Design for Software: A Playbook for Developers

Part I: Research

When building a house or remodeling a kitchen, it’s not uncommon to spend a fair amount of time planning before you let contractors go willy-nilly. Typically, you research neighborhoods or cabinet manufactures, and look for inspiration in various interior design or architecture magazines. Then during the build-out, things will more or less go according to plan and everybody’s happy. Can you imagine what the process would be like if you didn’t plan anything upfront and winged it? It would be a disaster—you wouldn’t even consider it…Not surprisingly, designing software without a plan usually ends the same way—a disaster.

I talk to many folks that have great ideas for apps, yet so many of those apps remain exactly that—ideas. Nothing gets built and ideas fade away. Or what’s worse, they jump in headfirst, slapping things together and the result, amongst other things, is a poorly designed product. On the contrary, I’ve seen applications come together in a mere few weeks that look and work great. As with any process, doing the due diligence and planning upfront has its benefits.

The first two chapters of the book will help you kick off your next project right. If you’re new to the field and aren’t sure how to get started, or if you’re looking for inspiration to help kick-start your design, these chapters will be helpful. Throughout Part I you will learn about the following topics:

• Performing fundamental user research

• Gleaning user insights that will fuel your next application

• Finding inspiration and leveraging it in your app design

• Presenting user research to stakeholders

Chapter 1: Planning

It works, but nobody uses it

SO YOU JUST finished your latest digital creation, and you managed to squeeze in every last toolbar, pop-up menu, banner, button, tooltip, and scrolling marquee. It’s awesome . . . right? I’m sure it is. But sadly, more features rarely mean better software.

Well-designed software doesn’t start with a functional requirements list, pretty pictures, or a slick algorithm. It starts with people. People use software as a means to an end. Whether it’s a website, MP3 player, or utility, users have distinct needs and motivations for using the digital product. It’s your job to cater to them.

How many times have you found yourself using, say, a GPS unit or kiosk and thinking, That doesn’t make any sense or Why did they design it that way? Chances are, the people who built the software weren’t thinking about you. Tragic, I know.

Seriously though, all too often we approach building software solely in terms of functional requirements. We approach every problem by looking for the best technology solution, rather than focusing on what’s best for the user. After all, that is how software development is typically taught in school and how most projects are structured.

I’ll let you in on a little secret. Creating successful software is not that complicated. In fact, all you must do is understand what users need, and then give it to them in the clearest, least cluttered way possible. Simple, huh? Well, not exactly. But, by using the techniques in this chapter, you’ll be well on your way to creating software people love to use.

An Introduction to User Research

Many industries conduct extensive user research to create that perfect product. For example, the advertising, gaming, and auto industries invest tremendously in user research. Frankly, however, the tech community is a bit behind in adopting user research as an integral part of software design. Okay, maybe that’s a bit overstated, because user research seems to be prevalent among web designers and Human Computer Interaction students. However, why do websites and school projects get all the attention? Why not kiosks, digital signage, ATMS, GPS units, or cable box menus for that matter? Ugh . . . just thinking about navigating my DVR makes me tired all over.

The whole point of doing user research, and this is important, is to generate insights and empathy. Most good product solutions revolve around a just few good insights. Nonetheless, the field of user research isn’t new, and the techniques in this chapter barely scratch the surface of what’s out there. However, using just a few key techniques can have a profound impact on the usability of your application. Let’s have a look.

KEY POINT

The whole point of doing user research, and this is important, is to generate insights and empathy.

User Research Is Not Usability

The terms user research and usability go hand in hand but aren’t necessarily interchangeable. User research, through various techniques, can lead to insights that can improve usability. But at its core, user research is about understanding the needs and goals of users. I like to think of user research as the precursor to usability.

Design Lingo: Ethnography

Another form of user research worth mentioning is ethnography. Wait, ethno—what? Ethnographic research methods are aimed at generating understandings from a particular group of people or culture. Wikipedia defines it as follows: A qualitative method aimed to learn and understand cultural phenomena which reflect the knowledge and system of meanings guiding the life of the cultural group.

Ethnographic research methods are outside the scope of this book, but they can help demonstrate when ethnography might be useful. I like to think of ethnography as a pre-product activity. In other words, before you identify an audience or particular problem to solve, you can conduct ethnographic research to determine social and behavioral trends that might lead to the invention of a new product.

Table 1-1 shows use cases for ethnography, user research, and usability testing..

Table 1-1: Cases for Ethnography, User Research, and Usability Resting

Start with User Insights

Before you can build the next killer website, widget, or app, you need to understand what the user’s goals are. As technologists, we have some issues with prying ourselves away from the minutia—our meticulous attention to detail and compulsive habits tend to inhibit us from looking beyond our own role on a project. These aren’t bad characteristics because they help make for great engineering minds. However, taking a step back and really getting into the user’s shoes will help you understand the real problem.

To illustrate this point, I’ll use Dropbox.com. Dropbox is a utility application that makes syncing files extremely simple. Dropbox operates from a particular perspective: Technologists often work with many computers and potentially many operating systems. Syncing files among computers can be a cumbersome task, and before Dropbox, the only products that claimed to help solve this problem were complicated and rife with inconsistencies.

Dropbox understands these pain-points, but what’s more, it understands the motivations and behaviors of users seeking a better solution. Its product works exactly how you expect it to and where you need it most. Dropbox didn’t create a flashy user interface (UI); in fact, it’s virtually a UI-less product. For Dropbox, it was about understanding the target audience’s needs and delivering a solution as elegantly as possible.

The secret sauce, if you will, of great software stems from your ability to uncover your audience’s motivations, which in turn, leads to key behaviors that result in connections between your software and the user. For example, take a look at top sites and apps such as Mint, Evernote, and Amazon. All these sites are extremely efficient at helping users complete a handful of core tasks.

KEY POINT

Great software stems from your ability to uncover your audience’s motivations, which in turn, leads to key behaviors that result in connections between your software and the user.

Despite its size, Amazon remains really good at one thing—making it super easy to buy stuff. Perhaps a little too easy (I’m looking at you, Mr. 1-Click purchasing button). Amazon gets the impulse buying mentality and nailed it right on the head. Do you really like to pull out your credit card every time you make an online purchase? I’m guess most people don’t.

Mint.com (see Figure 1-1) is a great example of where user research literally paid off. If you compare Mint to most online banking offerings, it’s clear that the folks at Mint understand the motivations, pain-points, and opportunities involved with managing personal finances. When you log into your Mint account, the first thing you see is how much money you have, how much you owe, and how your money has been spent. In contrast, most online banking sites turn reading your balance into something of a science with terms like ledger balance, available balance, and current balance—when all you’re wondering is, How much money do I have?

Figure 1-1: Using clear language and layouts help keep your UI aesthetically pleasing and usable.

(Copyright Mint.com)

Evernote (see Figure 1-2) does digital note taking better than anyone else. This is by no accident; they focus on one task and do it really well. The good folks at Evernote understand a nearly frictionless user experience is crucial for successful note taking. Ironically, it’s pretty easy to screw up something as simple as digital note taking with save dialogs, connectivity alerts, and gratuitous styling. Evernote jumps through some pretty significant engineering hoops to mask the complexity of file storage, syncing, and conflict resolution so that the UI just works. You never have remember where you put your notes, how to get them on other computers, or even bother organizing them. Evernote took something that has been done many times before and made it better. That’s really hard to do without truly understanding the user’s needs and tasks at hand.

USER RESEARCH TECHNIQUE #1: OBSERVATION

I’d be willing to guess that some of you have developed software and then haven’t watched how users actually interact with it (and, yes, I’ve been guilty, too).

People ask me all the time, "What’s the one thing I can do to make my project better? My response is usually another question—Have you watched anybody use it? Sadly, more times than not, the answer is no."

Figure 1-2: Even though many note taking applications exist, Evernote succeeds because it takes a user centered approach to note taking.

(Copyright Evernote.com)

Though a bare-bones approach to user research, observation is perhaps the easiest, cheapest, and quickest way to elicit real feedback from your target audience. Simply observing users in their environment can be an invaluable tool to keep in your software-design utility belt. Of course, I’m not suggesting that this is the only tactic for doing user research, but direct observation is a great way to get started.

The quick-n-dirty method

For those of you who literally have no time, and perhaps no money for user research, here are the ten steps to the quick-n-dirty method:

1. Find out who your primary users are.

2. Go to their workplace and ask for permission to observe them at work.

3. Bring a camcorder.

4. Bring a coworker.

5. Keep an eye out for common activities.

6. Watch for struggles and hesitations.

7. Note how the users interact with their environment (consciously and unconsciously).

8. Eat a burrito and analyze your recordings; specifically, try to find patterns in behavior.

9. Group the patterns and translate them into insights.

10. Bonus: Have users state their stream-of-consciousness while they are using an application. And have them verbalize their thought process (this is very useful, and usually very funny.)

Brilliant. Now, take a closer look at these steps.

If possible, it’s highly useful to observe users on location; doing so allows you to peer into the unspoken aspects of their tasks and motivations. Going onsite literally puts you in a user’s world. Be sure to gain permission before you shadow users. Nothing is worse than showing up at someone’s workplace with a camcorder looking to gain some insights, only to have a security guard toss you out and confiscate your equipment.

Camcorders, voice recorders, cellphones with video capture, anything that can replay a session is important for keeping an accurate account of what happens. Relying on some chicken-scratch notes and your memory simply won’t cut it.

Common behaviors may surface throughout the session; try to keep note of them. For example, users may need to frequently take phone calls while inputting information. Or they may need to adjust the angle of the screen throughout the course of a day to account for sunlight glare, which may be a good reason to use a high-contrast color palette.

Imagine that you’re targeting a power user . . . say, a stock trader using a trading system. Observing the trader’s environment and how he interacts with it can be a good way to understand the context in which your software will reside. More specifically, observing the interactions among traders may lead to a really nifty social feature.

Watching for hesitations and struggles is also important, especially when looking for ways to improve existing technology or to discover usability issues within your own applications. These struggles are typically referred to as pain-points and can be catalogued and prioritized. Identifying pain-points can also provide valuable insights into how to differentiate your product from your competitors’.

Another interesting thing to look out for is how participants subconsciously interact with their environment. For example, I often see people bustle up to a kiosk or an ATM and place their drinks, purses, or bags on top of the display or on any nearby surface. Thus, one obvious insight is that people need the ability to drive the interface by using only one hand. A simpler solution might be to install a ledge to accommodate personal effects.

After you scour your recordings, transcripts, and notes, you’ll likely uncover patterns in participants’ activities and struggles. Later in the chapter, you find out exactly what do with your findings. At this point, take a moment to rank and prioritize your findings, and give yourself a gold star.

Case Study: Lightning Fast Checkout

A couple of years ago, my company was consulted on a project in which the client wanted to increase the efficiency of the retail checkout processes. You know the scene—you’re standing in a checkout line noting that there are 30 registers, with only one servicing customers. So, you decide to ditch your basket and walk. That was precisely the problem we were asked to resolve. The client voiced the problem loud and clear: Time is money, and saving even one second per transaction matters.

First, we observed transactions at the checkout lane as they happened in real time. As we began our investigation, we noticed the whole process was peppered with little bottlenecks. Most peculiarly, the total checkout time was only loosely correlated to the basket size. Curious about what was causing these bottlenecks, we looked deeper into the tasks involved with ringing up a customer. We timed everything from how long it took to bag milk and weigh produce to how long it took to return cash and accept electronic payments.

We discovered one consistent bottleneck—ringing up of produce. All those tasty apples, onions, and spices caused the average transaction to take up to six times longer than other items. This bottleneck occurred because each produce item had a unique barcode found by combing through a little black code book. Every time a produce item came across the belt, employees had to flip through this book, which disrupted the whole checkout process. At that point, we had our key insight, and it was clear what we had to do: eliminate the black book and make ringing up produce as fast as possible.

In our final solution, we had touchscreens, biometric fingerprint scanners, and even label recognition, all in an effort to make checkout more efficient. This Frankenstein of a lane was a real beaut, and I could write an entire chapter on all of its small innovations, but I’ll avoid going on tangents (for now) and get back to the produce screen.

In our exploration of options for the produce screen (see Figure 1-3), we started with a basic grid layout with the barcode, the item name, and an image for each row. The grid was sortable, nicely styled, and it worked. It was an obvious way to solve the problem of looking up produce in a long list, but it didn’t do much to make the task of ringing up produce easier or faster. Meanwhile, the little black book lay quietly staring.

We knew we could do better than this, so we barged forward and continued to refine. The final version of the screen (see Figure 1-4) was successful for a couple of reasons. For starters, we laid out the produce buttons in a left-to-right order and sized them proportionally to their popularity, making the most popular produce the easiest to access. In addition, we displayed a large produce image behind the produce title for visual reinforcement. We grouped each edge case product (atypical peppers and spices) into broader categories such as ethnic and exotic. This effectively put all produce items no more than two taps away, making the screen very efficient and eliminating the need to memorize the barcodes. Bye-bye little black book!

Figure 1-3: Tabular UI presentation is often antiquated. Grids or cards can be more usable and aesthetically pleasing.

Figure 1-4: Design to accommodate habitual tasks. In this case, bigger buttons and images are used for fast recognition and touch efficiency.

(Copyright 2013 Microsoft)

And there you have it. I wanted to share this example because it demonstrates that even with just a few basic observations, you can start thinking about the software you’re building from the user’s perspective. Also, if you let your findings drive your UI decisions, then you’ll be on the path to creating a unique and elegant solution.

USER RESEARCH TECHNIQUE #2: USER INTERVIEWS

Whether you’re building a new mobile app, website, or dog leash, you have to discover what people want, and there’s no better way to do so than to ask them. However, even so, understanding what people want can be hard, namely, because cognitive psychology tells us that as humans, we’re generally bad at a few things:

• We’re bad at articulating what makes us happy.

• We’re bad at predicting what we’ll like or dislike.

• We’re bad at giving feedback on things we don’t care about.

As the interviewer, you’re on a mission to find out exactly what users want. So, what the heck, why not just ask them, "How would you design [some feature or interface]?" This approach would work great if all the interviewees were also product designers. But that’s not always the case, and unfortunately, this method typically produces knee-jerk reactions that aren’t well thought out.

However, figuring out what people want isn’t a pipe dream. The fact is that arriving at accurate conclusions from your research is all about getting the right users and asking the right questions.

Get the right users

During the planning portion of most projects, you may find yourself in a room with various business stakeholders brainstorming creative ways to solve a problem. These discussions are important for understanding the goals of the project from a business perspective. But it’s also important to understand the problem from a users’ perspective, and most of the time, these initial planning discussions don’t include actual users.

Recently, I found myself with a group of business folks looking for ways to make food stamps more innovative. After a couple of hours of fruitless brainstorming, it occurred to me that no one in the room had ever used a food stamp, and I couldn’t help but think, What business do we have innovating something we’ve never used? Unfortunately, we didn’t come up with any major food stamp breakthroughs.

Interviewing stakeholders can lead to great supplemental information but will never be as good as conducting interviews with real users. Actually, being there lets you hear what users have to say, but more importantly, how they say it. (As a side note, your colleagues at work, your mom, and your best friend are usually not good candidates for collecting accurate information.)

Finding the right participants can be pretty easy, and maybe a little obvious in hindsight. Depending on the project, I usually try to find the following:

• Existing users

• Potential users

• Power users

• Former users (these are the best users to interview)

Wrong questions, wrong answers

After you have the right people, you need to ask them the right questions. Being armed with good questions for your interview will help pull good answers out of even the most introverted participants.

Like any craft, asking the right questions requires some finesse. Remember, there are people who dedicate their careers to user research, and if it’s possible, hiring a professional will likely generate the best information. However, if you don’t have the extra time or a sufficient budget to do so, here are some guidelines for creating good questions:

• Avoid closed questions. Closed questions are typically questions that yield dead-end answers. In general, try avoiding questions that can be answered with a simple Yes or No. Closed questions will give you quick facts and can be a good way to test an individual’s knowledge, but they aren’t very good for generating thoughtful responses. Inevitably, closed questions will come up in the natural flow of conversation (it’s almost impossible to never ask a closed question). You can recover by simply asking your participant Why? ... Here are some examples of dead-end questions:

• Are you happy with ____?

• Do you dislike _____?

• How should ____ work?

• How do