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.