Good Pre-Design Questions

Who:  Who is the typical user: the audience.  Do you really understand them?

What: What do they want or need to do? What are their tasks? What are their motivations?


When:  Temporally, how does one task follow the other? When is a task begun? When does it end?

Where: Where is your solution to be used?  A UI for a refinery floor that the operator uses while wearing gloves will be different than one that's used primarily from a cell phone.


Why: Why does the user do what they do; what are their "goals" and motivations? 

How: How do the users currently carry out their tasks? A lot can be learned about their expectations by fully understanding how they currently work.

Useful vs. Usable

 "Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union." - Frank Lloyd Wright.

“Design is not just what it looks like and feels like - Design is how it works.” - Steve Jobs

As a UX designer, to what extent do you defining what the system does as opposed to just how users interact with it?  You can see the implications of this question exemplified by a quote I heard somewhere The quote goes something like this:

If you can give me an application that can accurately predict tomorrow's stock market, I'll put up with the grossest usability issues, even a command line interface. On the other hand, if you give me an application that tells me what already happened on the market, it better have better UX than the one I currently use or I won't switch. 

If anyone knows to whom this quote should be attributed, I'd be grateful to know. I'd like to hear more from this person. It says to me that while good design is important, without useful functionality, it's not sufficient. As Frank Lloyd Write says, form and functionality need to dovetail to provide the UX. 

A few thoughts around providing appropriate functionality:

• gather market or user research to validate that the primary functionality is seen as useful
• perform task analysis with users to understand their needs completely. Prioritize those tasks and ensure functionality is provided for the most important tasks. Focus your UX efforts on the support for the most important tasks
• Where is the competition in terms of functionality? Do you compete with new or improved features or do you provide a better experience for already established features?

Designer != User

 "Designers are not users." Jakob Nielsen.

  "A design isn’t finished until somebody is using it." Brenda Laurel.

 "The user’s time is more valuable than ours. Respect it. Good UI design is humble.” Jono DiCarlo.

When designing, there is a strong tendency to revert to a line of thinking like

• 'what would I like it to look like' or 
• 'how would I expect it to work'.  

But, of course, it's most often it's the case that you're not the user! As designers, unless we have actual users on-site, we're often forced to make many assumptions about how aspects of our design will meet user expectations.  Our unvalidated design assumptions can be wrong in two divergent ways. 

We can assume that a particular design will cause problems with users. As designers, we sometimes ask far too many questions and therefore over think a design.  I run into this problem often. I think things are more complicated than they actually are.  There was a study (sorry, I don't have the reference) that looked at the accuracy of designers' prediction of usability issues vs. what actually happens when the design is tested.  The result was astounding. Something like 75% of design points designers felt would be usability problems were not born out in testing with real users.

The opposite is also often true.  How often have you been totally surprised when user after user stumbles over a part of your design that you were certain was fool-proof?      

So what to do?

• create personae for the various potential user types
• Recognize and list the assumptions you're making in your design
• recruit test subject that match these personae 
• talk to a few of those users, try to understand  their mental model of the problem space, and keep their mental model (not yours) in mind when designing
• test, test, test -- ensure your assumptions are validated or refuted through user testing  
• Lose your ego.  Finding your design assumptions are incorrect is par for the course

Can Design Solve Everything?

When I started this blog, I said its purpose was primarily to help me sort out my own thoughts and experiences with UX design.  This post is one where I'm truly torn between idealistic and a practical ways of thinking about the scope of design. Let me apologize in advance if this post seems a tad negative.   

One extreme says: everything is designed. Design, therefore, can solve most problems.  Certainly, people like Tim Brown espouse this broad and idealistic position. "Design thinking", they might say, broadens the breadth of design's scope will solve the big problems the world faces. I agree with this. I'm not sure how one could disagree. 

One the other hand, most UX designers today face hard deadlines; incomplete or nonexistent requirements and user input; restricted budgets; political infighting between various disciplines on development teams; responsibility for design without ownership of design; or a development environment where application of lipstick to a fete de complete bulldog is all that can be realistically accomplished. Is it your job as a UX designer to redesign the business, requirements, and development processes?

I don't mean to set up a false dichotomy here. Broader design thinking is the obvious evolution of the design discipline. But what does the lowly UX designer do while we await the required epiphanies in our organizations? A few thoughts:

• Document design and process trade offs you're making and ensure the stakeholder understand the trade offs being made and why.
• Document design assumptions when there's no user data to back up your hunches. State the potential consequences to the user and the bottom line.
• Educate the stakeholders. Lobby for improving processes outside your realm of responsibility by sharing easily understood and implemented ideas.

I'm sure there's more we can do. I'd love to hear about your approaches.

Work well with other disciplines

 "Decision by democratic majority vote is a fine form of government, but it's a stinking way to create." Lillian Hellman. 

 "To turn really interesting ideas and fledgling technologies into a company...it requires a lot of disciplines." Steve Jobs.

If your title is "Interaction Designer", consider it lucky that you role is defined so specifically.  How steadfastly do  you stick to that role? How protective are you of other team member treading on your turf?

Thing is, the various roles on software design and development teams have overlapping skills to some degree. It's to everyone's benefit --and the product's benefit-- to recognize these overlaps rather than fighting over whose toes are being stepped on.

For example, visual (or graphic) designers and interaction designer often have UI pattern skills in common. Interaction designers and UI developers often share a good understanding of a widgets set's capabilities. Information developers often have the task-focus of an interaction designer and can easily recognize a poor design as they've had to save "poor" design through documenting work-arounds so often.

Ultimately though, when there's a design problem to be solved and there's no time to poll or test users on the issue, one person should have the authority to make the decision.  It's not always appropriate for the team lead to be the final arbiter as they may not have the skills to decide on all issues. Nor is it ideal for the strongest personality or most outspoken team member to be always making the call.

I've been on many teams with overlapping skills over the years. Some teams were able to easily come to consensus and other were always at odds. The best teams have always shared the following characteristics:

• the members did not protect their ego (see an earlier post: Lose your Ego)
• the team lead decisions are made by the appropriate discipline
• the person deciding shares the rationale for the decision

This way, all opinions are heard, conflict is minimized, all members can feel they've contributed and the best ideas are implemented.

Simplicity

"Any darn fool can make something complex; it takes a genius to make something simple." - Albert Einstein

“Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.” - Charles Mingus

 "No matter how beautiful, no matter how cool your interface, it would be better if there were less of it." - Alan Cooper.

It would seem intuitively obvious that a product that exposes fewer design facets to a user is going to be easier to take in, absorb, and understand than a product with a thousand bell and whistles. Yet, we continue to produce function-laden products and products with overly complex designs that confuse and dissatisfy users. There may be a number of reasons underlying this phenomenon including the perception that the more features available, the more useful the product. Design for simplicity actually requires some hard work.  Here are some approaches.

1. Ask a few questions about the function itself: 
• Is this function really needed? Is there user feedback that substantiates the need?
• Is the function included to simply meet a competitor's offering. Do we know that their customers find this function useful?
2. Sometimes the implementation is being inappropriately pushed into the user interface. Consider making this type of functionality automatic or behind the scenes.
3. When facing a design problem, consider eliminating the problem rather than doing more design to fix it.
4. Hide advanced functionality initially and allow more advanced users to opt in.
5. Avoid visual clutter; have sufficient white space.
6. Most important or commonly used items should get top billing.
7. Avoid deep levels of navigation where possible and appropriate. 
8. Focus on shortening the steps for the most important or repetitive user tasks.
9. Last but not least: test it with users! 

These are just a few suggestions. I'm sure there are many more. Let me know your techniques.

Lose Your Ego

As a designer, your hard work will be easily and often challenged. I can be really disheartening when you've worked incredibly hard to create what you think is an elegant and engaging solution to a design problem and customers, stakeholders or user test subjects pick it apart. On the other side, when reviewing someone's design, it's so easy to see remaining design issues while not really appreciating or pointing out all that is right with the design.

If you have a big ego and therefore you easily become defensive, it'll get in the way of hearing any constructive criticism offered up. Some tips:

• you don't hold a monopoly on good ideas - welcome criticism and others' thoughts
  
• try to stay objective and evaluate (with rationale) others' ideas against your own
• don't become too attached to your design; it'll need to change
• don't design in a vacuum, seek feedback