Product Planning Series: From use cases to storyboards

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This is the fifth post in my Product Planning Series.

My approach to product development revolves around user-centered design. The basic tenet of this philosophy is that the product team must be equipped with a thorough understanding of the end user’s needs, wants, expectations and limitations in order to create an excellent product solution to solve the user’s problems.

This understanding begins with user personas at a high level and becomes fleshed out via use cases and user stories.  The UX design team can then ideate on a solution to the problems the user is trying to solve and create storyboards to imagine how the solution may be implemented in the context of the product.

The words “use case”, “user story” and “storyboard” can mean different things to different people.  This is what I mean when I use these words to describe the tools and artifacts I use in the product design process.

  • Use case: A high level thought experiment of a workflow from a user’s perspective.
  • User story: A brief description of a part of a use case or storyboard that succinctly defines a task the user has to complete, from the user’s perspective, with no assumptions placed on design or implementation. Used to describe functionality that will go into a backlog to be prioritized and managed by a product owner (in classic Agile methodology)  It is usually much more granular than a use case and describes a snippet of what the user needs to do to complete a workflow.
  • Storyboard: An output of the design process that illustrates the experience of the user in a journey to complete a workflow using the product. In my experience, this is the fastest and most effective way to turn a high level UX idea into something concrete that the product management team can use to test with customers and the product development team can use to plan their work.
I find that these three things are fairly universal in their applicability to all kinds of products, hardware and software alike.   In cases where the use cases are complex and the solution is non-obvious, it is vastly faster and cheaper to iterate a design idea at the storyboard level than to code it up and then review the actual working code output.
With the right talent on the task, one can literally come up with 5 or 6 storyboard iterations in a single day without investing in any engineering development.  The impact on software products is substantial – it can take weeks to program just one of those iterations, so storyboards saves time and money in a tangible manner.  The impact on hardware products is game changing – a single iteration for a hardware implementation could take months or longer.  Storyboards allow the product team to iterate, test and learn, so that we can come up with a better end result in a shorter period of time with the least possible investment in engineering development.
Once the product design is vetted at the storyboard level, it becomes much easier to fill the rest of the design gap with a detailed design solution, and development will then be able to implement the design efficiently and effectively.
Advertisements

6 Responses to “Product Planning Series: From use cases to storyboards”


  1. 1 Alex August 24, 2011 at 1:32 pm

    Nice article. Can u reccommend any Mac software which aids in creating storyboards for prod dev?

    Thx

  2. 2 Elaine Chen August 24, 2011 at 6:26 pm

    Dear Alex,

    For software wireframing I like Balsamiq http://balsamiq.com/products/mockups – it runs cross platform (it’s an Adobe Air app). It’s mentioned in this wonderful top 10 list on this web design site. http://webdesignledger.com/tools/10-excellent-tools-for-creating-web-design-wireframes.

    For hardware I am embarrassed to say I am low tech – I draw with pen and paper and then scan or take a picture 🙂 I’ve tried a few drawing apps on the iPad2 but found that the interactivity is still lacking, plus it takes me more time to upload the pix than to scan to a target destination using the auto feeder. So I gave up. Maybe someone else would have a suggestion?

    Hope this helps!

    Elaine

  3. 3 David Erdos September 27, 2011 at 11:23 am

    Hi Elaine,
    Great article! How would you recommend evaluating different storyboards with respect to each other? Specifically, how do you determine which storyboard actually gives the user a better experience?

    Particularly with respect to hardware, how you can validate and compare different user experiences? Without the physical hardware present, it would seem difficult to compare different user experiences; although I guess this depends heavily on the type of hardware product.

    Thanks,
    David

    • 4 Elaine Chen September 27, 2011 at 8:12 pm

      Hi David,

      If the product is not so new as to be completely alien to the end user I would bring a few storyboards to potential users, talk through the use cases / scenarios and see what the users think. This of course only applies for things that can’t be cheaply prototyped (e.g. if you are making a web app it’s best to just prototype an interactive demo – even interactive html/css is better than a static storyboard.)

      If you are doing hardware, and the hardware is way too big / complex to prototype cheaply and you have no budget (e.g. you are making a new piece of farming equipment to compete with John Deere, for instance), you’d have to draw on experience and gut feel to help you evaluate competing proposals for user experiences.

      If it’s a small enough hardware product (e.g. a handheld consumer electronics product) we often made non-functional prototypes. This lets you (a) feel the prototype in your hand to see if it is right from a human factors / ergonomics standpoint, (b) mime your way through use cases so you can imagine using it in real life – this helps you figure out if your theoretical use cases make any sense in real life.

      For reasonably sized products, you can make form models very quickly if you know someone who can bang out a foam or foamcore model for you. Alternatively, (and I prefer this,) you can get a designer or mechanical engineer to hack up some surfaces in something like Rhino or Solidworks, then shell the thing and send it to an RP vendor to make a rapid prototyped part (SLA is my method of choice). Something the size of a mouse, shelled, would cost you a couple hundred bucks, but the ability to have a dimensionally correct model to play with in your hands is truly priceless.

      Hope this helps!

      Elaine


  1. 1 Product planning series: Planning a new web app « Startup Musings Trackback on June 18, 2011 at 10:07 pm

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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




Twitter Updates


%d bloggers like this: