User stories are the building blocks of product design

Explaining product design to clients is often harder than it should be

Too often people, even (especially?) ‘software people’, can’t separate the actual product design from its more concrete constituent parts, such as visual design and even coding.

_{Aside:  See this excellent article on how visual design is not user experience design, much less product design: http://insideintercom.io/the-dribbblisation-of-design/}

‍

Part of the problem is that its hard to see product design

You can see mockups, you can see code, but without either of those things how can you ‘see’ the product? Sure you can create mockups to help explain the product, but creating thoughtful and useful mockups is time consuming and without a good product definition you are likely to waste a lot of time mocking up the wrong thing.

User stories, while usually used to guide and manage software construction, are about the purest form of product definition you can have yet still be useful. Anything more vague and its hard to judge the value/cost of the item, and anything more detailed gets distracting due to a focus on the ‘how’ a feature works instead of what the feature actually is.

‍

User stories have two additional key features that make them ideal for product management

Anyone can create them: This is unbelievably important. Any person related to the project can quickly and effectively (with a little coaching sometimes) can create, edit, and understand a plain-english story. They may not know all of the tradeoffs or edge cases, but they can get the conversation started. Mockups, prototypes, even traditional ‘requirements’ need a certain skill set just to create them, and thus creating another layer of indirection between the person with the idea in the first place.

They are useful throughout the process: If you start with stories, and build all of your management and development around stories, they become the common language that connects everyone involved with the process. Product owners can describe them, developers can implement them, and testers can verify they work, and (to complete the loop) product owners can confirm the software does what is needed.  No need to translate a document into something consumable by the next guy; everyone knows what to do with the stories.