Event Storming and User-Experience Driven Design

Introduction

User experience driven design (UXDD) and event storming are two complementary analysis methodologies used for designing applications from the point of view of the user (or process). What this means in practice is that they are tools for establishing what the user wants up front before delving into the technicality of how that can be provided.

Background

There is a flippant remark that "The way to make a statue of a horse is to start with a block of stone and cut away all the parts that do not look like a horse".

We recognise that this is a silly saying and yet all too often, we approach software analysis in exactly that manner - asking the users (or stakeholders) to make decisions about how the system will be built that are quite beyond their level of expertise - and end up with the business effectively saying "I'm not sure what I want but I'll know it when I see it".

Event Storming

Entities are about what things are, events are about what things do. It seems we have dedicated far too much effort modelling what things are to the detriment of what things do.

An event storming meeting is a meeting between a small number of analysts and a small number of business domain experts. Good meeting management dictates that the numbers must be kept low (the famous "two pizza rule") and you must be prepared to have multiple meetings to get the information if you need more domain experts than this.

The equipment you need is a common space (a whiteboard, blank wall or large table) and post-it notes. You then start by identifying the "things" in your system and for each of these, you identify as many events that can happen to that thing as possible. You then write these up on the post-it notes and cluster them together around the "things" of the system.

Where an event involves multiple things, you write a separate post-it note for each impacted thing - don't try and connect them together as this is premature solutioning (as bad in the analysis world as premature optimisation is in the coding world).

It is important that all the things and events are written in the language of the business, not in technology terms. For example, in business terms, an order is "placed" not "created".

Example: Events Occurring for a Cow

Then you can expand the events to add a note of what information you can capture for each of these events. At this stage, it is not necessary to decide if each bit of information is mandatory or not, and the output from this should not be considered the "definitive" data for the event. Further analysis may unearth more data that is available or required.

User Experience Driven Design

The next stage is to take the events (and "things") that were discovered in the event storming session and ask "how does the information for this event get into the system?". In nearly all cases, this can be one of two ways - either data comes from another system (or a sensor or some other non-human input) or it has to be entered by an operator.

For those events that have to be entered by the human user, we need to design a screen layout to allow this to be done. Typically, the layout for this would be created by some prototyping tool (such as Balsamiq) so that the user can envisage entering the data for the event.

Then we need to design screens that present any data that the users need out of their system in order to perform their business function. It is very likely that this will vary by the role of the user viewing the system - for example, the accountant will want to see the value of orders and stock, whereas the warehouse manager will want to see the items and locations needed to fulfil an order. Again, the use of a prototyping tool will work here.

At this stage, you need to get a signed-off document from these prototyping tools and event descriptions - this is your user experience contract and, so long as this is delivered, how you implement it under the covers is your (technical) concern only.

Objections and Blockers?

One of the possible objections to user experience driven design is that it doesn't address the architecture and technical side of the system - but this is not the case. What it doesn't do is address those aspects with non-technical people. Instead, you make a commitment to deliver the experience the user requires and they will let you take care of the details in whatever way suits the system best.

Worked Example

The top level requirement for our worked example is to Create a system to allow the management of a meet-and-train running league to improve or replace the current intensive manual system.

The first look at this system leads us to believe that there are three very distinct views of the system depending on the user (or use case) present. For the league organisers, they want a system to track team performance, membership and so on. For the race organisers, they want to be able to track the runners finishing times and positions reliably, and for the individual runners, they want to be able to track their own performance over time. The decision was therefore made to split the application into three domains.

Domain 1: The League

The league domain is responsible for registering teams and individuals, scheduling the races and tracking the results from those races to create a league table, etc.

We arranged an event storming session with league representatives and also with some runners and marshals. This larger group was chosen so that (a) no design constraints would be introduced at this level that adversely impacted the other users and also (b) that the concept of event storming could be introduced to everyone at the same time. We wanted these stakeholders to feel that they were designing the application as this would give them more ownership of the process.

The event storming session was restricted to what events the system should capture and how they correlated to the things we needed to model. A conscious decision was made to delay talking about how the system would look (or even on what devices it would be available) as in our experience, the exploratory phase of system analysis can be shut down quite quickly if design decisions are involved.

The entity types identified in this session were:

• Race - a single specific scheduled event
• Season - a defined set of races after which overall winners would be identified
• Team - a number of runners competing together as a team
• Club - An organisation the team or individual runner could belong to
• Runner - an athlete registered with the league

For each of these, we were able to determine a way of uniquely identifying them and to determine an initial set of events that could occur to them. It is not essential to capture all of the events at this stage nor indeed all of the attributes pertaining to the event, as these are often discovered as the analysis proceeds.

The UXDD step comes next. For each of the events where the data comes from a human, we need to design an input screen and for each set of information that the league wants to extract from the system, we design a display screen and/or report. These were done as pencil drawings so as to keep the focus on the overall idea rather than the deep dive design elements of colour and font.

Domain 2: The Race

The race domain is responsible for the organisation of each individual race that has been scheduled by the league. This means recording the position and time of each runner as they cross the line, and tracking how many runners have completed at any given point in time.

Initially, we thought that there was a big overlap with the league domain but after a while on the event storming board, it became obvious that the only entity type that mattered at this level was the runner. We decided to use the same unique identifier (runner number) as for the league domain.

The UXDD side of the race domain is also quite interesting - runners want to know their time and position as they cross the line, but they really don't want to have to do anything to input to the system as they should be literally on their last legs crossing the line. Therefore, we still need race marshals to do the actual input side.

Domain 3: The Runner

The runner wants to track her or his performance over time and to have a social feedback aspect which encourages training and participation. They may also want to track races external to the league and training schedules and all sorts of other information.

From a UXDD point of view, the runner also wants to be able to control what is shared with other registered users and what is private. In conversation with the representatives, we found that most people felt that using either a smart device or a website was best - we decided that a mobile-freindly website gave the best coverage rather than having device specific "apps".

History

• 2015-11-18: First cut
• 2016-03-24: Added worked example