What is a UI Design Pattern and what are its benefits?

UI Design Patterns are an important aspect of application and website usability and user experience. UI Design Patterns (also commonly referred to as Interaction Design Patterns) document and convey robust UI design solutions, that have proven to be successful over time, to common usability requirements. Properly applying UI Design Patterns ensures the UI designer that the application or website will be intuitive and its features and functionality robust. There are many benefits to using patterns including: Teaching new UI designers, analysts and developers best practices and common approaches to solid UI design. Speaking about UI design in standard terms that everybody understands. Reducing the time and cost required to design UIs, since it always takes longer to reinvent the wheel. Using metaphors that have been tested across a number of different contexts. Making it easier for users of a new application or website to understand how the interface should be used to accomplish their tasks since users have seen the same pattern used many times before. Ensure a consistent user experience across screens within an application and across multiple applications within a product suite.

What are some guiding principles or tenants of UI design?

Usefulness Ensure that the system includes the most important features and functions needed to provide value to the user. A system that is missing high priority functionality is not going to be very valuable. Similarly, a system that includes too much additional functionality which lacks relevance to the user will obfuscate the intended flow through the system. Consistency Consistently apply the UI design patterns that your group has agreed upon and adopted ahead of time. This includes UI actions, product terminology and UI commands. UI design pattern consistency is important across screens within an application as well as across applications within a suite of products. Whenever appropriate, the concepts, terms and metaphors used should mirror that of the real world and present information in a logical order. Simplicity Keep the design clean and clutter free eliminating any unnecessary or irrelevant information, features, controls, or icons. When many options are available for a user to complete their task, keep the most commonly used options visible and make the other options readily accessible via some other means. Design the system with the goal of being intuitive enough that an appropriate user of the system can learn it without instruction or formal training. Communication and Feedback The system should provide clear and timely feedback in response to user actions. This reinforces within the users mind that they have taken the correct step to successfully complete the task. Organize and sequence the information within a screen in a way that conveys specific meaning to

the user. Like information should be grouped together and the order in which a user encounters information should reinforce the flow of the process as they currently understand it. Ensure that whatever help information is provided is concise and focuses specifically on the users task. Error Prevention and Handling A system cannot and should not catch all mistakes. It should catch serious errors when possible, but should not be so restrictive that it does not allow for reasonable variation in data entry or process flow. Ask the user for confirmation before allowing a potentially destructive action such as permanently deleting a record. If the user performs an incorrect action, provide clear and descriptive messaging that describes what they have done wrong and when possible how they can correct it. To relieve anxiety, provide the user with the ability to discard unwanted changes, or to undo a particularly sensitive action. Efficiency Ensure that skilled users can use the system efficiently and that functionality built for inexperienced users does not slow down skilled users. Provide shortcuts keys and functions for the experienced user and allow for customization of shortcuts when possible for frequent actions. Workload Reduction Automate aspects of the process and system whenever possible. If something can be easily derived by the application then dont make the user spend time doing it. Eliminate mental calculations and comparisons by showing the results on screen. Ensure that users dont need to remember information from one screen to another. Provide the necessary information on each screen for them to be able to complete their work. Designer Judgment Remember that usability guidelines are just that, guidelines. There are tradeoffs between perfect UI design, user experience, and system performance. There will always be cases where it makes send to not follow a particular guideline or principle. Use your judgment. However, try to stray from guidelines as infrequently as possible and, when doing so, be sure to document the reason why the guideline was not followed for future reference.
What should be documented in a UI Design Pattern?

Though pattern descriptions vary somewhat, many pattern templates contain a set of common sections. Primary Sections of a UI Design Pattern Name: Should be concise yet descriptive (typically between two and four words in length) so that someone can find the pattern easily and reference it within discussions for clear communication amongst team members. Description: A few lines briefly describing the pattern. Since short names are not always sufficient enough to clearly and uniquely describe the pattern a description is important. However, this is not where you will describe the pattern in great detail.

End User Requirement/Problem to Solve: Communicate what requirement or challenge will be solved by the pattern. What is the user trying to achieve? When to Use/When Not to Use: It isnt always obvious under which condition or within which context a pattern should be used. Here you can document when a pattern should be used and, equally important, when it should not be used. Solution: Document the details of the pattern/solution including a detailed description of the user interaction. Include screenshots to help convey the pattern clearly as needed. Comments: Capture any other comments that you feel are relevant to the reader. Optional Sections of a UI Design Pattern Depending on the needs of your team or organization you may choose to add some additional sections to your pattern template. Examples of Past Uses: Including screenshots of past uses of the pattern along with a brief description can help the reader visualize the benefits of using the pattern. Rationale for Use: Understanding why a particular pattern works so well can be invaluable when deciding whether to use one pattern over another. Detail out the specifics of the user experience and the direct benefits that they receive by using this pattern. Implementation Specifications: If standards exist within your organization or team, consider accompanying the pattern with style guide information such as font family, font size, font weight, font color, table and cell spacing, and more. Or if the styles change based on the application or product being developed, provide a link to the style guide information. Usability Research: Any specific feedback on how well the pattern works can be documented for future reference. Consider including feedback from UAT testers or your sales organization, but also dont exclude feedback from developers and other testers. Related Patterns: List other patterns that may solve a similar problem or patterns that work together to achieve a broader goal. Pattern Variations: Document minor variations in the pattern that can be used. If the variations are significant enough, consider developing a separate but similarly named pattern. For example, Tag Cloud 1 and Tag Cloud 2 Development Notes: Capture notes that help the development team implement the pattern. This may be a snippet of code or a link to a code library where the code for the pattern can be found.
What type of testing might involve the business analyst?

Of the various types of testing, the business analyst is usually most involved with Functional Testing, Regression Testing, and Usability testing. Since the business analysts are closely involved in documenting the business requirements in the BRD and may also be writing the functional specifications, many organizations will involve the business analysts in the role of Functional Testing. This may be to create functional test cases, or sometimes even to carry out the test cases themselves. Regression testing is used to refer to

retesting a portion of the system after a modification has been made to ensure that it still performs per spec, and typically refers to Functional Testing. Similarly, given that many business analysts also end up designing screens and portions of the user interface, it often makes sense to engage them in usability testing. Usability testing may be done up front on a lightweight prototype of the application to help the business analyst understand the best way to design the features across screens and how to design the individual screen UIs. It can also be completed after the final application is delivered to the client. This way, the results of the usability testing can be used to improve on UI design as future modifications are made.
What types of testing should be considered when developing an application?

There are so many different types of testing that it would be difficult to come up with a comprehensive list. Additionally, each type of testing typically has a number of variants that have been developed based on the team creating the testing strategy. However, the most common types of testing used by a majority of projects are: Unit Testing (Component Testing) refers to the testing of individual software components as they are completed. This type of testing is typically completed by the development team. Integration Testing refers to the testing of components as they are combined or integrated together. This ensures that each component that has been tested on its own operates correctly when it is used in conjunction with the other components that it is designed to interact with. This is particularly important for client/server and service oriented architecture systems. User Acceptance Testing refers to testing that is performed by the user or end customer of the system as a condition of approval. User Acceptance Testing is where the user/client ensures that the final application or product meets the agreed upon requirements set forth by the Business Requirements Document. This is also why traceability of requirements throughout the entire Analysis, Development, and Testing lifecycle is so important. Functional Testing (Black Box Testing) refers to testing the features and behavior of an application to ensure that it coincides with the functional software specifications provided. This type of testing is also referred to as black box testing because it completely ignores the internal workings of the program and focuses only on the outputs as a result of the specified inputs and execution steps. Usability Testing refers to testing the ease in which users can learn the application, as well as the users efficiency and productivity while using the application. Performance Testing (Load Testing, Stress Testing) refers to testing performed to evaluate whether the system meets the documented performance requirements. Performance Testing ensures that the system will support a specified number of users while still maintaining specific service level agreements (SLAs) for page load times and service response times. This type of Performance Testing is also called Load Testing. Additionally, during Performance Testing, often it will be required to test the systems limits and determine the maximum number of concurrent users that can be supported before the system fails. This is referred to as Stress Testing. Regression Testing refers to testing a portion of the application that has previously been tested following a modification to ensure that the original functionality still works and behaves per the specification. While Regression Testing really just means to go back and retest, it typically refers to Functional Testing.

What is the Herfindahl Hirschman Index (HHI) and why would you use it?

The Herfindahl Hirschman Index (HHI) is a measurement used to understand the level of competition that exists within a market or industry, as well as give an indication of how the distribution of market share occurs across the companies included in the index. Understanding the level of market competition can be important for strategic planning as well as when trying to establish pricing for a companys products or services. The calculation of the HHI differs from the standard Concentration Ratio in that it squares each market share value which places a higher importance on those top companies that have a larger market share. The formula for determining the HHI is as follows: HHI = MS12 + MS22 + MS32 + MS42 + MSn2 The HHI can have a theoretical value ranging from close to zero to 10,000. If there exists only a single market participant which has 100% of the market share the HHI would be 10,000. If there were a great number of market participants with each company having a market share of almost 0% then the HHI could be close to zero. When the HHI value is less than 100, the market is highly competitive. When the HHI value is between 100 and 1000, the market is said to be not concentrated. When the HHI value is between 1000 and 1800, the market is said to be moderately concentrated. When the HHI value is above 1800, the market is said to be highly concentrated.

These values are used by the Department of Justice when evaluating whether to permit a merger of two companies. Using the HHI, we can quickly gain insight into the distribution of market share within an industry. The example below demonstrates the additional information that can be gleaned from the HHI over the Concentration Ratio. Example 1
Market Position Market Share % CR8 HHI 1 2 3 4 5 6 7 8 8 8 9 4 1 1 1 9 6 10 11 12 13 14 15 3 3 2 1 1 1

100 12 12 11 11 10 10 9 83 12 12 11 11 10 10 9

920 144 144 121 121 100 100 81 64 36 9

Example 2
Market Position 1 2 3 4 5 3 3 6 2 2 4 7 8 2 2 4 4 1 1 1 1 1 1 9 10 11 1 12 1 13 14 15 1

Market Share 100 39 % CR8 HHI 92 39

23 17 4 23 17 4

2 2 4

238 152 529 289 16 9 1 1

In this example, both industries have 15 companies that make up 100% of the market share. In example 1, the industry has a more evenly distributed market share across the 15 companies, while example 2 shows a heavy concentration of market share among the top three companies. If a business analyst were only to look at the difference in Concentration Ratios (accounting for the top 8 companies) between the two examples, they would see that the CR8 of example 2 with a value of 92 is only 11 percent greater than the CR8 of example 1 with a value of 83. However, using the HHI they would find that the HHI of example 2 at 2381 is 259% greater than the HHI of example 1 at 920.

What is RUP (Rational Unified Modelling) ? with examples

Inception Phase: Interacting with business users , developers and project manager to make business requirements by using tools like MS Visio and MS word. MS excel also used for some documentation purpose. Using RUP (rational unified modeling) to make BRD (business requirement document) specifications.

Performing requirement analysis and design work with rational rose and analyzed, documented the system specifications, business requirements and detail design of the existing business by using a the tool requisite pro for the requirement tracking and analysis.

Elaboration Phase: In this phase created Activity diagrams, sequence diagrams and collaboration diagram etc by using Microsoft tool MS Visio. Documented the critical path analysis and extensively analyzing the ER diagrams (entity relation diagrams). Also finding out the different opportunities and parameters that can improve the business process and performance.

Finally coordinating the project scheduling with IT development manager.

Construction Phase: Developed a prototype for actual system and developed project blue print. Also developed a mock web page generation for a part of the system goal.

Writing use case specification for the given business requirements. Identifying the actual network and human resources to utilize properly for development, documentation and training purposes.

Transition Phase: In this phase we concentrate in vendor software compatibility , data base integrities and other performance issues.

Successfully deploying the finished product.

Configuration, implementation and deploying the developed software in various cross platforms to see the products efficiency.
What is Model-View-Controller?

Model-View-Controller, or MVC, is a design and architectural pattern used to ensure that the modeling of the domain, the presentation information, and the actions taken based on user input are loosely coupled and maintained as separate classes. The View manages the display of information. The Controller handles input events from the user interface using handlers and tells the Model or View how to update itself accordingly. The Model manages the behavior and the data of the application domain. The Model responds to requests for information about its state (usually made by the View so that the View can redisplay itself). It also responds to instructions to change its state (usually coming from the Controller).

The key to the MVC pattern is in the relationships that exist between each of the three objects. As shown in the diagram below, the View is dependent upon the Model, the Controller is dependent upon the View and the Model, but the Model is dependent upon neither.

The existence of a dependency means that if the definition of one element changes then the other element which is dependent upon it may also change. In turn, this would mean: If my View changes then my Controller may need to change If my Controller changes then neither my View nor my Model should need to change If my Model changes then both my View and my Model may need to change

This is where the MVC pattern proves its worth. Controllers are just the glue that allows for the loose coupling between the Model and View. Since the data and behavior of the application domain which are maintained by the Model typically change far less often than its presentation (the View), it is the impact of changing the presentation or the View that we want to minimize. And this pattern does just that. A change to the View which may happened quite often only requires updates to the Controller. However, a change to the Model which is less frequent would potentially require changes to both the View and the Controller.

What is a Concentration Ratio and why would you use it?

Concentration Ratio (CR) is a measurement used to understand the level of competition that exists within a market or industry in which a company operates. Understanding the level of market competition can be important for strategic planning as well as when trying to establish pricing for a companys products or services. The Concentration Ratio provides a view of the market and of the price sensitivity that may exist for the companys products or services. A highly competitive market will have much greater price sensitivity giving a company less pricing power than it might otherwise have in a market which is less competitive (only a few key players reflecting an oligopoly or monopoly). The Concentration Ratio is often determined for the top 4, 8, 20, 25, and 50 largest markets participants by revenue. However, the most prominent Concentration Ratio used to measure market competitiveness is the CR4 which is determined by measuring the total market share (MS) of the 4 largest market players. The formula for determining any Concentration Ratio is as follows: CRn = MS1 + MS2 + MS3 + MS4+ MSn, where n is typically 4, 8, 20, 25, or 50.

In the case of the CR4 (4 largest companies by revenue), if the total is less than 40% then the market is said to be competitive. If the CR1 value (single largest company by revenue) is greater than 90 then effectively a monopoly exists. One of the cons of using the Concentration Ratio value alone is that it doesnt give any indication of how the distribution of market share occurs across the companies included in the ratio. Are there a few key players in the lead and everyone else shares a very small percentage? Or is there a fairly even market shar distribution across all market players? For this reason, some choose to use another value for determining market concentration called the Herfindahl Hirschman Index (HHI). Concentration Ratios for US markets and industries can be found at the US census bureau (http://www.census.gov/). Here is a sample from 2002 (http://factfinder.census.gov/servlet/IBQTable?_bm=y&geo_id=&-ds_name=EC0231SR13)

What is SWOT Analysis?

SWOT Analysis is a strategic planning technique used to assess the internal and external environment in which a company operates and competes. Internal environmental factors are classified into strengths and weaknesses, while external environmental factors are classified into opportunities and threats. Each is identified as follows: Strengths (internal factor): The companys resources or capabilities that give it a competitive advantage within its market or industry. Weaknesses (internal factor): Areas where the company lacks certain resources or capabilities that prevent it from taking advantage of available opportunities or make it vulnerable to other environmental factors. Opportunities (external factor): Industry or market factors that may result in company profit and growth. Threats (external factor): Factors that may have a negative impact on the companys profit, growth, or position within its industry or market. Strengths (Internal) Weaknesses (Internal)

(Quadrant 2) If particularly (Quadrant 1) Focus on profitable market opportunities areas where a companys Opportunities exist then the company may strengths align with market (External) want to eliminate weaknesses opportunities for rapid in this area to take advantage of growth and profitability. these opportunities. (Quadrant 3) When a companys strengths align with market threats, these strengths can be use to avoid or mitigate these market threats. (Quadrant 4) When a companys weaknesses are in the same area as market threats, steps should be taken to eliminate these vulnerabilities immediately.

Threats (External)

A company should usually focus their effort on quadrants 1 and 4 first. Quadrant 1 delivers the most amount of gain for the least amount of effort since it takes advantage of existing strengths of the company. Quadrant 4 will likely require a lot of effort, but if left unattended, could result in detrimental outcomes for the company.
What is the difference between a Primary and Secondary Actor in Use Case Modeling?

Use Case modeling is used to diagrammatically depict a system and those people or processes that interact with it. This system can be a business system (a process) or an application system (computer or web based). To understand the scope of the system under consideration a system boundary is used. Anything depicted within the system boundary is part of the system under consideration, while anything outside of it is not. Use cases are then used to define a group of user-system interactions that together deliver value to the user of the system. These users are called actors. Primary actors are people, or at times even other systems, that require the assistance of the system under consideration to achieve their goal. They initiate the use cases of the system (business processes or application functionality). A use case within the system may have more than one primary actor, since more than one type of role may initiate the processes or functionality of the system. The system, and its use cases, often rely on other people, business processes, or applications in order to obtain a result or specific information required to achieve its goal. These are called Secondary Actors. A secondary actor is one from which the system requires assistance to complete the use case. A secondary actor never initiates the use case. It is invoked by the systems use cases in order to obtain information or a result. There may also be many secondary actors of a system.
What is a View as it relates to system modeling?

A view organizes diagrams into logical groups to describe a particular aspect of the system. It is the abstraction of the system organized is such a way as to give a perspective of a related set of concerns. The purpose of using views as a business analyst is to enable the analyst to comprehend very complex systems, and to organize the problem or solution domain around specific areas of expertise. The audience interested in each view may vary based on their roles and experience. A subject matter expert from the business will ask different questions and have different concerns than a developer or system architect. Views help present the information in an easily digestible manner. The different views that a business process or system should be broken into varies and is the decision of the analyst and the stakeholders involved in the project. Some common views used by analysts are: The Behavioral View A view showing the functionality of the system as perceived by external users. The Logical View A view showing how the functionality of the system is designed in terms of the logical static structure and dynamic behavior. The Implementation View A view describing how the physical code is structured, its main modules, and their dependencies.

Deployment View A view showing the physical deployment of the system such as computers, servers, switches, routers, etc. Organization View A view depicting organizational elements, their structure, and their relationships. This may include people (an org chart), agreements, contracts, policies and organizational interactions. Requirements view A view describing the requirements, goals, and objectives that the system shall support.

Not all of these views would necessarily be used together. They belong to multiple standardized view models. Some standard view models or frameworks exist which dictate how systems should be organized into standards views. Some examples are: 4 + 1 View Model Department of Defense Architecture Framework (DoDAF) Reference Model for Open Distributed Processing (RM-ODP) Zachman Framework

What is the 4 +1 View Model as it relates to system modeling?

The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software. The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system. The 4 primary views are: Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior. Development View: this view describes the system from a programmers perspective and is concerned with the organization of physical code, its main modules, and their dependencies. Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few. Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.

The 1 supporting view is: Use Case View: this view describes the functionality of the system from the perspective of external actors.