Archive for the ‘Getting started in design’ Category

Why “mom-centered design” isn’t an established discipline

It’s fun to work with beginning designers because they make fundamental mistakes so predictably. Perhaps the most enduring beginner mistake is to design for yourself. The key to user-centered design is to realize that you are designing for someone else and that all your decisions should be made from their point of view, not yours.

It’s so typical for a beginning designer to say “I would never do that.” If you then remind them that they are designing for their target users not themselves, they’ll often reply “OK then, my mom would never do that!” As if that somehow makes their case stronger.

What’s so wrong with designing for mom?

While we all want to please our moms, designing for our mothers is pointless (unless your mom really is the target user.) Despite the tremendous number of practitioners, there’s a reason why “mom-centered design” isn’t an established discipline.

You aren’t the target user, and neither is your mom. Imagine your mom walking into the cockpit of a jet aircraft and saying “All these dials and levers are really complicated—I would never use this.” True, but unless your mom is a professional pilot, it hardly matters. More typical examples are just as pointless, just less obviously so.

My mom would never fly this plane.

Another problem with mom-centered design is that it’s disingenuous. You are still designing for yourself or for your assumptions about your target user—you’re just using mom as a proxy.

We all do this

While I expect beginners to design for themselves, experienced designers often do it too. This is such an easy trap to fall into.

My mom would never drive this car.

In the discussion How not to design for user experience: the Ferrari example, the poster asserts “When the use of something as intuitive as a steering wheel takes a nine-minute video for just a brief overview, you’ve got a problem.” Most of the people leaving comments agreed. But this is a design blog and the commenters are all designers, and they are thinking about this design purely from their own point of view. If Michael Schumacher felt this way, then I would be concerned.

Yes, the Ferrari Formula 1 steering wheel is complex, but it’s designed for professional race car drivers whose livelihood totally depends upon winning races. They need the features—saving a second is a big deal. They have the motivation. They can spare the nine minutes to learn how to use it.

Real users aren’t you—or your mom

Different users have different characteristics. Here are some of them:

  • General computer knowledge (expert vs. novice)
  • Application and task knowledge (expert vs. novice)
  • Goals, tasks (what they are going to do)
  • Frequency of using apps, doing tasks
  • Vocabulary (to speak the user’s language)
  • Motivation (willing to make effort, endure misery)
  • Environment (data, scale, formality)
  • Age, physical abilities

Details like motivation make a big difference with respect to what users can or are willing to do. Having a clear understanding of these characteristics enables you to make better decisions on behalf of your target users—something mom-centered design can never do.

If you do only one thing:
Remember that user-centered design is all about designing for your real target users. Not you. Not your assumptions. Definitely not your mom.



Don’t design like a programmer

I sometimes say that UI looks like it was “designed by a programmer.” This isn’t some arbitrary remark—rather this is my cute way of describing a class of UI design mistakes that programmers are particularly prone to make. Contrary to claims made by Alan Cooper, I don’t think this style of UI is the result of some programmer conspiracy to inflict their ill will over hapless users. Rather, these designs happen because programmers find them easier to develop, don’t notice their usability problems, and often aren’t aware that there are better solutions.

New! By popular demand, I have posts that show what a good design looks like and how to get it. Please check Don’t design like a programmer, part 2 for a design process and Don’t design like a programmer, part 3 for the new design.

These designs usually stem from directly mapping a data structure into a UI and expecting the result to be usable. To see what I mean, let’s assume that we have a data structure like this:

     struct UserOptions {
          bool        Option1;
          bool        Option2;
          String      Option3:
          String      Option4:
          ...
     };

It’s natural to assume that a good UI might look something like this:

Now all you have to do is present this UI to the user, have the user provide all the information, and continue. Pretty straightforward, right?

While sometimes this approach works just fine, all too often it leads to a poor experience. Here are some of the reasons:

Data structure issues

  • Using variable or technology names as control labels The variable names work fine for the code, so why not use the same or similar names in the UI? The problem is that these names, often based on technology, may not be all that meaningful to users. Devices properties and settings are full of examples. For example, how many users know that “duplex printing” means print on both sides of the paper?
    Warning sign: Control labels based on technology rather than purpose.
  • Letting variable types determine control types The common data types of strings, integers, and Booleans readily map into text boxes, radio buttons, and check boxes. The problem is text boxes, being the most unconstrained control, require the most knowledge and effort for users. Mapping to richer, more constrained controls takes more effort for programmers.
    Warning sign: Overuse of text boxes and check boxes.
  • Exposing raw, unformatted data It’s much easier to expose raw data than to translate it into a format that is more meaningful or natural to users. For example, it’s easier to expose a raw date than a properly formatted date for the user’s locale. It’s easier to display a plain date than the useful, relevant information behind the date (such as days until deadline, age when an event occurred, etc.) Likewise, raw data like “1KNG 1BDRM EVO STE NSM” is easier to display than the more comprehensible “Evolution Suite with 1 King Bed (non-smoking).”
  • Warning sign: Controls display raw, unformatted data that requires users to translate.
  • Exposing representation invariants In object-oriented programming, a representation invariant is a set of constraints that a concrete data type must uphold to correctly represent an abstract data type. Simply mapping a data structure to a UI would expose the invariant and put the burden of enforcing the invariant on users instead of the code. A typical example is having to enter a phone or part number in a specific format instead of the program handling any reasonable input.
    Warning sign: Users required to enter data using a specific format.
  • Exposing special values A common programming practice is to assign special meanings to a special value, so, for example, a value of -1 might mean “not available” or “unassigned”. Simply mapping a data structure to a UI exposes these special values (typically through the control label), requiring users to know and enter them.
    Warning sign: Control labels that explain special values.
  • Overusing error messages A related problem is display error messages for the slightest input problem, regardless of how clear the user’s intent or easy the problem is to correct.
    Warning sign: Use of error messages for easy-to-correct input problems.

Simplicity issues

  • Not optimizing for the probable While from the code’s point of view any input is possible, from the user’s point of view not all input is equally likely. For example, while users could select any font, most likely users are going to select the last font, a recently chosen font, or a font chosen in the past.
    Warning sign: Not optimizing for the most likely input.
  • Over generalizing (the 0, 1, n problem) Programmers handle the absence or presence of something with a simple if statement, but handling 2 or more things requires a for loop. Exposing this generalization often leads to unnecessary complexity. From the programmer’s point of view, if you are going to design code to support a family, you might as well support a commune too. From the UX perspective, it’s far better to optimize for the common cases.
    Warning sign: Not optimizing for the most common number of objects.
  • Asking for what the code needs vs. what the user knows What the code needs and what the user knows might not be the same. For example, the program might want an airport code, but the user might know the city. Or the program might want the telephone exchange code, but the user might not know what that is (it’s the three digits after the area code). While it’s easier to present what the program needs directly, it’s better to ask for input that users can provide easily and confidently.
    Warning sign: Users have to look up information or need to use help to provide input.

Life cycle issues

  • Having baffling initialization Have you ever seen a large form where everything was initially blank and you had no clue what to do to get started? While zeroing out everything is a fine way to initialize a data structure, sometimes users need more than a blank form to get going.
    Warning sign: Initial UI state is blank and difficult to figure out.
  • Going all in Data structures reflect data types and hierarchies, but they reflect little else—they don’t reflect dependencies between members, or important vs. unimportant or required vs. optional values. Mapping a data structure directly to a UI would present all the data at once, without showing dependencies or optional values, or using progressive disclosure to hide infrequently used settings.
    Warning sign: All input is always displayed and always required, even if unimportant, optional, or dependent on other settings.
  • Having all or nothing Similarly, while all elements might belong together in a data structure, they don’t necessarily have to be provided by the user all at the same time. Mapping a data structure directly to a UI would require the user to provide all the information before proceeding, whereas a better experience would be to let the user proceed with the task with only the minimum amount of information, and gathering the remainder only when needed.
    Warning sign: Input is requested well before it is necessary.

Efficiency issues

  • Having a privacy hurdle If the data structure needs personal information or information that is difficult to obtain (such as having an account, finding an account name or password), users might be unwilling to provide such information—especially if such information shouldn’t be required to perform (or at least initiate) the task.
    Warning sign: Users are required to have accounts, log on, or provide personal information unnecessarily.
  • Avoiding excise Even if all the other factors work out, the UI could be annoying if displayed every time a frequent action is performed. Frequent actions should be designed to reduce or eliminate any hurdles, typically by assuming reasonable default values.
    Warning sign: Frequently performed tasks present an unnecessary dialog box instead of assuming defaults.
  • Handling scale Mapping a data structure directly to a UI might work well for a few variables, but the resulting UI can be a nightmare for dozens.
    Warning sign: Way too many controls displayed on a single screen.
  • Handling unexpected input Just because you don’t expect input in a certain format or find that format inconvenient doesn’t mean it’s wrong. If the user believes the input is valid, it almost certainly is. Check We cannot accept that behavior for an unpleasant but all-too-common example.
    Warning sign: Unnecessary restrictions on input formats.

If you do only one thing: Think about UI as a means for users to achieve their goals and perform their tasks, not as a means to fill in data structures or make code happy. Poorly designed UI requires users to translate their goals into what the UI needs, whereas well designed UI does this translation for them. What at first appears to be easy and obvious UI design may prove to be a poor experience from the user’s point of view.

A challenge

How many of the above problems can you spot below?

Yup—this looks like it was designed by a programmer. For starters, notice how nearly all the controls are text boxes and check boxes because they map directly to the underlying data structure. While this UI has problems outside of those mentioned in this post (such as poor communication, task flow, and layout), fixing the core problems first will make other problems easier to solve.

Want to see how to do it right? Check out Don’t design like a programmer, part 3.

A bonus challenge

The User Options example has 6 minor guideline compliance problems. Can you find them?

Want to learn more? Check out UX Design Essentials and UX Design Basics

If you would like to learn how design UIs the right way, please consider taking my UX Design Essentials course or my online UX Design Basics course. I’ve designed both of these courses to help non-designers get started in UX design.  I’ve only scratched the surface here.



Getting started in interaction design

“I’m a software developer and I just started working on a project that needs a good UI. I don’t have a UI design background and nobody on my team does either, but I know enough to realize that our current design needs a lot of work. I’d like to help make it better. How should I get started?”

This is a popular question. While there are many things you could do, here’s what I recommend:

  1. Pay attention to design Design, both good and bad, is all around you so pay attention to your everyday experiences. If something works well or doesn’t work well, try to understand why. To develop your design thinking, make note of what is “intuitive,” what confuses you, what delights you, and why.
  2. Know where you are on the UX design skills ladder Understanding the ladder will help you develop a road map to get to the next skill level. It will also help you work more effectively with people with different skills by understanding where they are coming from.
  3. Design for your users, not yourself The most common trap for beginners is to design for themselves. It’s also common for intermediates to think that they are designing for their users but design for themselves instead. An easy way to tell the difference is to gather your team and write down all the known facts and assumptions about your target users, then validate your design decisions against the list. If, for example, you are targeting beginners but some features require advanced knowledge, you’ve got some work to do.
  4. Work with more than one design idea The second most common trap is to fall in love with your first idea and, as a result, fail to see other possibilities. Design is about making choices, but you can’t make a good choice unless you have options to choose from. Considering alternatives also helps you build confidence in your decisions. But if your first idea is so good that you can’t possibly think of anything better, at least design a simpler version of that solution. Chances are you’ll like it better (and prove to yourself that there are alternatives.)
  5. Think in terms of users and scenarios, not in terms of features and technologies A scenario is a description of a user’s goal, problem, or task in a specific environment. Great design focuses on nailing important scenarios. By contrast, weak design focuses on individual features and technologies, without much regard for the user’s goals, tasks, or environment.
  6. Make priorities It is literally impossible to focus on everything. Good design establishes clear targets and nails them. Poor design is undisciplined and tries to do everything for everybody. You can’t do everything, and you certainly can’t do everything well. Do less better instead.
  7. Learn to communicate to users effectively Great designs communicate their purpose well. This is what people really mean when they say a design is “intuitive.” Think of your UI as a conversation between you and your target users.
    Does your design communicate well? Here’s a simple test: suppose you are looking over a user’s shoulder and he or she asks, “What should I do here?” Think about the explanation you would give—the steps, their order, the language you’d use, and the way you explain things. Also think about what you wouldn’t say. That’s what your UI should be—like a conversation between friends—rather than something arcane that users have to decipher. If the UI feels like a natural conversation, your design communicates well.
    Many developers avoid thinking about UI text, and assume that any problems can be fixed by somebody else later. Wrong!  If the communication is poor, the design is poor—and quite often such problems can’t be fixed by just tweaking text. Effective communication is an essential element of good design, not an add-on.
  8. Look for design models What existing products or services have a similar experience? This is helpful question when brainstorming or identifying design alternatives. The design models don’t even have to be remotely related to what you are doing—a particular experience at Starbucks might be a great design model for purchasing your accounting product. The key is to understand that the goal isn’t to copy other people’s ideas but to inspire you to consider the full range of possibilities.
  9. But don’t design by copy Another trap for beginners is to design by copying features that you like. While at first this approach seems logical—if the design works and you like it, why not use it? The problem is that design is all about making good choices on behalf of your target users to create a product that satisfies their goals. Design-by-copy often fails because it short circuits this user-centered thinking by focusing on features—features that may have been designed for different users with different goals in different environments.
  10. Ask for feedback Ask people who represent your target users (or at least neutral observers) to review your design and provide feedback. Review their feedback, look for trends, and refine the design. If you design without getting feedback, there is a good chance that you’ll make many mistakes. I try to get feedback on everything.
  11. Learn how to receive critical feedback Critical feedback is required to do your best work, but not all feedback you receive is going to be encouraging or well presented. Regardless, smile, thank the person for helping you, take the feedback seriously, follow up on it, and encourage more.
  12. Learn to give good feedback—based on something other than personal opinion Feedback is a two-way street, so it’s important to learn how to give good feedback as well. If someone asks for your feedback about a design, it’s inevitable that at least some of it will be personal opinion. However, feedback based on scenarios, design principles, guidelines, and such are far more useful, especially when there is disagreement within a team. For example, think of the top tasks you can perform with a product, and present your feedback in terms of the issues you found while performing those tasks. While such feedback might still feel personal, it’s not just personal opinion anymore.
  13. Learn to appreciate good design It’s easy to criticize bad design—anybody can do that. A more useful talent is to understand what makes a good design good. When you see a good design, examine it carefully and try to understand why specifically it works so well. Think about the project management angle too—consider the team leadership and design process required to make that good design a reality. It didn’t just happen by itself.
  14. Learn to appreciate bad design It’s easy to sneer at bad design—look at how silly those people were…what were they thinking? Of course, we would do so much better, right?
    Not necessarily. There are many traps in the design process and we are all bound to fall into them eventually. When you see a bad design, examine it carefully and try to understand what went wrong behind the scenes. Did they try to do too much? Was it designed by non-designers? Was it designed by committee? By the boss? For the boss’s mom? Did they design around features and technology instead of users and scenarios? Did they not do any user testing? Was the schedule unrealistic? Did they rush to market? Bad design happens for a reason, and many of those reasons extend well beyond design skills.
  15. Continue to improve your skills Read books and blogs about UX design. Read up on interaction guidelines. Take a design course. Hire a design consultant to help you get started.

If you need professional help with any of these skills, please let us know. We’re here to help!



Why “everybody is a designer”: The UX Design Skills Ladder

I started to write an article on how non-designers can get started in interaction design, but quickly realized that Tip 2, “Know where you are on the UX design skills ladder,” is worthy of its own post.

The UX Design Skills Ladder has several constituents:

  • The ability to recognize problems
  • The ability to identify solutions
  • The scope of design knowledge
  • The method for making decisions
  • The ability to give and receive feedback
  • The ability to persuade others

Here it is:

Level 0—”Everybody”

  • Can identify general, superficial problems with a design.
  • Thinks of design in terms of technology.
  • Believes “user centered design” means designing for the one’s mother, sibling, or spouse.
  • Gives vague, often harsh feedback, usually in terms of personal opinion or preference.
  • Offers feedback that is often inappropriately detailed, focused on minor visual details.
  • Is unaware of what they don’t know.

Level 1—Beginner designers

  • Can identify basic interaction and visual design problems.
  • Thinks of design in terms of technology and features.
  • Works with a single solution, rarely considers alternatives. Often that single solution is their first idea and they have trouble seeing beyond it.
  • Makes one-off decisions based on whatever “feels right.” Often “wings” it.
  • Offers feedback in terms of personal opinion or the behavior of other programs.
  • Can convince self that a design idea is good.

Level 2—Intermediate designers

  • Can identify many interaction and visual design problems. Aware of what makes a design good.
  • Thinks of design in terms of tasks.
  • Usually works with a single solution, but occasionally works with a few.
  • Makes decisions based on data, team feedback and consensus, and the problem at hand. Still often “wings” it.
  • Offers specific, actionable feedback at the appropriate level in terms of design concepts.
  • Can convince several people that a design idea is good.

Level 3—Advanced designers

  • Can identify subtle interaction and visual design problems. Has a strong appreciation for good design.
  • Thinks of designs in term of scenarios and personas.
  • Always works with many solutions before making a choice. Proposed solutions include standard approaches, simple solutions, and innovative alternatives that others would miss.
  • Makes decisions using a decision making framework and a holistic product vision. Often uses data to make decisions, but is willing and able to go beyond the data.
  • Offers specific, constructive, actionable feedback at the appropriate level in terms of design principles, guidelines, branding.
  • Can convince a team that a design idea is good. Experts can convince a team that a radical design idea is good.
  • Is completely in tune with what they don’t know.

Some observations

  • Level 0 Everybody has at least level 0 design skills, which is why “everybody is a designer.” Unfortunately, these skills are neither rare nor particularly valuable but people at this level are blissfully unaware of this fact. They often think their vague, unactionable feedback is brilliant. For example, they’ll say things like “My mom would never do that” or “I don’t care for that color red.” Brilliant! They also tend to be managers.
  • Level 1 Most people experienced with “design thinking” are at least at level 1.
  • Level 2 A surprising number of people are at this level, even designers with many years of experience.
  • Level 3 This level of design skills is fairly rare. Many people think that they are at this level but aren’t quite there yet. For example, I’ve noticed that many who think they are doing user-centered scenario-based design are really doing feature- or task-based design. (The difference? Check Design scenarios—and how thrilled users ruin them.)

Why this helps

Knowing the ladder will help you in a variety of ways:

  • It suggests a road map on how to improve your design skills.
  • It helps you understand other people’s design skills better so that you can work with them more effectively.
  • It helps you evaluate other people’s design skills for things like job interviews.

If you do only one thing: Know your UX Design Skills level and make a plan to get to the next level.

Next week, we’ll look at how non-designers can get started in interaction design.



Welcome to Everett’s Interaction Design Blog

UX Design Edge is all about helping teams with minimal design resources (usually none!) do their best work, primarily through interaction design consulting and training. Consequently, I will focus the blog around this theme. If you are a non-designer who wants to learn about design and help your team deliver the best product UX it can, you’ve come to the right place.

To accomplish this goal, I plan to focus the posts on the following subjects:

  • Getting started in design
  • Understanding basic design principles and guidelines
  • Using design tools effectively
  • Improving poor design
  • Appreciating great design
  • Getting from bad UX to good UX
  • Getting from good UX to great UX
  • Doing design makeovers
  • Answering the interesting interaction design questions

For the last two subjects, I need your help. If you have simple design makeover or interesting interaction design questions, and you don’t mind sharing, please send them to me!

Beyond this, I have two more goals:

  • Post something new every Monday.
  • Maintain a sustainable pace.

A sustainable pace is important. The world doesn’t need another abandoned blog.

Please stay tuned. This is going to be fun!



For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge