UX Design Edge

Don’t design like a programmer, part 3

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.

I ended the post with this example, which shows what happens when you fall into this trap:

This has been my most popular post and the feedback has been very supportive. Still, several people said that they weren’t satisfied that I ended the post bad example without showing a good one, and asked me to provide an example of a good design. Easier said than done!

My first step towards this goal was Don’t design like a programmer, part 2, where I outlined a design process for good design and its various attributes. In this third post, I would like to put everything together, apply the process, and show a partial mockup of a good design that is user centered and avoids the “designing like a programmer” trap.

Two critical design problems

My original post was not a critique of the wGetGUI UI, but rather an exploration of a common UI design trap that programmers often fall into when designing UI. wGetGUI was just an example.

There are two critical problems with the original wGetGUI design that I must point out before continuing:

• The purpose of the program is unclear. You need external knowledge to understand what the program does.
• The mechanics of the program are unclear. You need external knowledge to understand how to use the program.

While these are design problems are quite common, I believe they are unacceptable. The purpose and mechanics of a well-designed program should be obvious from inspection, and should never require external knowledge, experimentation, or documentation to understand. The old programmer acronym of RTFM should be replaced with DTFUI.

By contrast, the more obvious design problems—the over complexity and exposing everything on a single surface—are of secondary importance and easy to fix.

Applying the design process

OK, let’s get down to business and apply the design process outlined in Part 2. Let’s call the new UI SiteNabber.

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?

   SiteNabber is a simple utility for copying website files, primarily for site backup or offline usage. Without SiteNabber, users either have to copy the files manually or use a complex utility.

2. Define the target users. Write a short paragraph to define the target users and their relevant characteristics.

   The target users for SiteNabber are intermediate computer users. They have enough knowledge about computers and the Internet to want to copy a website’s files, but they aren’t so advanced that they would prefer using a more complex existing solution. Experts who want to control every detail aren’t target users!

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?

   The top user goal is to perform the download/backup task with minimal hassle, both in terms of effort to use the program as well as time to download the files. SiteNabber users need enough control over the task to avoid wasting time by using an efficient approach and not downloading files they don’t want.

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.

   There are two top tasks:

   1) Downloading a site (or partial site) for offline usage.

   2) Downloading a site (or partial site) for backup.

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?

   Users may own the site content but probably do not (if they owned the site, they would probably use a specialized site archival tool). Consequently, users probably don’t know the structure of the site, its specific file types, or their sizes.

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.

   Here are the steps to copy a website:

   1) Determine the url for the website you want to copy.

   2) Chose the folder you would like to copy the files to.

   3) Start the copy process.

   4) Unless there is a problem (such as files that are too large to copy), that’s it!

7. Map your natural explanation into a page flow. Break that task explanation into steps, give each step a title that explains what users are 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.

   Page 1: Gather the required input from Step 6, provide access to options. The title should explain what the utility is for.

   Page 2: Give progress feedback, deal with any problems found. No input required. Title: Copying website files…

   Page 3: Show task completion. No input required Title: Website copy complete!

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.

   I’ll do this in the next section.

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.)

   I’ll jump ahead here and point out that the target user knows the website url and where to copy the files to, but doesn’t know anything about the files being copied. But the target user does have the goal of not wasting time or disk space. Consequently, the options should optimized avoid wasting time and space by default.

   A good optimization goal is that users should be successful on the first try instead of trial and error. That is, instead of attempting the copy, failing because of some problem, canceling, tweaking the settings to avoid the problem, and then starting over; the UI should be designed to handle problems as they are found.

   Another optimization is to preserve all previous input and settings so that users don’t have to reenter them.

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.

    Check!

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.

    Check!

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.

    Beyond the scope. But if you are a user, please send me your feedback.

A couple important takeaways

While working through the above process steps, two important takeaways really jumped out at me:

• For a simple utility like this, these design process steps don’t take very long—you just have to think them through. Thinking them through by writing code is the opposite of agile. Saying that you don’t have the time to apply this process isn’t a convincing excuse.
• The steps strongly suggest that the original wGetGUI is designed for a target user probably doesn’t exist. Its target user wants a simpler, easier to use UI than the command line version, yet somehow knows what all the command line options mean. This is the Using variable or technology names as control labels trap I identified in Part 1.

Page design

Now let’s cut to the chase and design some pages!

Page 1: Gather input, perhaps with an Option dialog.

Here is the main page that identifies the program and its purpose, gathers user input, and provides access to options.

The large main instruction at the top of the page explains the purpose of the utility. Should no longer be a mystery.

The website and folder combo boxes are used to get the source and destination for the copy. Combo boxes are used for efficiency, since previous input is likely to be reused in the future. The Browse buttons (labeled with ellipses) are used to display picker dialogs to help users with providing the input. Once everything is set, the user initiates the task by clicking the prominent Copy website button.

The options required for efficient copy are selected by default. Instead of sprinkling options everywhere, the options related to the source are accessed using Source options and the options related to file copying are accessed using Copy options. General advanced options are accessed using the Advanced button. I’ll look at options in more detail in the next section.

Page 2: Give progress feedback, deal with any problems found.

Here is the progress page:

The purpose of this page is to communicate the overall progress. Gory details like the current filename being copied aren’t necessary so they are omitted. I’m assuming target users really don’t care.

An interesting design challenge is to deal with large files that users might not need to copy without having to abandon the task and start over. Note that the first page has a Prompt for large files option. If that option is set, files that are larger than some specific size are prompted before copying. Here’s how that UI might look:

Here files greater than 1 GB are prompted. Users can select to copy them as they are found or wait until the initial copy is done, select the desired files, and click Copy large files. I haven’t tested this solution, but there is a lot to be said for eliminating trial and error.

Page 3: Show task completion.

Finally, the last page gives clear feedback that the task as been completed:

As a convenience, the page gives a link to the destination folder to complete the task from the user’s point of view. If in the top scenarios users are likely to want to access that folder immediately (which I’m not assuming here), a better approach would be to not display this feedback, but just close the program and display the folder to show task completion.

To wrap this section up, note how the pages closely match the task steps outlined in Step 6. If they were different, that would suggest a design problem.

Handling the options

Handling all the options is clearly a challenge with the wGetGUI design. In the interest of time and space, I won’t mockup screenshots but rather describe a good solution.

There are several techniques to simplify a UI. These are the most useful for this program:

• Removal If an option is unlikely to be used, just remove it! Here are some reasons to remove options:
  • There is one option that always works well, so alternatives aren’t needed.
  • The program can determine the right thing to do automatically, so users don’t need to be involved.
  • The option is so obscure that nobody uses it.
• Goal based Better to have a few, high-level settings based on the users goals than a whole bunch of directly exposed technology knobs and dials that require users to map to their goals.
• Contextual While anything might be (theoretically) possible in general, only a few things are likely in a specific context.
• Organized Options are easier to find when well organized. If the options don’t fit well on a single page, the traditional tabbed property sheet is a good standard solution.

Let’s apply these techniques and handle the options in a variety of levels:

• Level 0: Removal Just do the right thing without involving the user. For example, if a file already exists in the destination folder with the same size and timestamp, it’s the same file. No need to download, no need to ask. Given the target users defined in Step 2, it’s appropriate to be aggressive here. Remember that super experts aren’t the target.
• Level 1: Surface most important, frequently used options For this proposed design, the Prompt for Large Files option is important enough to be surfaced to the top level. If the design had goal-based options (suppose the options for backup are different from those for offline viewing), those should be surfaced as well. I don’t think the other options justify surfacing. Certainly not a good idea to surface all of them!
• Level 2: Contextual options The source and copy options are accessed contextually using the Source options and Copy options buttons.
• Level 3: Advanced options I used an Advanced button to present any remaining options—assuming any remain. Ideally these would fit comfortably on a single page, but I would use a traditional tabbed-based presentation if not. Normally I recommend against using an Advanced label (generally, it’s better to use a more specific label), but that label is appropriate here because the remaining options really are advanced and infrequently used.

The design process puts a lot of emphasis on defining and characterizing target users and their goals. The challenge of handling the options illustrates why: good design decisions completely depend upon the needs of the target users. Don’t fall into the other classic programmer trap of designing for yourself or presenting everything the same way.

Handling the details

I haven’t yet performed Step 12: Test with real users, so there’s a good chance that I have some details wrong. This is normal and expected. Here is some feedback that might come up with real users:

• I need all those options! The proposed design eliminates only the options that aren’t really needed—so any disagreement lies with what is really needed. To simplify, the focus should be on the probable, not the possible. Yes, I suppose it is possible that somebody using a website copy program doesn’t want to copy html files, but it sure isn’t probable. Better to remove such options.
• Your design isn’t practical.The original wGetGUI design is a UI for a command line program, so you can’t get progress feedback (or some other problem.)  Feasibility often comes up as an issue, so I want to make two important points:
  • The user experience should drive the technology, not the other way around. Saying that the technology can’t support a good UX is usually a poor excuse. Fix the technology!
  • Decisions made by backend/API developers affect the user experience. Such developers often claim that their work doesn’t affect the UI. This is nonsense. But this attitude explains why so much software has poor performance and responsiveness, poor error handling, poor feedback, and can’t be canceled.
• But I like the original design… If so, that’s great. You had the motivation to learn how to use the utility, but most users don’t. This proposed design is targeted at those users.

If you do only one thing… If you design UI like a programmer, please try to apply the design process outlined in Part 2. It really does work and it gets you focused on your users instead of the code.

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.

Feature Hoarders: Extreme Edition

I have an odd fascination with A&E’s Hoarders and TLC’s Hoarding: Buried Alive. It’s a sad human tragedy, where people harm themselves and their loved ones only because they collect too much stuff, let it all pile up, and refuse to throw anything away.

It’s harsh to say, but I’ve seen many apps that look like they were designed by feature hoarders—the equivalent of room after room of features and options of questionable value that have piled up over the years because nobody was willing to make the hard decisions to get rid of them.

This post explores why feature hoarding happens and what you can do about it.

Potential value

I should start by saying that I sympathize with hoarders to some degree. While I don’t get the shopping sprees (I get more delight in not buying stuff), I understand their reluctance to throw things away. When I look at something, I try to see its value and I’m reluctant to throw away things that have value.

If you watch a few episodes and listen to hoarders explain why they collect all their junk, phrases like “potential value”, “I’ll use that someday”, or “that will make a great gift” keep coming up. Emotionally, they see value even though rationally the odds of that value ever being realized are extremely slim.

Feature hoarders think about questionable features and options the same way. Even though the features aren’t necessary and rarely used, feature hoarders see the potential value and cling to the idea that one day somebody will find them useful, no matter how unlikely.

The value of simplicity and organization

While hoarders overestimate potential value, they severely overestimate actual value. They also underestimate the value of simplicity and organization. Being able to easily find and use things that you really need is far more valuable than having possession of things you don’t use.

The key to simplicity is to understand that the features and options that users will use are far more significant than those they might use. Ease of use equals use, so things that are easy to find and use have more value. Ultimately, potential value doesn’t matter much.

A bad day for user-centered design

If you were to ask a usability professional how to make a difficult design decision, there’s a good chance they’ll say “Just ask your users.” This isn’t always good advice, and these hoarder shows illustrate why. When dealing with hoarders, every day is a bad day for user-centered design.

Have you ever noticed how user centered these shows are? The hoarder is involved with every decision. In the beginning, the consultant/therapist/expert asks the hoarder item by item “Can we throw this away?” Each time, the hoarder’s answer is an emphatic “No!”, often accompanied with an “I’ll use that someday” or “I’m going to fix that” rationalization. This grinding process usually ends with shouting and tears.

The problem with user-centered decisions here is that users are good at giving their goals and setting priorities, but they are poor at making the tough, detailed decisions. If you were to ask users if they want something, the answer is almost always yes. I call these “Do you want fries with that?” questions, and as a designer you shouldn’t ask them.

A better approach would be to ask the hoarder to go through the house and point out their favorite things and the things they use the most. Then, remove everything from the home (including the hoarder), clean everything up, strategically replace and reorganize what the homeowner really needs, then evaluate the results with the homeowner.

Changing culture

Still, I appreciate what the consultants/therapists/experts are doing. Is relatively easy to clear out a house—it’s much harder to change the behavior that lead to the hoarding in the first place. If the expert doesn’t change the behavior, the improvement will be temporary at best.

Remember: the junk is there for a reason. The hoarder thought it was a good idea to buy and to keep all that junk, and without a behavior change they will do it again.

If you are trying to simplify a UI, I recommend understanding how that complexity got there in the first place. Chances are those unnecessary features and options are there on purpose, and that purpose was well intended. Somebody thought the features were a good idea at the time. Perhaps customers requested them directly. Simplicity requires saying “no”—it’s much easier to say “yes.”

Sure, you can declutter a user interface, but unless you change your team’s culture by setting a higher bar for adding features and a lower bar for removing them, that clutter will soon return.

Making the tough decisions

The top takeaway of these shows is that decluttering is much easier said than done. So, what can you do to declutter your UI? Consider using one of these techniques:

• Gather real user data If you have the ability to gather actual usage data, you’ll have a strong case from removing unused or rarely used features. While I don’t advocate using data without interpretation, as long as there isn’t a discoverability problem, removal is usually the right interpretation.
• Highlight your top scenarios With your team, make printouts of all your screens, perform your top tasks, and highlight what you actually use during those tasks. Take a good hard look at what didn’t get highlighted. What bad thing would happen if they were removed? With this activity, you’ve demonstrated the answer: not much.
• Try a simplified version I’m a strong advocate of considering design alternatives. One alternative to always try is a simplified version of your current design. Instead of going through the grinding process of cutting feature by feature, just go directly to the simplified results and give it a try. I bet you’ll be surprised how nobody misses what was removed.

A devious use of iPhone design

Here’s a fun exercise to help your team simplify a UI and perhaps even change its culture. Assuming that you don’t already have one, have your team design an iPhone app. (If your app does many tasks, do this for a few top tasks.) Before starting, you might want to quickly review the iPhone guidelines, point out that there is only so much screen space, typing is a pain, and that the best iPhone apps focus on doing one task well.

Once you are done, evaluate the results by performing the top tasks. If successful, chances are your team will say things like “This is great!” and “If we had this, I don’t think I would use our original app anymore!”

Now, take a step back and compare the iPhone app to your original app. Justify the complexity of the original app. Do you really miss the features that were removed? Does the ease of use, speed, and delight of the simplified iPhone version more than make up for the missing clutter? Is there any reason why your original app can’t be more like the iPhone version?

I bet your team will have trouble justifying the complexity of your original app. The iPhone platform demands simplicity and starting from a clean iPhone slate allows your team focus on the essentials without legacy baggage.

If you do only one thing… Don’t be a feature hoarder. Focus the UI on the features and options that your users actually use, not on what they might use. Value simplicity, organization, speed, and efficiency by getting rid of what gets in the way. Get in the habit of creating simplified design alternatives and seeing if they work better. Chances are, they will!

Looking for UX design interview questions? Show candidates a complex UI and ask them to simplify. When they recommend removing features and options, challenge them by explaining why there are there and seeing if the candidate can still convince you to remove them. The ability to make a persuasive case for simplicity is a valuable design skill.

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…Users 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. To avoid designing for yourself, specifically identify how they differ from you. (Hint: It’s a sure thing your target users don’t know how your code works.)
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.

Everybody loves creativity

I saw a rerun of the Working Girl episode of Everybody Loves Raymond last week. In this episode, Debra gets a job at an advertising agency. Her first project is an advertising campaign for a pizza account, so she comes up with a character called “Professor Pete Za.” She was fired on the first day because her boss didn’t like the idea but Debra kept fighting for it. The episode concluded with Debra and Ray talking about how silly her ideas were and how she should have realized that and backed down.

Apparently I didn’t have the intended reaction. I thought the Pete Za idea was pretty good and Debra shouldn’t have been fired for fighting for it. Creative ideas often look silly at first and they require some fighting. These challenges show what the creative process is supposed to look like!

Having creative ideas is easy—selling them is hard

If you want to foster a creative environment, but want to limit your team to only the creative ideas that everybody immediately gets and don’t have any problems, you might as well pack it up because it isn’t going to happen. People don’t always appreciate creative, innovative ideas right away. And there are always problems—lots of them.

While it’s challenging to come up with creative ideas, often the bigger challenge is selling them and working through the problems. It’s a mistake to abandon them too early just because there are issues. And it’s a mistake to expect everyone to immediately get your creative ideas without you standing behind them and selling them.

So simple, a caveman can do it…but would an executive?

The episode was about advertising, so let’s look at a real advertising example. My favorite ad campaign is for Geico. I think their ads are extremely creative, fun, and memorable; and do a great job of selling their product.

Imagine being at the meeting where the Martin Agency first pitched their ideas to the Geico execs. It might have been something like this:

Martin: People have trouble pronouncing “Geico”, so we were thinking of having a talking gecko with a cockney accent. And we’ve got a great idea for a series with sensitive cavemen who are constantly being insulted.

Geico: Interesting…what else do you have?

Martin: We were thinking of a series with a pile of money called Kash to represent customer savings.  Then there’s a series featuring old sayings being taken literally. Oh, yeah…there’s the one about talking pothole with a teenage southern accent.

Geico: Um…OK! Thank you for your time. We’ll get back to you.

Is this really a good way to sell auto insurance?

What would you have thought had you been there? Would you think these ideas would be successful?

I’m pretty sure that I wouldn’t have. All these ideas have the same, obvious problems: what in the world do they have to do with selling car insurance? They all seem a bit crazy. And with so many different ideas, won’t the campaign lack focus? Won’t people get confused?

While I think that the people who came up with these ideas are brilliant, the people who persuaded the Geico execs to go with them are just as brilliant. Perhaps the Geico execs who gave it all a green light were the most brilliant. I’m sure most executives would have turned these campaign ideas down.

Many creative ideas are losers

One thing we will never know is how much effort went in to making these ideas work. We’ll also never know now many bad ideas the Martin agency went through to find the few winners.

That’s why the creative process requires brainstorming. Many creative ideas aren’t winners—especially the risky ones, so the process is to come up with as many ideas as you can, identify their strengths and weaknesses, work through the problems, and see what holds up. Then sell them! I think the only mistake Debra Barone made was working with a single idea.

Developers have a hard time with creativity

Developers can have a tough time with the creative process because they tend to view all ideas through the lens of how difficult they would be to implement. Developers are trained to take an idea, pick it apart, and identify all the problems. We love doing that! But it’s harmful to the creative process.

While feasibility and development challenges are important, they aren’t important during brainstorming and the creative phase of the design process. That analysis is for later. It is important for developers to understand this.

Getting everyone on board

Given the challenges with creativity that I’ve just outlined, it’s important to get everyone on your team on board so that their contribution is as constructive and impactful as it can be. Make sure that everyone on your team:

• Has an open mind. The creative process requires looking at a wide range of ideas. You can’t make a choice if you don’t have a range of options to choose from.
• Doesn’t say no. Not all the ideas are going to be winners, but effective brainstorming requires the free flow of ideas. The worst thing you can do during brainstorming is critique ideas or say no.
• Is patient. Even the best ideas are going to take a while to appreciate and work through the problems. Don’t expect the winners to be perfect right off the bat.
• Fights for ideas, but doesn’t dwell. Creative, innovative ideas require some fighting—never expect to lob out an idea and have everybody love it immediately. But don’t dwell, which is when you continue to pursue it after it’s clearly not working or you refuse to seriously consider alternatives.
• Focuses on creativity now, feasibility later. Feasibility and development challenges are important only after you have figured out what you want to do. Before then, these concerns are a tax on the creative process.

If you do only one thing: The creative process requires skills that most people haven’t fully developed. This is especially true if your team is highly technical. To make the creative process effective, get everybody on board first by reviewing how the creative process is supposed to work.