The business case for design: ROI

Peter Merholz of Adaptive Path explained his view that customer experience is an investment, not a cost, in an article this week on Harvard Business Publishing’s site.

I adapted one of the “linking elephants” illustrations in the Merholz article by adding another row of boxes and text to illustrate what Merholz says: it is design that motivates people to modify their behaviour. I also added an ROI or return-on-investment calculation.

merholz-linking-elephants

Design makes the difference. By “design” I don’t just mean how it looks; I’m including the mental model (how the site visitors or users think the site meets their needs), the workflow and interaction (how users complete the task), the experience (including how users feel about using the site), and the prototyping and formative usability testing needed to validate the proposed changes. Your business case needs to include the cost of all this design work.

Making a business case can be intimidating, but the above illustration shows that it’s conceptually easy. In your business case, you predict the benefit to the company of a project, using the best estimates you can come up with. What would be your organisation’s goal? What behavioural change on the part of site visitors moves you toward that goal? What is that behaviour worth, either in revenue or in reduced costs? How many site visits do you get per week? What’s the potential impact to your organization of redesigning part of your site? After you implement the new design, you use summative testing and comparisons to get feedback on the assumptions of your business case.

I recommend reading Merholz’ article on the Harvard Business Publishing.

Validating your development method

On Agile product design, I read:

If you tell someone about a great idea, and they say “That’s a great idea,” it’s not a pattern.

If you tell someone a great idea, and they say “Yes, we do something like that too,” that’s a pattern.

 Exactly! That’s why I speak about Five Sketches™ at conferences and professional development sessions. And that’s why I post and write about everything I come across that’s similar to Five Sketches™.

Design Studio was the first undeniable indication that we’ve solved a problem that others in software development and web development are experiencing. That’s because the Design Studio method is very similar to Five Sketches™. Two completely separate teams, in different countries, came up with nearly the same solution to their respective design-process challenges. Design Studio was developed at Jewelry TV by Jeff White and Jim Ungar.

I do that, too!

Here are some more methods and techniques that are similar to parts of Five Sketches­™.

  • Low-fidelity generative design. There’s a huge benefit to exploring and evaluating a range of interaction concepts while involving both business and technology partners. This is, in effect, the divergence stage of generative design advocated by Bill Buxton, and done with low-fidelity. Adaptive Path does this with sketchboarding. Five Sketches™ does this by using mixed teams to separately sketch five ideas per participant, and then iterating from there.
  • Parallel design. This is supported research and advocated in the book of guidelines from Usability.gov. To ensure parallel design, Desiree Sy at Autodesk uses interns to prototype 10 or more design solutions to a design problem.
  • There’s much more that’s already been posted on this site. Use the Search box on this site to look for posts about generative design, design studio, creative hacks, Leah Buley, Bill Buxton, Scott Berkun, Jeff White, and Jim Ungar.

Generative design vs. Five Sketches™

© Leah Buley, from her presentation on SlideShareLeah Buley talked about generative design at the South by Southwest Interactive conference, today. Buley feels design methods are lacking in the set of professional tools we use for software development: “We don’t have so many good, reliable, repeatable design techniques.” I agree with her.

Buley tells how, in her first design session at Adaptive Path, she was handed a pen and paper, and told to sketch. The point was “to crank out a lot of ideas in a short time.” That’s what generative design is all about: saturating the design space with ideas. Design programs teach generative design, but there’s no generative design taught in programs for developers, QA staff, technical communicators, product management, or marketing.

There are already several design methods for software development teams to choose from, including Buley’s wonderful grab bag. Others I know of are Five Sketches™ (obviously) and Design Studio, both of which focus on the complete process of producing a design, start to finish, with all its challenges. Microsoft’s Bill Buxton told the UPA 2007 conference that he insists on generative design, and I’d love to see that in action. Each method differs slightly, but they all work because….

Why do they all work? Because of generative design. Generative design addresses what Buley calls her “dirty secret.” She freely confesses, about her design work before Adaptive Path: “I had very little confidence that what I was presenting as the design was in fact the one, optimal solution to the problem.” My experience teaching Five Sketches™ tells me that once you’ve participated in a generative-design process, you’ll know that you can have that confidence.

Buley’s great presentation (slides with audio) is here. Have a look:

A tangential question: when will computer science programs teach Basic Design Methods?