Archive for the ‘user exprience’ Category

What is Usability

1 Usability definition:
As defined in ISO 9241-11 1 The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

2 Parameters of usability
1. Effectiveness : Task Completion
2. Efficiency : Lesser time / clicks
3. Satisfaction : Pleasurable activity

3 Benefits of Usability
Benefits to Users User satisfaction à User Delight More ease of use Efficiency increases Shorter learning cycle User perceived quality improved Benefits to Developers User oriented thinking = Reduction in rework Designing for the users and not (only) Clients Benefits to business Product quality improvement More value delivered à Priced higher Increased Profitability 4 Why Usability is important Other sources report : “There are about 43 million Web sites, and no one knows which ones are usable. The best sites we’ve found are usable only 42 percent of the time, and none that we have studied are usable a majority of the time ….” Forrester Research : Losing approximately 50% of the potential sales from a site as people can’t find what they need Losing repeat visits from 40% of the users who do not return to a site when their first visit resulted in a negative experience Jacob Nielsen : “Studies of user behavior on the Web find a low tolerance for difficult designs or slow sites. People don’t want to wait. And they don’t want to learn how to use a home page. There’s no such thing as a training class or a manual for a Web site. People have to be able to grasp the functioning of the site immediately after scanning the home page — for a few seconds at most.”

5 Usability Engineering Goals
1. Compatibility (with the user) – Computer speaking my language
2. Learn ability – I can do that.
3. User friendliness – Easily
4. Effectiveness A – Accomplish user goals.
5. Effectiveness B – Business goals fulfilled.
6. Efficiency – faster.
7. User Satisfaction – Alright ! it was smooth !
8. User Delight – Wow I did not expect this.
9. Flexibility – good ! You could do it this way also, (Ctrl C Ctrl V)
10. Excellent User Experience.

6 Usability Engineering Definition An Evidence based methodology that involves end users throughout the development process to product information systems that are measurably easier to use, learn and remember. — By Jean Fox, Janice R. Nall.

7 Understand the users
1. Who are the users of this specific product?
2. What are their User specific & Use specific needs?
3. What are the users goals for using this product?
4. Which areas are critical for meeting the user goals efficiently?
5. What other products they have used?
6. What is the terminology they use?

8 Model of stages of use Model for Stages of Use (for a particular application)
1. Novice
2. Advanced Beginner
3. Competent Performer
4. Expert “User and Task Analysis for Interface Design” by Joann T. Hackos, Janice C. Redish

9 GUI Design Process
1. Understand the Users
2. User goals, Business goals
3. User specific and use specific tasks
4. Define features
5. Design the work flow
6. Design the information structure
7. Design the front end

10 Usability Methods
1. Card Sorting Technique that allows users to group the information on your Web site and helps to ensure that the site structure matches the way users think.
2. Contextual Interviews Method that enables you to observe users in their natural environment to better understand the way users work.
3. Focus Groups Moderated discussion with a group of users that allows you to learn about users’ attitudes, ideas, and desires.
4. Heuristic Evaluation Usability inspection method where a group of usability experts evaluate the Web site against a list of established heuristics (or guidelines).
5. Individual Interviews One-on-one discussions with users that allow you to learn how a particular user works and enables you to probe on a user’s attitudes, desires and experiences.
6. Parallel Design Technique where multiple designers create mock-ups of the user interface and the best aspects of each design are used in the final design.
7. Personas A fictional person that represents one of the major user groups for the site. The design team considers the needs of this fictional person when developing the site.
8. Prototyping Draft model (or mock-up) of the Web site that allows the design team to explore ideas before fully implementing them. A prototype can range from a paper mock-up to interactive html pages.
9. Surveys (Online) Series of questions asked to multiple users of the Web site that helps you learn about the people who visit your site.
10. Task Analysis Method that involves learning about users’ goals – what they want to do on your Web site – and understanding the tasks that users will perform on your site.
11. Usability Testing One-on-one sessions where a “real-life” user performs tasks on the Web site in order to identify user frustrations and problems with the site.
12 Use Cases Description of how users will use a particular feature of the Web site. Use cases provide a very detailed look at how users interact with the site including the steps a user will take to accomplish each task. 13 Writing for the Web Guidelines for optimizing content on the Web based on the way users read online. Involves chunking content, using bulleted lists, and putting the most important information at the top of the page.

11 Heuristic guidelines for usability testing
1) System Status shown (Keep the user informed about what the computer is doing) Providing feedback to the users Appropriate method of feedback to be used
2) Match with the real World Use simple and natural dialog. Tell only what is necessary, and tell it in a natural and logical order. Ask only what the user can answer. Speak Users language Use metaphors familiar to users Use words and concepts familiar in their work. No computer jargon.
3) User has to feel he is in command Provide clearly marked exits so users can escape from unintended situations User should be able to leave an unwanted state Users should not get locked in the system
4) Consistency in terminology and required actions. Consistency in communication Names, Images Use sequence, Use of Controls Behavior of controls
5) Error prevention Prevent errors from occurring by keeping choices and actions simple UI should prevent an error from occurring Minimize error situations
6) Error Recovery Give good, clear, specific and constructive error messages in plain text, no beeps and codes Error messages should Clearly indicate the problem Constructively help users solve the problem Be polite and express in plain simple language
7) Recognition not recall Minimize the user’s memory load Objects and screens should be Easily visible Easy to interpret User should not be forced to remember any information
8) Flexibility Provide shortcuts for frequent actions and advanced users Provide multiple ways to accomplish the same task If possible provide freedom to customize the system
9) Minimalist Design “Less is More” Offer only relevant information and functions Make invisible all the irrelevant information & functions Seek minimum inputs from the users
10) Help and Documentation (Provide clear and concise, online help, instructions and documentation. Orient them to the users task) Anticipate where users will require help Provide appropriate help


Read Full Post »

original posted on http://www.strangesystems.net

Wireframes serve a central function in the development of a web site. It is a key tool in communicating the content and layout of each web page for internal and client reviews as well serving as a blueprint for graphic designers to produce designs and for programmers develop functionality.

What are wireframes?

A wireframe is a stripped-down visual representation of a single web page, devoid of any graphic treatment. As the name suggests, it is a framework made with wires, which define basic layout and placement of content and page elements such as navigation; header & footer; branding etc.

They are sometimes referred to as “page schematics”, “page architecture” or even “blueprints” (though the term “blueprint” sometimes refers to a more overall site design).

It is sometime helpful to use the architectural blueprint metaphor in understanding wireframes. Architectural blueprints show you the form of the building, define the functionality of the spaces and paths for circulation, while provide the contractor and interior designer specifications from which to build from. Likewise wireframes define areas of content and functionality, navigation strategy while providing a framework from which the programmer and graphic designer can build from.

A full wireframe needs to deliver the following information:

  • Layout: General placement of page elements such as headers, footers, navigation, content area, and often branding; It communicates decisions that as been made as to the navigation strategy of the site; it also shows the prioritization of the content on the page.

  • Content inventory: What content needs to be present on the page

  • Web elements: Headers, links, forms, lists, images etc.

  • Behavior: Notes/annotations may be added as to how elements should be displayed (such as number of elements, default display etc.), or what functional behavior occur when an element is activated (popups, page refresh, link to another page, or external site etc.)

When are wireframes created?

Wireframes as deliverables are developed as a part of Information Architecture phase. It usually follows the “Business Requirements” phase of the project and precedes any graphic design and technical development.

Usually this is the role of the information architect. On smaller projects, this often become the role of the project manager.

Who is it for?

The following table shows the consumers of wireframes and how they are used.

A blueprint with which they can review whether the design meets their needs; a preview to the actual site design; Key deliverable, the signoff of which kicks of design and development phases of the project

Consumer Usage
Project Team A communication tool around which aspects of strategy, technology and user experience can be discussed
Client Stakeholders  
Graphic Designer A guide upon which they can develop mockup designs
Web Programmer A requirements document that details layout, content display and functional behavior of a web page to certain extent

Types of wireframes

  • Content-only wireframes (aka Powerpoint wireframes): Powerpoint is used to define the key pages of the site. Name of the page, and a list of content items are captured on each page without information about layout or placement. This technique can be used to quickly capture client requirements and sketch out a site without having to go through the labor intensive work or creating detailed wireframes. Tools: Powerpoint

  • Block diagram wireframes: This type of wirefames is one step higher than the Content-only wireframes in that it offers basic layout information through blocks of functionality, and content grouping. These wireframes can be used in conjunction with detailed wireframes to provide a high level strategic overview to the wireframes before diving into the details. Tools: Powerpoint, Visio

  • Detailed wireframes: Fully-loaded wireframes with layout, content, web elements information along with notes and annotations on page behavior. Tools: Visio, OmniGraffle

Developing wireframes

Here are some basic steps an information architect would take when developing wireframes.

Gathering information

  • Business requirements: Ideally you would already have documentation from the the Business Requirements phase. This document will spell out major site functionality, key site pages and what content/functionality would need to be presented on them.

  • Content requirements: If there is no documentation from a previous phase it is important to meet with client and sketch out what needs to be presented on key pages of the site. A content-only wireframe is a good tool to do this.

  • Existing design requirements: Additional information such as need to integrate with existing site guidelines or need for consistency with previous site design, etc. should also be noted.

  • Bandwidth requirements Some clients may have to serve a low-bandwidth user base in which case, the design will have to be more text-reliant and less image heavy.

  • Software requirements Some sites are CMS-driven or software driven (such as blogs). Many software packages have layout and navigation rules the design will have to conform to.

Prioritizing/grouping information

  • Once the information has been gathered, it is important to first group and then prioritize how they need to be displayed on the page.

Navigation strategy

  • Clients may have strong preferences as to how navigation should work and be placed on the page. If there is no strong preference, software requirements and usability should dictate how navigation should be configured.

Drawing wireframes

Wireframes should include:

  • Key page elements & location: header, footer, navigation, content objects, branding elements

  • Grouping: side bar, navigation bar, content area, etc.

  • Labeling: page title, navigation links, headings to content objects

  • Place holders: dummy text (lorem ipsum dolor…), and image place holders

The question often arises: how many wireframes should I create? The answer is how ever many you need to get the job done. (or in our case how ever many we said we will create). Having said this the follow should be included in any good set of wireframes:


  • Homepage

  • Major sub-pages and “portal” pages

  • Key template pages

  • Pages with forms


  • Search results page

  • 404 Error pages

  • Any other pages that provide clarification to the overall development process

Read Full Post »

A User Interface Management System (UIMS) is a mechanism for cleanly separating process or business logic from Graphical user interface (GUI) code in a computer program. UIMS are designed to support N-tier architectures by strictly defining and enforcing the boundary between the business logic and the GUI. A fairly rigid Software architecture is nearly always implied by the UIMS, and most often only one paradigm of separation is supported in a single UIMS. A UIMS may also have libraries and systems such as graphical tools for the creation of user interface resources or data stores.

Generally, you cannot easily use multiple UIMS systems at the same time, so choosing the correct model for your UIMS is a critical design decision in any project. The choice of system is dependent upon the system(s) you wish to create user interfaces for, and the general style of your application. For example, if you want to create a web based front end, or just a standalone application or both that would be an important factor in choosing. If you want to deploy to the Macintosh, Windows and Linux, that would further influence your choice of a UIMS system.

Read Full Post »

The event, “Google Presents User Experience & Mobile Apps, Google user experience designer Leland Rechis started his talk by re-iterating Google’s mission: Organize the world’s information and make it universally accessible and useful. Rechis added that mobility is fast-becoming the key to making information “universally accessible,” but he warned that without a solid user experience, there is no way mobile applications can be useful.

Rechis said that when Google plans to launch a mobile application, it looks at the potential app through six layers:

1. Understanding users, anywhere, anytime

2. Fits in your pocket

3. More personal than the PC

4. Consistency across modes

5. Localization is intensified

6. Integrated devices, modes, products

Rechis then broke out the company’s mobile development and optimization strategy by each level.

Understanding users, anywhere, anytime

Rechis said that Google breaks down mobile users into three behavior groups:

A. “Repetitive now”
B. “Bored now”
C. “Urgent now”

The “repetitive now” user is someone checking for the same piece of information over and over again, like checking the same stock quotes or weather. Google uses cookies to help cater to mobile users who check and recheck the same data points.

The “bored now” are users who have time on their hands. People on trains or waiting in airports or sitting in cafes. Mobile users in this behavior group look a lot more like casual Web surfers, but mobile phones don’t offer the robust user input of a desktop, so the applications have to be tailored.

The “urgent now” is a request to find something specific fast, like the location of a bakery or directions to the airport. Since a lot of these questions are location-aware, Google tries to build location into the mobile versions of these queries.

Fits in your pocket

Rechis stressed the limitations of mobile phones. He pointed out that any mobile application has to be able to fit on a small screen and cannot require complicated text input. Also, since the third screen has no X-axis, layout has to clean, simple, but maintain the basic usability of the parent desktop application. Rechis also stressed that the “density of information” changes on a mobile phone, requiring designers to identify only the most essential parts of any given application. Obviously, juggling all this isn’t easy.

In order to achieve usable mobile applications, Fechis reminded the audience that they have to be willing to test and re-test applications with users. Otherwise you can’t get it right.

Also, building successful mobile apps requires developers and user experience people who are passionate about their subjects. He pointed out one Google employee who went to great pains to make sure that Google Maps gave directions correctly for Japan. Since street signs and markers in Japan are different than in the West, this employee had to go to great lengths to make sure that the app rendered maps and gave directions in ways that are useful for that country.


Google always strives to keep the look and feel of any Google application consistent, both within the type of function (i.e. all blog search results look different than map search results) and on devices (a map search on a desktop looks and feels like a map search on a mobile phone and vice versa). If mobile applications are to be universal, then developers have to maintain patterns and designs across all screens.

Read Full Post »

What is Strategy

Before we define User Experience Strategy, lets define Strategy. Answers.com says
“Management plan or method for completing objectives; plan of procedures to be implemented, to do something.”

That’s a bit vague, so lets try to get some handle here. Strategy is the path between Vision and executing vision or in other words a vehicle to realize vision. hmm so it’s not just a tool but has great importance. It’s a 3 step dance:

Vision > Execution Strategy > Execution

Many organizations tend to go directly from vision to execution, missing this important step in between, perhaps most important one as it is allows for energies and resources to be canalized in the right direction.


For this article I’ll equate Vision to goals even though that’s not entirely correct. But you’ll see why I am doing this.
Goals that an organization has are more or less a variation of:

  • Increase Revenues
  • Reduce Costs
  • Increase Profits
  • Increase customer base
  • Improve brand image


You need to figure out what variation of which goal do you want focus on in the solution you are building.



So now that some context is set for what strategy is and role it plays, Lets dig deeper into it. Strategy can apply to anything with a vision from building a house to marketing a product to anything. So there can be :

  • Marketing Strategy
  • Brand Strategy
  • Pricing Strategy
  • Product Strategy
  • Experience Strategy
  • Innovation Strategy
  • Coding Strategy
  • Combat Strategy


… this list can go on and on..

Important thing here is to understand that more than one kind of strategy can be applied to reach the goals.

Lets take an example – Microsoft v/s Apple – both would have had similar goals, but applied different kind of strategies, Needless to say but Microsoft focused a greater effort on marketing strategy and less on experience strategy, Apple was opposite.

Lets take another example – Google v/s Microsoft (can’t resist this one). If you look at it Google is NOT a search company, it’s brand stands for innovation , that’s the reason we just absorb “any” product they launch.. everyone has to have an account with new products from Google.

A non-tech example would be airlines – Jet blue had experience strategy, they had well developed systems (in non-technical sense) to ‘institutionalize’ ability to provide superior experience

So User Experience Strategy is one of the many that an organization can choose from. Each strategy has a cost and value that it delivers. Also strategy does is relative not absolute. It depends on time, market, and competition.

How to decide on the strategy? Here are some tips, (but this is a subject that deserves a separate article):

  1. Vision: This of course is the starting point, strategy must align with vision.
  2. Industry Direction: Take an example of Hotel industry, the base direction it is taking is experience strategy, which is good, but question to be asked is if you can differentiate yourself on same strategy or something else is needed. Consider Yahoo – it has opened yahoo products like a development platform, because even though industry is moving towards Innovation Strategy, they cannot generate enough innovation in house.
  3. Socio-Economic Situation: Back in 1940-50s airline prices were regulated by government, given this airlines could only differentiate based on service and experience they provide. Once that regulation was removed, price wars started and strategy changed.
  4. Competitive Landscape: This is very much of like Industry, however in case you have specific competitors you are going after, looking at Industry direction alone would not be enough, you competitor might be doing something that changes Industry direction
  5. Your offerings: Last but not the least your capabilities. Sony is putting a great deal of resources on Blue Ray disc (one of the two HD DVD Formats being released). This has resulted in them selling new Playstation boxes at a loss because Blue Ray drives are being shipped in new PS and have added significantly to costs. But with competition from X-Box they cannot increase prices. So look at where is the strength in our offering and adopt the right kind of strategy.


User Experience

Okay, let me take a parallel road and look at User Experience at very high level, and then we’ll converge it with Strategy discussion.

So what is User Experience? Answers.com does not even tries to answer this, so lets take it from Wikipedia:

“User experience is a term used to describe the overall experience and satisfaction a user has when using a product or system.” We should change ‘system’ to service.

In more materialistic terms I would say User Experience is essentially something that resides in User’s long-term memory and has a bearing on decision to transact with the company in future. This could be positive or negative.

You need to ask following questions, and these will map you to User’s experience life-cycle:

a. How do users come to know of their need?
b. How do they find the right product/service?
c. How do they make a decision on that product/service?
d. How do they order it?
e. How does it get delivered?
f. How does it get installed?
g. How are problems with product and service resolved?
h. How is it disposed?

Am sure some questions here are new and do not form a part of current experience design discussions, but all are important opportunities.

Now map your user’s path across these stages and rate your and competition’s performance at each stage. I like to follow a 5-point scale as it brings enough granularity, and at the same time has limited subjectivity. I do not recommend using 1 to 5 scale, instead use (-) 2 to (+) 2, i.e. –2, -1, 0, +1, +2

-2 Significant problems with experience
-1 Mild problems with experience
0 As expected
+1 Mild improvements to expected experience
+2 Significant improvements to expected experience

So now you have some assessment of User Experience at high level

Bringing the two together


So now you know which places the experience fails. Next Step is to “Identify Critical moments”. These are moments where users decide to move to next step or not. For e.g. lets say you are doing this for Parking Garage and experience of finding the garage was significantly negative, but once they find the garage they might go ahead if other parameters are fine. But if at this stage attendant’s approach is not right and if customer place high value on attendant’s attitude making it “critical” for customer, she might decide to look further.

So identify such critical moments and those are where you start to focus on. With this you have now narrowed on 2-3 such critical points and start to go deeper.

How do you find what’s critical and what’s not – User Observations are the most reliable method. Go in the field see what goes on and you’ll know what’s important what’s not. In addition talk to people. Do this for your product/service as well as competition product/service

Read Full Post »

A general principle for all user interface design is to go through all of your design elements and remove them one at a time. If the design works as well without a certain design element, kill it.   — Jakob Nielsen, author and consultant on user interfaces

A good website should have at least the usability and usefulness of a good book. But, although rarely fully exploited, it has the potential to be far more usable, largely because of the availability of hyperlinking.   — a Bellevue Linux Users Group member, August 2005

A well-designed and humane interface does not need to be split into beginner and expert subsystems.   — Jef Raskin, human-computer interface expert and a designer of the first Macintosh

Computer science departments have always considered ‘user interface’ research to be sissy work.   — Nicholas Negroponte, founder and director of the Massachusetts Institute of Technology’s Media Laboratory

Computing has gone from something tiny and specialized to something that affects every walk of life. It doesn’t make sense anymore to think of it as just one discipline. I expect to see separate departments of user interface, for example, to start emerging at universities.   — Nathan Myhrvold, former Microsoft executive

Don’t make me think.   — Steve Krug, usability expert

If the user can’t use it, it doesn’t work.   — Susan Dray, usability consultant

Most websites today fail basic tests of usability.   — Forrester Research

No matter how good your backend systems are, the users will only remember your front end. Fail there and you will fail, period.   — Tristan Louis, writer about the Internet

The Interface is the system.   — unknown

The only ‘intuitive’ interface is the nipple. After that, it’s all learned.   — unknown (but often attributed to a Bruce Ediger)

Usability cost-benefit data shows that including usability in product development actually cuts the time to market and increases sales because usability and ease of use build quality into products and catch many expensive problems early on in the cycle when they can be addressed at lower cost. Finally, working with users from the beginning of a product cycle ensures that the product is being designed so that users will be satisfied.   — Claire Marie Karat, human-computer interface researcher at IBM

Usability is critical for any application, but for mass-market software, usability spells success or failure more clearly than any other feature.   — Jerrold Grochow, Chief Technology Officer, American Management Systems

Usability really just means making sure that something works well: that a person of average (or even below average) ability and experience can use the thing – whether it’s a web site, remote control, or revolving door – for its intended purpose without getting hopelessly frustrated.   — Steve Krug

Usability rules the Web. Simply stated, if the customer can’t find a product, then he or she will not buy it.   — Jakob Nielsen

User interfaces have to do with people, and computer scientists don’t like to work on problems involving people. The classic work on user interfaces that sets the current paradigm was invented outside of universities in industrial research laboratories and government-funded institutes.   — Stuart Card, interface researcher at Xerox PARC

… when folks read news online, their eyes go for text first, particularly captions and summaries, and graphics only later.   — Bryan & Jeff Eisenberg, usability consultants and authors

Read Full Post »

 A prototype is a model of something to be further developed. The higher the fidelity the more representative is the prototype. Rapid prototyping implies that there is a short time between conceiving an initial notion and modeling it in physical form and between successive iterations. A popular method is to use paper to create the prototype (Snyder 2003) which can be done without programming skills and which has the look of work in progress thus encouraging users to comment on it. Software prototypes can then be developed when the ideas have been thought through and tested on paper. These can then be used for usability testing.

The reasons of Rapid Prototyping are

  • To increase effective communication.

  • To decrease development time.

  • To decrease costly mistakes.

  • To minimize sustaining engineering changes

  • To extend product lifetime by adding necessary features and eliminating redundant features early in the design.

Appropriate Uses

Rapid prototyping can be used for a number of purposes:

  • To be creative: the prototype can be developed in a workshop setting as part of the creative process in developing system ideas, functions and user interfaces.

  • As a basis for evaluation: the developed prototype (on paper or in software) can be tested for usability or usefulness with real users.

  • For communication: the prototype can be used promote a design idea or to support a request for a design requirement.

Costs and Scalability

Paper prototyping can be carried out by human factors or usability specialists with the support of domain experts and users. No special equipment is required.

Software prototyping also requires someone with knowledge of the prototyping tool being used.

Read Full Post »

Older Posts »