Editor’s Note: TechWhirl welcomes Jonathan Frazier to the Special Writers Unit. He’ll focus (obsess, even) on all things User Experience (UX).
I was at a Harley Dealership one Saturday where the rock band was jamming out to Black Eyed Peas and I thought to myself — UX is a lot like that. Get the band to play together, respond, adjust the tempo and feed off each other’s input.
Musicians come to the stage with a setlist of songs. Each person knows their instrument, how it’s supposed to be played, and what each song should ultimately sound like. In much the same way, each contributor on a development team knows; the product they’re going to make, the technologies they’re going to use, how it is supposed to be used, and ultimately what the final product is going to look like. Jamming back and forth between design and development is a critical piece of successful development. Gone are the days where a designer would lob a pixel perfect design over the wall and “see what the developers come up with.” Throughout the development cycle they reprioritize, tweak, or de-scope features as the band adjusts. UX exists to champion the needs of the user, at all times advocating for them. Like a band jamming out to Cee Lo Green – Crazy, everyone feeding off input/feedback/ideas to come up with something great for the fans.
Most people have heard of musical theory, including the basic elements of notes, pitch, rhythm, and scale, to describe how 12 musical notes of the Western scale can be combined to create melody and harmony. Music theory is not actual music, but knowing music theory greatly helps musicians make music people enjoy. In a similar way, knowing the theories underlying User Experience (UX) (Occam’s Razor, Hick-Hymann Law, Milller’s law, etc.) helps the development team make better UX design decisions, in a similar way music theory helps musicians make better music.
Consider this list of ways UX gleans information to make design decisions:
- User Observation
- UX laws
- Best Practices
- UX publications
- Personal preference
This particular order shows the clear diminishing value of these approaches. Nothing can trump observing a user, you’re physically observing their actions. Simply watching their behaviour will tell you nearly all you need to know. Interviews provide tremendous sources of insight, but they come with some caveats. The quality of the participants, the interviewer, the phrasing of the questions, and the order of the questions can all affect the quality of the information gathered. Analytics add great value to observation of past behaviour when used correctly, however numbers are always open to interpretation. UX laws offer pretty entertaining conversation yet in my experience, a bit taboo. Mention one in a meeting and see where it gets you – nowhere. Too often, those around you may think you’re a bit of a know-it-all. Best practices deliver guidance on practical application of laws and models, but they usually change pretty frequently, and are topics of debate. UX publications can educate on how the industry trends, even if a particular discovery isn’t relevant to anyone else. Finally, there’s personal preference, which is only as good as the person whose preference it is.
Going right to the source
User observation is the best way to uncover valuable information. Jared Spool famously tells of “The $300M Button,” where he conducted usability testing on a struggling e-commerce site. Users were given money to go shopping on the site, which prompted users to log in right before checkout. Spool’s team was taken back by the level of resistance to logging in. Some couldn’t remember if it was their first time to the site, or what their password was, or where to find it. Many abandoned their purchases. After watching enough users struggle, Spool recommended that the client add a “checkout as guest” button to the site. The next year saw revenue increase by $300M, not too shabby, right?
We don’t hear of stories with such simple solutions and great ROI every day, so after hearing about a success story like that, you might want to rush right out and set up a lab and then begin testing users in search of revelatory discoveries. Reality is a bit more complicated. It’s easy to mess up a well intentioned usability test. It’s dangerous to make hasty generalizations and leap to conclusions based on the patterns or behavior you observe in a particular user. The only way around that is to observe as many users as possible. After you do enough research with a sufficient sample size, you can begin to make general observations or even create a persona of a typical user. Here’s a great resource on how to recruit users for a usability test by NM/g.
Design based on observation and empathy
Interviews or empathy gathering, give insights that user observation may miss. In my experience, two forces that are at odds with each other can appear during any interview. One, the interviewer knows what kind of information they’re trying to collect. Two, the interviewee is trying to guess what the right answers are, even when there is no wrong answer. Both can bias your conclusions.
Either consciously or unconsciously the interviewer tries to help the subject identify their problems or frustrations. However, in order to keep the interview as productive as possible, this underlying purpose needs to be shelved. The interviewee is under enough stress already.The smaller the questions, the bigger the answers.
In the back of their mind, they want to give the correct answer, even if there isn’t one! It takes a lot of energy to recall one’s own opinions, and it takes concentration to be able to eloquently phrase our thoughts in the way we want. The key to a good interview is to let the interviewee talk as much as possible, and record their reactions objectively.
The case for watching the hive
By their very nature, analytics represent averages of the entire ecosystem of users, so they are perfect for gaining insight into the hive. But they need to be taken with a grain of salt. First, analytics are generated using sampling from a subset of data. While smaller sample data resembles larger sample data, it is just a sample. Second, it requires experts who know how to properly collect data and extract analytics to get meaningful information back. Finally, adding the right dose of creativity ensures you get the right data back to answer specific questions.
At one company, I used analytics to identify which browsers users favored. I noticed a large portion were using IE8 (34%), arguably the worst browser ever. Further research uncovered one location with almost 100% IE8 usage. I knew of only one client in that city, and found that the client’s network used IE8. Our company could speak with them directly about updating their browser, so we could avoid countless hours supporting IE8. It takes a little detective work to let the numbers tell a meaningful story.
Trust in laws, practices and trends
UX laws are a misnomer. UX didn’t create them and they weren’t created solely for UX. These laws refer to a wide variety over centuries of human observations on philosophy, physics and psychology that have an uncanny application to interaction design. Among the more commonly known are the Pareto principle(19th century), Occam’s Razor(13th century), Gestalt Principles and Hick’s Law(20th century). More modern work such as Jeff Raskin’s laws of Human Interface Design provide more accessible approaches, and researchers discover more great stuff all the time. No need to limit yourself to three “laws”, when new work is being published all the time, such as the University of British Columbia’ study on “The Need for Attention to Perceive Changes in Scenes,” or this recent work on animating transitions in statistical data graphics.
The cynics may say best practices are whatever Apple, Google, Facebook, and Amazon say they are. In fact, these companies offer a great place to start. All together they heavily influence what users expect, and what they have come to learn about how things work. But sadly, “best practices” often turn into personal opinions during meetings. Arguments often ensue with comments like “Well, I think user prefer this…” or “if I were a user, I’d think it should be done like that…” Which is neither scientifically nor objectively “best” on anything.
Using only the Big 4 as guidelines for best practices can be limiting when you have a user task that is more complex than uploading a vacation photo. So consider other great products from Intuit, Ebay, or Netflix.
Keep your eye on trends especially when you know how they could affect your product. Trendspotting can help you figure out what to prepare for. Oddly enough, the Big 4 won’t be your best sources for trends. You can learn more about trends from nimble tech companies like Twitter, who have money and can afford to experiment with technology and have the agility to roll it back quickly if needed. Larger companies usually take time to roll out big changes, because of the high costs and risks. The best places to spot trends are start-ups, which are blank sheets of paper, that depend on innovation to set them apart. Techcrunch hosts a showcase of the best new start-ups each year called Disrupt.
It’s equally valuable to know which trends to ignore. Much of the internet is 7-10 years behind in technology. It’s pretty normal to find technology is struggling just to be current, let alone ahead. It takes a lot of good decisions to make a product that is ahead of its peers, and a little bit of luck.
UX publications deliver exposure to other teams’ research and findings. For example, Australian semi trucks were crashing into overpasses that were too short, in spite of large warning signs. So, Laservision created a water curtain stop sign that appears in front of the truck after all other signs have failed. I’ve found several sites to frequent such as iteration group, and projekt202 that help get inspired by others who solved unique challenges in creative ways.
Personal preference, the least scientific, but arguably the most influential in design. What it really boils down to is what the designer likes.
While UX strives to be as objective as possible, much of design is either subjective or entirely personal preference. On the other hand, developers are supposed to make it work on time and on budget. Ultimately the buck stops with the devs who are racing against time to deliver the final product by the due date. If they are worried about hitting that deadline, they are going to begin taking what they see as non-critical, too difficult to code that way, or just removing things altogether. That’s where UX takes on a negotiating role, working together with the devs to make sure nothing critical to the users get’s lost. Developers and UX work best when they’re collaborating. Which brings me back to my original observation, if we were all a band, we need to jam to make music!