The scenario is a key artifact in our design. It ties together the personas and their objectives with their workflows and pain points. It forms the basis we derive solution requirements, like release hills. And the way we validate our design using playbacks.

There is a large variability in how I have used scenarios across Green Threads, GDD, CLM, SLM, PLE,  and IoT projects. A few examples are given below. All scenarios use a visual representation of the scenario flow as Acts and Scenes.

Scenarios always benefit from a context or a story. It builds on the personas and provides an organizational context to the individuals. For example, in the scenario for Global Development and Delivery (GDD) we tell the story of a global organization sourcing work to near-shore and off-shore teams.

In the Story below I describe the personas, their objectives, and hint at their geographical distribution.

Then, on the Solution, I discuss more their responsibilities and activities. And I indicate the application artifacts and tools each of the personas is interacting with. The relation between the personas and the artifacts is key in the Application Lifecycle Management (ALM) scenarios. Note that colors also give hints on their geographical distribution and artifact ownership.

I find it valuable to have a single page outlining the overview of the scenario. It becomes a great image to present the high-level objective and flow of a scenario and its personas. Two examples below from initial GDD scenarios. And later scenarios for ALM.

I use scenarios to report on solution gaps and user pain points as we declare state our as-is and to-be products. Two examples below from capturing tool gaps and user pain points.

A final example from the design of First-day productivity for the Systems and Software Engineering solution. The scenario outlines the discover-try-buy scenario, the personas, and their interactions in exploring and adopting the solution in a project.



Learn more about IBM Design and IBM Design Thinking on