Test-Driven Product Design

One way to drive more effective product design is to start with scenarios.  One way to think of this is “Persona-based scenarios with goals.”  You can use the scenarios as test cases.  The scenarios can help you evaluate the design and they can help you evaluate implementation.  Simply put, “Can the persona or user perform the particular scenario effectively?”  You can then use criteria to evaluate.

It’s test-driven product design.

You can imagine how you can start with key themes and then break those down into more specific groups or frames. You end up with unit tests for experiences or scenarios and you can evaluate key things.  For example, if you were doing a competitive assessment, you might evaluate against the following criteria:

• Complexity
• Time to implement
• Out of the box experience
• Compliance with best practice

The frames approach is a common approach for how platform competitive assessments are performed.  That’s why we adopted it as an approach for how we do prescriptive guidance … it’s a proven practice for mapping out the problem domain within a given domain or space.

Example Scenarios Map
This is an example of mapping out core scenarios, in this case, developer scenarios for source control:

Example of Sub-Scenarios
This is an example of elaborating the core Branch/Label/Merge scenarios above:

There are many ways to gather, organize and use scenarios.  In the end, what’s important is that you have the user scenarios validated with the actual users, and that you use them as a hub to bring together the customer, the developers, and the testers.

The beauty is that you can re-use the scenarios, whether it’s to explain your product, write documentation, or create prescriptive guidance.