Talk to your users

Talking to users is the first and the most important aspect of designing a software product or application. Talking to the users can be done in many ways - Ethnographic studies, contextual inquiry and observations, questionnaires, card sorting, affinity diagramming, etc. All these user research techniques help in user interface analysis, design of appropriate scenarios, help in layout and visual design, and design of protocols for usability testing. User research also helps the product development team arrive at appropriate functionality and prioritize it.

However, in small and medium-sided software product companies, it becomes very difficult for usability professionals to conduct any meaningful user research. Software product companies create many barriers between the usability researchers (or developers) and users.

1. The Chief Technology Officer of a small sofware product company in India was of an opinion if users can talk to the development team, they will disturb the development process. The users will constantly call or email them with bugs, discuss ideas, give suggestions, and would want them to solve all support queries.

2. Sales and marketing departments don't want the product team to talk to the users. They don't want the team to talk to satisfied users because such talks may make users dissatisfied with the current product. They also don't want the product team to talk to dissatisfied users because the users may feel that the product is really bad.

With the above excuses, even a good product idea can see a slow death. First commandment of usability is "know your user."

You may want to see how McAfee understood their users to fuel a successful product.

Where is the learning?

Companies are moving their instructor-led training material to self-paced elearning (first generation elearning) to save costs, manage learners, manage scores, manage multiple courses, and feed this data into the human resource software for employee performance appraisal.

But, what happened to the learner and the quality of learning? Earlier, learning was instructor- led and it had pedagogic roots of classroom training methodologies. However, the same methodologies cannot be replicated to a self-paced learning system. The instructor also used to keep tab of individual learning needs and styles. Moreover, adult learners prefer instructor-led face-to-face learning than learning through the use of electronic media.

As learning moved to elearning, the variety of methods earlier used by the instructor reduced drastically to rudimentary instruction methods (read Jurassic age!) provided by an LMS. Now, e-instructors have to confine to drag-and-drop or 3-answer MCQs to test learners' procedural knowledge. As the manageability of the learning increased, the quality of learning suffered.

Corporations have also started singing LMS tune - the score of the course is directly proportional to the learning, which is directly proportional to employee remuneration. Corporations fail to realize that learning must be measured by measuring the quality of output at work and elearning score is no indication of performance. Training managers and HR managers must understand that learning and training is in context and must be measured in context - the context being the work environment.

Ranking features in functional requirements

System functional requirements is a laundry list of all the requirements and features of the proposed system. It conveys that all functions and features are equally important. The reality is that the features that requires minimal coding are taken up first. Features that require a lot of coding or that cannot be achieved using the current API are also delayed.

There is much written about feature prioritization - Coad proposes a technique of ranking features according to customer satisfaction if the feature is included. Moreover, ranking them by customer dissatisfaction if the feature were ommitted. This will give a clear ranking of the features.

On the other hand, the feature list is the first step for a Usability Specialist. They need to order the list to rank each feature. Each feature is ranked according to the functional necessity and frequency of use. This ranking can be achieved after the task analysis process. The ranking is required to understand where the Usability team should concentrate on - the 80/20 rule.

Cracked Programmer Creole!

Are not abl;e to see this slide. this slide has mainly bullets and the link opens site. If you can see the site which opens in a diff window the QuickStart/Control Practices can be seen. You cant understand any specific thing we will send thiss to Jen.

Crack: We are not able to see this slide. This slide mainly has bullet points as links. Each link opens a new window. If you can see the site, you will be able to see Quickstart/Control Practices. If you can not understand anything, we will send your query to Jen.

I spent about half hour to crack this - fast! Am I am qualified to be a programmer now?

Web-based applications' data entry guidelines

For designing a data entry system, the guidelines differ according to these key parameters:

1. Domain knowledge of the user (for semantic errors)
2. User training and experience of the user (typing mistakes, cultural conventions)
3. Data source (paper, scanned, another program window, audio, etc.)
4. Data entry technology

While using paper (or similar) based source, a very strong co-relation exists between the layout of the data entry forms and the structure of the associated data entry screens. To require a user to scan and re-scan in input form to locate (and re-locate) various data entry fields invites significant errors.

Regardless of the technology used, there are various techniques used to reduce data entry errors:

1. Long string reduction (from 146734678453 to 1467 3467 8453)
2. Mnemonic re-structuring of semantic data
3. Co-related screen layout for paper based entry
4. Elimination of social amenities like please, do you wish, and if you want among others.
5. Native language input cutomizable according to demographics
6. Standardization of terms, abbreviations, and conventions accoriding to users' domain knowledge
7. Early identification and structured display of errors either inline or spatial
8. Empirical default entry strategies for greater than 80% chance of selection
9. Automation of entry completion
10. Inclusion of error toleration like synonyms, homonyms, and vowel elimination or replacement in spellings among others.

Design of rich internet applications

Rich Internet Applications, in my experience of building large call center applications (yes! web-based), are a mix of page-centric HTML and the GUI applications. They trying to achieve the rich interactivity of GUI applications in a web scenario.

As we all know, 80% of usability is navigation. RIAs are breaking the paradigm of "navigation metaphor." Moreover, navigation is changing its meaning -- it has got many visible layers now.

The first layer has closed or partially open windows (sliding windows). These metaphoric windows contain information needed for successful completion of the immediate sub-task. These can take shape of a tooltip, a layer for quick selection, etc. It can also be quickly show the contents so that users can make a decision. This is information "on the fingertips."

The second layer has open windows. This layer consist of information or subtasks that are needed or performed by the user "regularly." For example, in a call center application, name of the customer is needed all the time by the user to address the user many times during the call, while the user also changes the customer address/phone numbers most of the times during the call. This navigational layer must always be visible and "accessible."

The third layer is a door that leads to another room - usually another page (or screen, or pop-up window, or similar artifacts) where the user must "go" to perform a task. These places are usually reached when the user performs tasks that are either not regularly performed or have information that is not needed in most scenarios. This layer is also usually reached navigating through layer two, however, shortcuts for advanced users do exist (depending on the personae).

In such navigation scenarios, the challenge is that the information and tasks must be findable on a screen (or page) vs. finding them on other pages. The scent of information through appropriate grouping, visual hierarchy, and spatial placement of artifacts on the screen gets very high importance.

My questions are: 1. How much support do popular webserver platforms such as Weblogic, Websphere, or Macromedia's JRun provide for RIAs? 2. How do RIAs cope with thousands of users logged in together, asking far more data than simple cookie based applications (page by page navigation approach)?

Joel and Napster's Affordance

While paving my way through the blogiverse trying to find familiar people, I stumbled upon Hejip, an old colleague and friend. In his blog about usability, he did mention Joel - who has now become the de-facto usability guru among software developers - Cooper is another. However, Nielsen and Eric do not find too many software takers as they talk about public websites and intranets and not real software applications.

Coming back to Joel and his old blog Its not Just Usability, was affordance of Napster really that bad? I don't think so. There are many reasons why the buttons on Napster are as good as tabs:

1. Position: The position of the button was at the top to mimic the position of the tabs. If the buttons were either on the right or bottom of the screen, Napster may not have a story to tell. Buttons on the right or bottom mean that they are action buttons and are clicked "after" the user feels that the action is complete. These buttons are never perceived as navigational elements. However, buttons on the top and on the left are typically perceived as navigational elements and are not confused as action buttons.

2. Shape: The Napster buttons were rectangular and placed horizontally - the approximate shape and the placement of tabs as we know them. The size of the buttons also was very similar to a regular tab.

3. Mutually Exclusive Affordance: The buttons gave good feedback that only one can be selected at a point of time - only one button (the selected one) was depressed. If any other was selected, the selected become the depressed on while the previously depressed came back to normal position. The affordance of buttons being mutually exclusive was very good.

So tabs could have been better? I don't think so - they would have been as good. Napster confirmed to good Usability principles while using buttons. However, that was not the reason that Napster was popular (Joel would agree too!) - the popularity of Napster solely lies with the usefulness of the software in social settings. Even if Napster's usability was bad, I am sure it would have been as successful.

Cutting edge product idea - a conversation

One of my regular client contact who works with a "cutting-edge" technology company invited me for an informal chat about a revolutionary new product idea. According to the client the product idea could potentially be a gold mine. I said wow! I also quickly landed up at their now-impressive office - once again. The earlier state of their office and the state of chairs is definitely bloggable sometime, I promise.

Powerpoint presentation with a cup of machine made coffee was my introduction to the grand new product idea. We will use the latest technology. Impressive! I must say.

So who are your users for the product? Hmm... let me think... the users is the XXXX industry in general.

No, I mean, who in the XXXX industry will use your product? The XXXX people who design new products will use it.

I think I need to make myself clear - what is the designation or job role of the person who will use this product? He is definitely the person who is an industry expert. I think he may be a VP or something...

What do you think this person will do using your proposed product? He will design new XXXX programs.

How many times do you think these programs change during a day? I dont think they change daily. Weekly? Nah. Monthly? May be, but I dont think so. 6 Monthly? I think so. 1 Year? Some may change... actually it depends on the XXXX company.

How do you think these products are designed? They analyze previous data, put in their hunches, see if the hunches are true, then they simulate the data, and then propose a new product.

Can I call up my XXXX manager, he may have some information about this industry? Sure... let me pick up another coffee... the office AC is working today.

Hey Jayram (my XXXX manager), can you tell me how XXXX products are designed and who designs them? In my company, a new product team designs these products and the team report to country head directly as these products are crucial to our bottomlines.

That's cool, but how do they think of new products? Market pressures, competitors, government policy changes, the reasons can be many. I can get you in touch with one of my friend's who works with that group, interested? Yup, I said.

So where are we? Can we meet up tomorrow, I have a meeting planned up before lunch. I will try to get all the user information that you need. Why dont you start thinking about the user interface. See navigation is simple, I have worked it out...when do you think wireframes can be ready? I need to show proof-of-concept in June and a beta launch by October... I am sure you will come up with something really nice looking...I liked the one you did with our web-based console some time back. Ok see ya tomorrow.

But... but... users?

User-centered innovation

Understanding users (different from "customers") is a critical part of the innovation process that most technology companies in India either miss or are ignorant about. Today, this is one of the key reasons why Indian software services companies like Wipro and Satyam cannot produce innovative software.

Organizations believe that customers are users, however, in reality most customers are NOT users. As service companies, we focus on our customers but we completely ignore the users who will use the application or the product.

Typically, customers have no understanding of their users. This leads to:

• Open ended functional specifications that change during the development lifecycle
• Most functions get similar priority. Or, arbitrary allocation of priority so that functions that require least time to develop are developed first rather than those critical to the users.
• Non-use of many functions by users
• Non-completion or partial implementation of critical (read day-to-day) functions performed by users - leads to user dissatisfaction and huge number of support issues.

What do innovating companies do to understand users?

• They ensure proximity and access to users
• They make Ethnographic studies, contextual observations, and inquiry techniques a key part of software development process

Customers who are geographically near their users and have understanding about users' day-to-day functioning, motivation, goals, and environment are the only ones who provide innovating ideas - understanding users always trigger innovating ideas. Innovative technology companies understand the users directly or by employing user research consulting companies.

How will understanding users lead to innovation?

Any innovation can be traced back to change in the style of work or leisure. This leads to positive changes in the users' life. The process of innovation begins with deep understanding of what the users actually do, their characteristics, their needs, their motivations, their experiences with the world, and what they care about. Successful collection, analysis, and synthesis of user data triggers innovative thinking. The insights that businesses get about their users help them make innovative applications and products that users enjoy and recommend.