It’s no secret that tech developers and senior executives don’t understand each other. Execs tend to have lofty ideas for the perfect customer experience. Developers are constrained to what the technology is actually capable of. Luckily, product managers came along to try and mediate the developer-executive relationship. But even still, miscommunication and frustration seem to dominate software development these days.
That’s why Adam Dymitruk, in a stroke of genius, dreamt up Event Modeling. Adam makes the point that story-telling is the innate human way to convey information. “Our brains are built for [story-telling] more than they are built for flow-charts and other formats”. Event Modeling harnesses the commonalities in the human thought process and memory storage. It creates a shared language–a language that developers, senior executives, product managers, and designers all understand.
Event Modeling is a way to graphically represent change in a system over time.
A simple way to understand Event Modeling is with an example of a customer checking into a hotel. There are four components to the process:
First, you and your team brainstorm the fundamental steps in a user’s journey. Next, place them on a simple, graphical timeline. You tell the story of the user’s journey. These steps are called events. It’s important to keep in mind that events are specific occurrences that change the state of the process. In our hotel example, a customer uses an app to check-in to a hotel, leaving one less room available to other customers. Events are represented by orange sticky notes.
Events can only change the state of the process after the user gives a command. In other words, the command precedes the event. In a hotel reservation interface, the command would be the user selecting “check-in.” The event is a result of that command: “checked-in.” Commands are represented by blue sticky notes.
Next, the read-model. Read-models are the result of the command-event chain. It’s what the user can see. The user selected “check-in”, then they were “checked-in.” The read-model is a calendar that displays room availability for certain dates. Read-models are represented by green sticky notes.
Interfaces (or wireframes) are simple mock-ups of what the interface could look like. This helps the visual learners in the group. It also gives non-designers a chance to give their input on what would make a nice user experience. Pretty simple, right?
It’s time to improve your company’s software development process.
The software development world was ready for a big change. No more miscommunications from developer → product manager → designer → executive. Event Modeling simplifies the communication process. Executives can understand what’s actually possible. The developer can understand exactly what the executives want to deliver to their customers. The designer can make it all look beautiful. And, no one shoots the poor product manager.
That’s Event Modeling in a nutshell. If you’re still curious about the ins and outs of Event Modeling, check out the rest of Adam Dymitruk’s technical writing piece that’s featured on his blog.
As for why you need oNote? That’s a whole long list of things that we’d love to talk to you about.