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. Instead of focusing on a mechanical solution and hoping to stumble across a usable human solution, let’s flip that and start with an intuitive, human solution and make it work mechanically. And save 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.