Basic Design Approaches
October 8, 2010 § 2 Comments
There are a couple of basic approaches for solving design problems in the tech industry. When I started to write this post, it was about the failings of scenario-focused design (I was forced into a pointless scenario-focused design brainstorming session recently…). But, I realized that I needed a more balanced take – so here are my thoughts on common methods for approaching design problems:
Scenario Focused Design
At Microsoft, this is the party line. We have an entire division of people shaping “best practices” and they preach this as gospel. With this paradigm, a designer starts with an audience, represented by a single person. For example, I work on a small business application, so I’ll design for “Jane”, an interior decorator. To me, “Jane” represents all personal services companies with less than 5 employees. I spend time with Jane, understand her needs, watch her work. I learn about her pain points. I then design to address these pain points.
Who uses it: Office. Oh Office.
Pros: You are designing to solve real problems that actual people encounter. That is good.
Cons: It is noble to extract the user needs from the technology. However, with the decades-old Office code-base it is also pure fantasy. Office wastes months of design time starting from scratch, only to make iterative improvements to very mature products. I imagine end-users telling Word PMs about trouble sharing docs, but that will inevitably translate to “better integration with SharePoint”. Trust me, better integration with SharePoint doesn’t solve anyone’s problem.
My take: Understanding high-level user needs is important, but doesn’t necessarily lead to good, usable software.
Iteration and Data Driven Design
This is a design invention made popularized by internet apps. The goal: instrument everything. Everything you do on a website — how many links you click, how long you spend on each page, each step you take in a wizard is tracked and reported upon. Design decisions are made based upon the data collected from the website. Designers make changes based upon any identified problems or bottlenecks. Frequently, this strategy involves multivariate testing of different designs, until an ideal design is found.
Who uses it: Google, Zynga, pretty much any legitimate online business
Pros: Design decisions are based on data, not intuition. No speculation needed about the best design – statistics solve the arguments for you. I like using this paradigm gauge the interest for new features, as well. For example, if there is a discussion in the Zynga office about adding a feature to Farmville, they’ll put up a link saying “get this feature”, and track how many users click on it. If enough users click on it, they develop the feature. Engineers understand and like this approach.
Cons: You can take this too far. For example, Google multivariate tests different button border widths. Why? Also, if you have any great designers on your team, this approach isn’t the best way to take advantage of their talents. And you may alienate them. See Google. Also, while this paradigm can help make iterative improvements, it may not point out bigger issues. If you aren’t fundamentally solving a real user problem, who cares that they can get through your wizards?
My take: Asking what users want is unreliable. Tracking users, and making decisions based on what they do is ideal. If you have a product and a team is full of smart people (but no user experience visionaries), this is a fantastic design strategy. I believe some level of data-driven design is absolutely fundamental to modern design. But it isn’t a way to create innovative, visionary software.
I’m actually making this paradigm up, but plenty of people design with goals, especially at Microsoft. Goal-based design starts with a mission statement. Something like: I want to fundamentally change the way users interact with data, I want to increase my search engine market share, I want to enable people to view cute pictures of cats with silly captions. At Microsoft (the epicenter of platform technology), goals are frequently more useful than scenarios. The design isn’t addressing user pain points – it’s pushing the envelope.
Who uses it: Bing, Pivot
Pros: This paradigm is ambitious and allows you to develop software beyond what your users can imagine. Take Bing for example, they aren’t solving real user problems, they are completing with Google. Google as a search engine is completely usable, Bing’s only hope is to change user’s idea of what a search engine should do. This is why Bing markets themselves a “decision engine”. Remarkably, this single minded devotion to increasing market share has increased market share. I don’t think it’s created any great UX though.
Cons: It is easy to get off track, and make technology for the sake of making technology. It is too easy to lose sight of what the user wants and needs. A great example of this is Live Labs Pivot. As “data visualization technology” it is innovative and interesting, but it doesn’t have any grounding in user needs.
My take: Combine this with scenario-focused design, and data-driven design you might have a strategy. It doesn’t work on its own.
Not much explanation needed here. The team has a ruthless leader with a vision.
Who uses it: Apple
Pros: The only tech I’ve ever seen that is beautiful, usable, and useful falls into this category. A team of great designers can put together something beautiful. Anyone with access to a user research lab, or A/B testing can make something usable. Good PMs can make useful software. But that combination of all 3…. That is something.
Cons: Like all dictatorships, it only works when you have a fantastic dictator. You also need a team that communicates well with the leader, because the leader can’t possibly be involved enough in the minutia to recognize potential technical issues. I feel like this is where I should fake cough iPhone 4.
My take: Find yourself a benevolent dictator ASAP.