Great user experience can rarely be added to a system after it's built. It has to be designed in upfront. That's why event modeling explicitly focuses on the user experience as the second step in the event modeling process. Event modeling is a visual medium that somewhat resembles another tried and true visual design medium; the storyboard of a film. The events that we discovered and sequenced along the bottom of our diagram in the previous step, represented the major plot points of the script. In this step, we'll place interfaces, consisting of graphical mockups of our UIs, along the top of our diagram, above their corresponding events, and these interfaces represent the frames containing concepts scene visuals in a storyboard. Finally, we'll represent the characters in our film by identifying the various audiences who will use our system and organize our interfaces into horizontal lanes, representing each audience. In contrast to commands, events, and read models, which are represented simply as a colored sticky note with the name written on it, interfaces are much more nuanced and labor-intensive. For that reason, it's important to select simple and familiar tools to produce these interface mockups. The goal for selecting a tool is to maximize participant productivity. Sometimes, low-fidelity tools are the best for getting started quickly. In physical, in-person workshops, printer paper and markers work really well. For digital workshops, you could choose a simple drawing tool. Other times, the team has already produced high-fidelity prototypes in a design tool like Figma, Penpot, Invision, Sketch, or similar, or perhaps they have screenshots of an existing user interface that the team can use. The key for the workshop is the ability to surface these high-fidelity prototypes at the proper place along our event model. The goal for both of these tools is participant productivity, so use whichever allows the designers to move quickly and efficiently. It's important to remember that interfaces do not have to be graphical, and interface represents the touchpoint that we provide our users to interact with in order to be informed of or to change the system's state. If our users are likely to be or to build software agents a web service API might be more appropriate than a graphical user interface. In other domains, specialized sensors or hardware like Barcode, QR, or NFC scanners might be the proper interface to bridge between the physical and digital realms. Finally, we can automate our own systems by using job-type interfaces, represented by a gear icon, that make decisions based on read model state, and issue commands on behalf of some group of our users. Here's what a section of the event model for our autonomous vehicle ride-sharing app, Autonomo, will look like, after completing the storyboard phase. We have identified three audiences here; vehicle owners, riders, and the vehicles themselves, identified by the small lane labels at the left. We've placed high-fidelity mockups of various user interfaces in the owner and rider audience lanes, and we've included a lo-fi placeholder interface for the in-vehicle NFC reader installed in the vehicle itself. These interfaces are vertically aligned with our corresponding events along the bottom of the diagram. Now that we can visualize the storyboard, we can iteratively improve the UX of our system. We can begin by highlighting interactions that don't seem right or need more work. Next, we can perform some lightweight user testing on the event model itself, with participants. Finally, we can continue user testing by bringing in friendly, nonparticipants to see if they can navigate our storyboard model, as a user. Our storyboard starts to bring into focus certain aspects of the state changes in our system and we should start thinking about these issues now, in preparation for the next step in the workshop, that we'll cover in our next module. First, users navigating among various interfaces doesn't necessarily comprise business state change. We'll make this point explicit in the next workshop step, but it's an important distinction to consider now. Next, we can begin to consider sources of information that populate our interfaces by asking ourselves questions like, "Where does this UI element get its data, and how do we populate this table?" Finally, we can begin to consider the state change triggers in our system, by asking ourselves questions like, "What happens when the user clicks this button or submits this form?" We've completed step two of our event modeling workshop by envisioning how our various audiences will experience our system, by creating a storyboard of interfaces and events. The purpose of our interfaces are to present information to our users about the state of the system so that they can make decisions, and then to empower them to enact those decisions by changing the state of the system. We'll look at how to model our system's ability to inform and empower our users in our next module. If you aren't already on Confluent Developer, head there now using the link in the video description to access other courses, hands-on exercises, and many other resources for continuing your learning journey.