On November 14, I presented Design Hacking: Great UX without time, money, or design skills to the Igniters: Stanford Entrepreneurs and Silicon Valley Founders group at Hacker Dojo in Mountain View, CA. I would like to thank Raj Lal, Cynthia Lee, and Wendy Soon of Vorkspace for inviting me and making this event happen. I had a great time, made some excellent contacts, and received a lot of encouraging feedback.
Design Hacking at Hacker Dojo. Apparently you are supposed to photobomb from the back.
First, this is my first real blog post since November 2011 (two years)! It’s not for a lack of ideas—I have a backlog of over 50 excellent topics. Rather, I haven’t had any spare time because business has been excellent (37 onsite UX Design Essentials Workshops and 17 public UX Design Essentials classes since that last post), plus the time required to write, produce, and recover from my new book UI is Communication, which was published by Morgan Kaufmann in June.
I have just now recovered enough to hopefully start blogging again regularly. It’s good to be back!
Obviously this topic is a tall order—is this goal even remotely realistic? I think so, but you have to believe three fundamental ideas:
What we need is a perspective to help us make better design decisions more quickly and confidently. Not only does such a perspective exist, but as you will soon see it is one that we already know!
Traditional user-centered methods require user research, requirements gathering, sketching, prototyping, user testing, and lots and lots of iteration. But there are several challenges, especially if you are in a hurry:
These are all sound design techniques, but they take a lot of time and great design is hardly guaranteed.
From what I can tell, agile and lean UX techniques don’t help much here either. They still take a lot of time and money—often with mediocre results, especially for larger, more complex projects. The main difference is that you’ll know your UX sucks much, much faster. [Disagree? Please provide counter examples in the comments.]
The traditional approach favored by developers, which often boils down to putting raw the data structures required by the back end on the screen, doesn’t work at all. Find out why in Don’t design like a programmer.
Don’t believe me? Let’s take a look at a well-known UI that is currently in the news.
How many HealthCare.gov’s Account Setup usability problems should have been obvious? All of them!
Nielsen Norman Group did a guidelines review of HealthCare.gov’s Account Setup step. Here is a sample of the guideline violations they found:
There are no surprises here—the designers should have known that these would be issues. Lots of time and money wasted here. My bet: this UI wasn’t designed as much as it was specified based on arbitrary, ill-conceived requirements. Usability wasn’t much of a concern but acceptance testing was. [Am I wrong? Please let me know in the comments.]
To design great UX without money, time, or design skills, we need to leverage what we already know. If you were to ask a group of people why UX design is so hard (which I routinely do), invariably they will agree that one of the biggest challenges is that we don’t understand our users well enough.
This is certainly true. But if this were the root cause of poor design, I would expect to see many UIs that are well designed, just for the wrong target audience. In practice, I never see that. Instead, what I see is UIs that are poorly designed for everyone. It’s doesn’t matter who you are or what you are doing—they’re poorly designed.
Of course, it’s true that different users have different knowledge, motivation, preferences, workflows, etc. But there are many attributes that we can safely assume that all users have that we usually don’t even consider. I have compiled dozens of these and put the top 50 in UI is Communication.
But to keep things simple, let’s start with one user attribute that every UX designer should know:
Unless they have been trained or have prior experience, users only know what your program tells them.
I believe the real root cause of most poor UI is a failure to communicate to its users. Well-designed UIs are self-explanatory, and shouldn’t require trial-and-error, a user’s manual, help, or training to use.
Most user’s manuals explain how the UI should have been designed in the first place.
A user interface is essentially a conversation between users and technology to do tasks that achieve users’ goals. A UI is a form of human communication, and if it communicates well it will be naturally intuitive. My UI is Communication book explores UI design from this point of view, and I will explain this concept in detail in a future blog post.
But to get started, a great way to design UI is to think about how you would explain a task to a target user in person. Think about the steps, their order, the language you would use, and the details that what you would bother to explain. Also think about what you wouldn’t say—those unnecessary steps or details you know the target users just don’t care about.
That conversation is a high-level guide to what your design should look like—great UIs feel like a natural, friendly conversation. But to be clear, I’m not saying the UI should be a literal conversation—that might be tedious—rather it should feel like a human conversation in terms of the steps, order, and communication. And it should never be chatty—applying this process usually results in less text, but much better text.
If there is a difference between what we say in person and what we say in UI, usually it is the human conversation that is right and the UI that is wrong. We naturally explain things in person in a way that the target users will understand. Great UIs should mirror human conversations because that is the most effective way to explain things.
At this point, I’m sure that you would like to see some examples. If so, please check out the Look Inside feature on Amazon. There is a very generous preview with many examples to get you going.
Now let’s cut to the chase! Here is a communication-focused design process that requires a minimum of time, money, and design skills.
Most of this process is fairly traditional. The main difference is that we are using our understanding of the target users and top scenarios to determine how to communicate the tasks effectively on a human level. Scenarios and communication drive the process. At best, traditional design processes discover that communication accidentally. Here we are doing it deliberately, and saving a whole lot of time and money by doing so.
Some evaluation techniques to consider:
I put a rough time estimate for each of these steps (in parentheses) to back up the “without time” claim. While designing all the pages and doing some user-based reality checking will take days, most of the remaining steps can be done in a matter of hours for simple projects.
For the sake of brevity, I glossed over several important design techniques that I mentioned here, but they are all covered in detail in my UX Design Essentials class. My next UX Design Essentials in San Francisco (San Mateo, actually) will be on April 23 – 25. You can register now without payment.
While I believe that UX Design Essentials is at least 90% relevant to entrepreneurs with extremely limited time, money, and design talent, I’m thinking of creating a new UX Design Essentials for Entrepreneurs class that is 100% relevant, then delivering that version exclusively in the Bay Area, New York, and Boston.
A good idea? Please contact me to let me know.
I will be presenting UX Design Essentials in Katowice Poland in November. Looking forward to it!
I will be presenting UX Design Essentials in Dalian, Beijing, and Shenzhen China in July. Looking forward to it!
My blog has been on an unscheduled vacation since November 1st. This is about the time I started working on UI is Communication, and unfortunately I don’t have time to both write a book and blog. Too bad, because I have about one hundred fantastic topics in the queue.
LinkedIn recently added a Poll feature and I’ve tried a few polls on a variety of user experience-related topics. They are fun to make, fun to take, and the results are often insightful. Best of all, I can put together a good poll in a couple minutes, which is about all the free time I have right now.
So, here’s the deal: Every Monday I will post a new UX design-related poll, which you will see in the lower-right corner of the UX Design Edge site. (That’s the weak fallow area for you Gutenberg Diagram aficionados.) Please stop buy, take the poll, and check the results.
To put everything together nicely, I have registered ux-poll.com, which will take you to an archive of the past polls.
Please participate and enjoy!
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.
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.
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:
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. This is the very definition of what it means to be intuitive. 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.
OK, let’s get down to business and apply the design process outlined in Part 2. Let’s call the new UI SiteNabber.
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.
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!
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.
There are two top tasks:
1) Downloading a site (or partial site) for offline usage.
2) Downloading a site (or partial site) for backup.
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.
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!
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!
I’ll do this in the next section.
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.
Beyond the scope. But if you are a user, please send me your feedback.
While working through the above process steps, two important takeaways really jumped out at me:
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 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:
Let’s apply these techniques and handle the options in a variety of levels:
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.
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:
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.
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.