User Interface Design

Chapter 3 of the book Design Interactions was called "The Zen of Palm".  On page 216 is an excerpt of what I found to be simple yet profound:

Rob articulates his design approach as a philosophy, but he also supports his philosophy with a very pragmatic design process: first understand the customer, then prioritizes ruthlessly:
One bit of advice that I gave to people designing the Palm OS was, "If you can really understand the one thing your customer wants to do most frequently, and make that a one-step process, then I guarantee people will like the product."
     Just say, "What is the one thing you want to do?" and even if you have to throw out conventions of logic, architecture, and hierarchy, you should make that one step.  The more "illogical" your approach is, the less likely it is that it will blindly follow the conventional wisdom, and hence the more likely it becomes that you will be able to differentiate and create a successful product relative to your competition.  If you take the conventional approach, by definition you're not innovating.  If you just say, "Here are all the features," and you lay them out in a logical pattern, then that's not going to be a successful product.

Before the iPhone, my mobile device of choice was the Palm Treo 650.  I used to love the Notes app and the To Do list app.  And to this very day with something so simple as a to do list app or a notes app, I haven't been able to find a third party solution where I was satisfied as much as the Treo.  I am convinced that it is because I experienced the ingenuity of the applications that Rob has designed in the palm with his philosophy of: "really understanding the one thing your customer wants to do most frequently and make that a one-step process".  I find it very interesting that similar applications have come out years after the palm but it does not meet the quality of design that palm had in its software.  And he hits it right on the nail.  Some of the most frequent things you want to do with software take several steps to complete.  And today I still wish I had those applications on the Treo that the iPhone doesn't have. 

Rob Haitani, you are a hero of user interface design in my book.

Common mistakes are apparent when looking through dozens and dozens of web 2.0 applications popping up recently.  Below I describe 5 and for each of the 5 mistakes, a question is included in order to start thinking about the solution to common mistakes.

1. Intended Audience Is Ambiguous – If you are a start up, your intention is to rapidly increase your user base.  You want every visitor to turn into a dedicated user or refer your site to someone they know.  But if it’s difficult for that very visitor to understand who the intended audience is within 6 seconds or less, then good luck in getting visitors to sign up or refer you to someone they know.  Question: Based on the design of your home page, who is the intended audience according to your visitors?
2. Valuable Scenarios Are Missing – Question: In what scenarios would your users find your product incredibly valuable?  Why make visitors wonder when the application would really come in handy!  Tell them.  I often wonder this myself while perusing a new application featured in a news or a blog site.  If I can’t think of scenarios that would personally help me, I don’t sign up. Do you?
3. Benefits Are Not Communicated – Question: What is the clear cut benefit for a visitor to start using the application?    And how is this apparent on the page?  Some ways this is done:
   1. Graphic – See Graphic on CrossLoop, it gives you an idea of who and what situation it might be used immediately
   2. Feature List – Have a convincing list of features that show this could help people.  See Mint.com how they present their beneficial features
   3. Demo – A video demonstrating how it works, sure beats signing up.  ReviewBasics.com quickly shows their product in a video.
4. Benefits Are Not Demonstrated – Question: Can people see that the application is delivering what it’s promising?  Visitors are impatient.  If they don’t see immediate results they aren’t convinced.  How do they know that a new social networking site is rapidly connecting people?  Are there user profiles that show that?  Or do users have to do a lot of work themselves in order to see the benefits?
   
5. Call to Actions Do Not Cover Multiple Phases – Question: What is it that you want the visitor to do in each step of the conversion process?  The answer is usually very simple: sign up to a service, register for a user account, participate in discussions, etc.  The execution and design of the calls to action are however, are much more difficult.  Different visitors are at different phases of the decision-making process.  The design has to support all of these decisions well.

The answers to the above 5 mistakes won't be solved overnight.  Different applications will have different ways of providing answers to the above problems.  But the sooner the visitors see or experience the answers to the above problems, the faster they become users or go about referring others. 

I have been reading Emotional Design by Dr. Don Norman, a professor of cognitive psychology and well respected figure in usability.  His book peaked my interest recently because in my career from graphic designer, web designer to web developer, I have always been told that as far as aesthetic design goes:

"You're just making something look pretty."

But Dr. Norman tells us differently.  Major take aways right off the bat:

• Two Japanese researchers tested usability of the same ATM application one simply more aesthetically pleasing than the other.  They found that the interface which simply looked better produced better usability results.
• Doubting the study, an Israeli scientist took the same study, translated all the Japanese text into Hebrew and ran the study again.  Bolder results confirmed the original study.
• Attractive things work better because it:
  • Affects our effort - We as humans become emotionally attached to aesthetically pleasing interfaces so we try harder to make it work for us.  We like the inteface so we keep trying even if things don't work the first time.
  • Affects our ability - Aesthetically pleasing interfaces put us in a better mood which in turn affects our ability.  If we are in a better mood, problems appear easier to solve and alternative solutions arise easier than in a negative, nervous or uncomfortable state of mind.
  • Effort and Ability Affect Performance - It makes perfect sense that further effort and better conditions to improve our abilities will result in better performance.

Read Dr. Norman's web article on why attractive things work better in further detail. 

I went to a Seattle SIG CHI (Computer Human Interaction) event to hear Jake Knapp, a user interface designer from Google.  From my point of view there weren't any groundbreaking tips, tricks that I haven't heard of before in the world of user interface design.

Some points from the presentation that you might be interested in, especially regarding their product development strategy:

• Ethnography and user research - Ethnography, is the study of people and their environment and stems from social science.  The key idea is you find opportunities not only by what people say but just as much from what they don't say.  Google, much like other companies i.e. Microsoft uses ethnography to identify unmet needs by first studying people.
• Sharing research findings with company employees - The researchers share the valuable information to the team.  I have seen Microsoft use the same practices as well.
• Brainstorm as a team - At their research meetings, the team starts to brainstorm how they can solve unmet needs
• Prototype from paper to mock-ups - The UI design team starts to prototype on paper and then moves forward into more detailed interactive prototypes
• Usability Study - Usability testing is done on prototypes, products in development in an iterative fashion

The above strategies are common in user experience and with the type of products that Google are coming out with these days, it validates the process of user centered design even further.

Interesting Tidbit #1: From one designer to another:
It was comforting that Jake was talking about the same thing I had experienced just a week or two ago in one of his slides.  When there are many design issues and uncertainties to address, he goes back to prototyping on paper.  Whether it's flash, html or visio protoypes, even when you are building a mock up, it's easy for the designer to get caught up in the details:  Where do I align this button?  How do I label it?  Will the user see this on their screen?  These questions aren't important in the early stages if the design concept in general has yet to be proven because the design can radically change.  I found that paper prototypes work wonders here.  He was recommending the same.

Interesting Tidbit #2: Positive Reinforcement in the Bathroom
I ended up having to use the restroom at their office.  I once read that Google posts printouts or leaflets in their bathroom stalls.  Indeed they do!  I was amazed that the printout talked about how at Google, our #1 principle is to focus on the user and all else will follow.  The printout went on to talk about how it's important to question about the target audience, their unmet needs, their behavior and so on.  I was impressed.  I would call this, encouraging the "Cans" at the Can.  Good job Google. 

I have always loved this comic!  I've seen this with so many projects after the fact.

Technology Acceptance Model 

Although written in 1997, this work: Morris, M. and Dillon, A. (1997) How User Perceptions Influence Software Use. IEEE Software, 14(4), 58-65 has great relevance today.  They present the Technology Acceptance Model (TAM) as a great way to see whether potential customers will use your application in the future.  You can ask your potential users questions based on these four factors:

• Perceived usefulness - "the degree to which a user believes that using the system will enhance his/her performance"
• Perceived ease of use - "the degree to which the user believes that using the system will be free from effort"
• Attitude Toward Using Your Application
• Behavioral Intention of Using Your Application

The above diagram illustrates how these factors are related. Asking questions on these 4 factors is far more effective than bluntly asking users "how likely is it that you will use this application in the future?"  The other major benefit of course is that the above set of questions allow you to drill down on what area needs work in your application. 

Usability studies alone are by and large focused on completion of a series of tasks and it doesn't focus as much on user's perceptions, which according to this research, is the driving force behind whether a customer will use your application.

"TAM has been shown to be extremely successful in predicting whether systems will be successful. Because of its simplicity, it offers a cost-effective tool which can be used to evaluating systems throughout the system design lifecycle."

Have you ever developed an application or was part of one where you delivered exactly what the customers wanted and they weren't satisfied?

I have seen it time and time again.  In fact I'm part of one right now where one my ex-team mates developed an application that does not meet the expectation of the customer.  We are re-developing major areas of the application and essentially starting from scratch.

What went wrong?

Customers often do not know what they want and even if they did, they have a hard time articulating what they want.  They don't understand the technology. What people do on a daily basis is so natural for them, it is difficult for them to articulate what they do themselves.

How do you approach your customers if they don't know what they want?

1. Find out the details of their activity - ask your target audience how they go about their activity.
   
2. Diagram the activity - Ask until you can create a diagram of their process
3. Verify the activity - Take the diagram and confirm it with your customer
4. Clarify Your Understanding - Ask about any oddities with the activity or process, or find out why they may do something one way over another
5. Be Your Own Judge - Now that you have mapped out your customer's process or activity, you can be the judge for yourself if what the customers are asking actually HELPS their own process o activity.
6. Map out improvements - You should THEN be able to map out a new diagram of how their activity will be easier or better with your product.
   

The bottom-line is, if you cannot diagram how your customers lives will be easier with your application, it probably isn't going to make their lives easier.  If you still are not convinced, here are 5 reasons why every developer or web entrepreneur must create a workflow or activity diagram of their users.

1. Get it right the first time

If you don't you're in for a real treat. Most likely you'll have to redo certain areas of the application or quite possibly the whole entire application.  I have been in several situations where the previous developer didn't analyze the customers business in depth and whatever comes out of the development process does NOT get the job done for the customer.  What does that mean?  An application that has to be re-created or go through a major overhaul.  NOTE: This is very expensive.

2. Identify opportunities

To continue on from the first point, if you map out how your users currently work, there is no doubt you will find opportunities for how they could improve their process.  This is what users cannot articulate and what technologists can.  The best part is, some of these opportunities maybe much easier to implement but could be highly appreciated by users. By finding out how the user's work, you can also remove some of the painstaking features that the users were asking in the first place.

3. Increase user base faster

Making your users happy naturally makes them want to spread its usefulness by word of mouth.  But not only that, if you know how they currently work, it makes it much easier to communicate to your target audience why your application is worth using to them.  You don't need a hard sell.

4. Developers get on board faster

Like the old saying goes, a picture paints a thousand words.  Even among people who love and create technology, most all would prefer to see a diagram of how users work rather than read a 10 page specification document.

5. Developers are much more effective

Not only do developers get on board faster, they understand how certain features that they are developing will help the user's process.  The reason they are developing a feature is not because "AJAX is hot and every new app is using it!"  The reason is: "This is how our target audience currently works and this is how they'll be far more effective with our product.