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.

Goal-based Design

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.

Dictator Design

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.

§ 2 Responses to Basic Design Approaches

  • I wanted to note the temporal aspect here. In the lifecycle of a product, it seems that there are times when each of the design philosophies would work best.

    For example, if you’re in a product that’s slowly evolving (Office), it makes sense to focus on A/B testing and make small incremental improvements. This is because any radical switch (ex. introduction of the ribbon) – no matter how good it is – will cause frustration. Quoting my favorite Steven Sinofsky, “10% better is 100% different”. The improvement has to be large enough to justify the fact that your customer has to relearn.

    On a similar note, if you’re working on a v1 of a product, it makes little sense to use iterative A/B testing design to build the basics of your business. Get the broad strokes right first (and I think that careful, time-boxed scenario-focused engineering OR a dictator are actually both fine approaches here). Then, decide some aspects of life – most contentious, quantifiable aspects – through iterative design and A/B testing.

    In general, I see old businesses (Microsoft, Apple) obsessed with the gut-driven approaches (“we have a leader that knows this best”). New wave folks, on the other hand, are salivating all over the data-driven mechanisms (Amazon, Zynga, etc). This causes lots of “shots in the dark” that completely miss the mark from the large companies, and serious lack of bold bets that step outside the core from the new wave. Let’s embrace the happy medium.

    • Angela says:

      Certainly the main faults of scenario-focused engineering are Microsoft implementation faults (ex: it takes fucking forever). But the problem of designing for V1s is certainly worth discussing. You can’t start A/B testing nothing, but I’d argue that it is frequently better to get something out there and iterate on it than it is to sit around imagining stories about theoretical users…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Basic Design Approaches at Angela on Tech.


%d bloggers like this: