UX Design Edge

Don’t design like a programmer, part 2

In my original Don’t design like a programmer post, I explored a common UI design trap that programmers often fall into, where you have a data structure, map that directly to a UI, and expect the results to be a good user experience. Sometimes that approach works just fine, but often it does not. The original post explains the potential usability problems in detail. This is an easy trap to fall into if you are thinking about the code instead of your users. As a developer myself, I’m very sympathetic here.

Someone named pankratiev put a link to that post on Y Combinator Hacker News and my site traffic just exploded—so much that my web host couldn’t handle it. (Thanks pankratiev! Please do it again!) While the feedback and comments have been positive, the top request was to show examples of good designs too.

I will start that challenge with this post. I finish with a proposed design in Part 3.

First, the original designs

Here’s the first UI in the post:

Actually, I didn’t say this was a bad design—rather I showed how this UI is a direct mapping of this data structure:

     struct UserOptions {

          bool        Option1;

          bool        Option2;

          String      Option3:

          String      Option4:

          ...

     };

I made this example generic to focus on showing how a programmer might map a code directly to UI. Is this a good UI? Impossible to say without knowing more, but the original post gives reasons why the odds are against it.

I then ended the post with this example:

I chose this wGetGUI example because it so clearly illustrates several of the problems I mentioned in the post. For example, note that almost all the controls are text boxes, check boxes, and command buttons, which map directly to strings, integers, Booleans, and function calls. You can just see the underlying data structures that need to be filled out:

     struct RetrevalOptions {

          bool        NoClobber;

          bool        Timestamping;

          bool        ContinueFileDownload;

          int         Quota:

          ...

     };

This is the UI everyone wants me to redesign—to something that doesn’t look like it was designed by a programmer. There are some problems with this task though:

• A good design requires applying a process, not jumping to a solution.
• A good design requires understanding the target users and their goals, top tasks, environment, etc.
• Unfortunately, I’m not a target user and don’t know anything about the target users and their goals, etc..

And as a courtesy to the wGetGUI developer, I really should add one more:

• It’s presumptuous to redesign somebody else’s UI without being asked.

So for this post, I’m going to outline a process but not attempt to improve the original design. This might seem like a cop out, but it’s actually the first key takeaway:

Key takeaway #1

You can’t significantly improve a user experience if you don’t understand its target users.

Sure, I could possibly make some minor improvements to the labeling, layout, tasks flow, and control usage, but that is hardly a giant leap for design. It’s not like changing a check box to a pair of radio buttons is going to be a big revelation.

UX design CSI: Focusing on the code is backwards

At this point, I’m going to take full advantage of fact that I’m not a wGetGUI user and look at the design from a fresh perspective. If I were more familiar with the tool, it would be easier to rationalize the design.

Key takeaway #2

Target users aren’t you. They have different knowledge, goals, and preferences.

My first observation about this UI is that I haven’t a clue what to do with it. A programmer might say “Well of course not, you haven’t read the documentation. RTFM.”

Key takeaway #3

Good UIs are self explanatory. Users shouldn’t have to read a document to figure them out.

I’m wondering what the tool is for. Shouldn’t the UI explain itself? Why should I have to figure it out? (Update: I tried to deduce what the tool was for, then later RTFM. Turns out I was completely wrong!)

Key takeaway #4

Don’t make me think…I shouldn’t have to figure things out using thought and experimentation.

Note that this UI presents settings and commands, but no obvious tasks. What are the tasks…what I am supposed to do? Am I supposed to know everything already?

Key takeaway #5

Good UIs are task centric, not feature or technology centric.

Just as the UI reveals how the programmer mapped the data structures to the UI, it also reveals the design process used. Something like:

Code -> UI

Instead, the process should look more like:

Target users -> goals -> tasks -> UI -> code

Key takeaway #6

The UI drives the code, not the other way around.

Starting with the code gets it backwards.

A process for doing it right

I’d now like to outline what the “target users -> goals -> tasks -> UI -> code” process might look like. There is any number of ways to do this, but I’ll outline a process that a programmer could actually use. No masters degree in design or UX professional staff required.

1. Define the product. Write a short paragraph to explain what the product is for. What is its value?  How does it differ from existing solutions? Why does the world need it? Why will people care?
2. Define the target users. Write a short paragraph to define the target users and their relevant characteristics.
3. Define the user goals. Write a short paragraph to explain why the target users are going to use the UI. What goals do they have? What problems are they trying to solve? What is going to satisfy them? Disappoint them?
4. Define the top user tasks. Write a short paragraph to outline specifically what the target users are most likely going to do. Focus on the top six or so tasks—not everything that might be possible. If you have defined more than six, you’re not focusing enough.
5. Define the user’s context. When and where are they doing these tasks? What facts do they know and data do they have? What do they not know? What other tools are they using? What other solutions are available?
6. Explain each top task to a friend. Suppose that you are explaining each top task to a friend who is a target user. Pay attention to how you would explain it: the steps, the order, the details, the language you would use, etc. Also pay attention to the things you wouldn’t bother to explain. The way you would explain the task in person is the right way to explain the task in the UI. This explanation drives the remaining steps.
7. Map your natural explanation into a page flow. Break that task explanation into steps, give each step a title that explains what the user is supposed to do, and list the elements required to do it. Don’t worry if you aren’t sure yet or if only one page is required. You can revisit this step as needed.
8. Design each page. Start with the page with the title that explains its purpose (exception: skip the title only if the purpose is so obvious that the title is silly). Give the layout a natural left-to-right, top-to-bottom flow. Start the task in the upper left corner or upper center. Emphasize the elements that need emphasis, and deemphasize those that don’t. Put related elements together so that their relationship is visually obvious. Map the interaction to the simplest, most constrained controls that do the job. To simplify the page, consider displaying optional elements on demand. Make the control to complete the task or advance to next step obvious.
9. Simplify and optimize the task flow and pages. Evaluate the design to make the operation simple and natural. Remove unnecessary effort or knowledge. Try to eliminate any frequently repeated actions. Provide reasonable default values. Take full advantage of previous user input, and avoid having users reenter information. Prevent input and other types of errors. To simplify, focus on what users will do instead of what they might do. Visually, remove unnecessary visual elements (like boxes, lines, 3D, meaningless icons.)
10. Review the communication Now compare the design to what you did in Step 6. They should match—after all, that’s the way you would naturally explain the task in person so any discrepancies suggest problems. For example, if you mention five options in your explanation, but your UI always offers 40, you’ve got a discrepancy.
    Make sure the purpose of each page and control is clear. Sometimes adding a word or two makes a huge difference. But don’t worry: the goal isn’t to have a lot text, but rather less, better text. Iterate as necessary.
11. Review the results. Now compare the design to what you did in Steps 1 – 5. Does it fulfill its purpose and provide value? Does it enable the target users to perform their top tasks to achieve their goals in their actual context? Any discrepancies suggest problems. Iterate as necessary.
12. Test with real users. You’ll never be sure that you’ve got it right until you test with real users. There are many ways of doing this, but direct observation is important. People have a tendency to blame themselves for mistakes, so they might not self-report all problems. Iterate as necessary.

Done!

If you design like a programmer, you might be doing a little of Steps 7, 8, and 9 before you start writing the UI code. That’s at best—at worst you are skipping all these design steps and going directly to writing the code. If so, mapping the data structures that the code needs to directly UI will be an obvious, natural thing to do.

Isn’t this a lot of work?

Some of you might be thinking: What a pain! I’d rather just map the code to a UI and take my chances.

Sometimes that approach works just fine. But if not, you’ll later have to choose between unhappy users and lost market share vs. starting over. This above process wins long-term because you are more likely to get the UI close to right the first time. Having to start over or fix fundamental usability problems complaint by complaint, bug by bug is a much bigger pain. But you know that, right?

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

If you would like to learn more about the process I’ve just described, 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.

• 1 Comment »


• Design process