Discovery to delivery transition with Event Modeling
Event Modeling – what is it?
Event Modeling is a collaboration tool for the Product Manager, Designer, and Tech Lead. It provides the ultimate glue between the discovery phase and the delivery phase. Outcomes of Event Modeling will then be used multiple times, by many people.
| Participants | Product Manager, Team Lead, Designer |
|---|---|
| Participants | Product Manager, Team Lead, Designer |
| Outcome | The specification by example in visual form. |
| Phase | Discovery & Delivery |
| What is next | - For UX Designers: Customer Journey, - For Product Manager: Extensions - Insights, planning/staging, costs - For engineers: Design Event Storming, Code generation, |
Let's see the modeled software after executing Event Modeling:
Few observations:
Even when you haven't participated in the workshop itself, you can read and figure things out on your own. With little legend, things become more apparent:
On the top, we have mockups. They can be organized in swimlanes - usually each for a different role.
Below the timeline, we have intentions/commands placed in blue boxes. Usually, those are linked from UI.
When they are processed by the system, some facts are memorized, represented by orange blocks. Those facts carry information that is described in a block.
When facts are memorized, we'd like to interpret them and show on view. Then facts are connected to green boxes. Those, later on, are usually linked to UI.
People communicate through stories; asking questions about it is convenient.
One storyline is enough for most people.
Proper story visualization significantly drops a cognitive load.
Linking cause and effect is powerful, and people are keen on doing it.
How to transition from Event Storming
The result of Event Storming is a board full of events, hot spots, external systems, and users. Events are usually partially ordered. From one diagram, one can extrapolate many different storylines. We don't yet know what the system should look like, but we do understand the business process very well.
Let's see the recipe:
Select a happy-path story full of events, that we want to model in the context of an information system.
Order the events in one line and put them on the top.
Start filling in the gaps. Pick the first event, imagine the interaction with the system, and ask questions that let you drill into the details:
If the event required the system to memorize facts: 'Purchase made', or 'Ticket booked', etc - then it remains the same, nothing changes.
If the event contains a 'presentation verb/selection verb' that does not need the system to change it's behaviour - for example: 'Menu seen', 'Product selected', then we should convert those events into views: menu view and product list, respectively.
Discover all the blocks moving forward using typical Modeling Evolution discovery key questions. You can find them here in the presentation below:
Switch to alternative scenarios when needed. Many people ask a question: "Event modeling is a single timeline; I cannot model a branch, so should I model all combinations?"
Not all combinations, but only the ones that trigger discussion and thus require space for it to happen. When you don't need a long debate and want to model a BDD failed scenario, then you wish to model it quickly just by stacking relevant blocks on top of each other.
When required, extend your model. Read more about typical extensions and transitions in our Resources.
CTOs takeaways
Money is one of the biggest motivators. In digital-product companies, innovation should be incentivized. The question that arises is how to align it with salaries structure. With Event Storming & Event Modeling, you have all the tools at your fingertips. You can make your delivery genuinely repeatable and predictable. And you can innovate rapidly in an agile spirit in complex systems.