Welcome to Part 2! In Part 1, we laid out some of the high level components of the system and established that we are going to build the system with a user interface driven mindset.
In Part 2, we’re going to discuss that mindset in greater depth before we start designing our system.
User Interface Driven Development
User Interface Driven Development is not an official practice out there with a swath of books and gurus. I’m using the term for lack of any better terms or official practices that I know of. It shares a lot with Behavior Driven Development and Use Case Driven Development and similar approaches. The primary difference is emphasizing the physical interface that the user will use to interact with the system earlier in the process.
But wait! You shouldn’t do that, you say! Many system design practices de-emphasize the UI. They focus on the abstract use cases, with the line of reasoning that the system may need to support several different interfaces, or that the interface details will change often, while the core system behaviors will change less often. For example, in Clean Architecture and Hexagonal Architecture (Ports and Adapters) the UI is treated as a pluggable implementation detail. Those are both great architectures, and great ways to think about your system and how to build it in a maintainable way.
It isn’t just programming-centric system design methodologies that de-emphasize the UI. It is also common practice in UX design workflows to save UI design to the end. Start with wireframes and low fidelity designs. Get the users focused on the high level system behaviors without getting bogged down in easy to change low level implementation details.
There is also a cost component. It can be more expensive to develop a fully working user interface than to create use cases and develop wireframes. That doesn’t have to be the case, but you need the right technology infrastructure, which may cost you something to learn and/or develop at some point. It is also worth considering the cost of the whole project. Maybe it costs more up front to develop a full interface, but what is the cost of a project that delivers an interface that users hate?
I am not opposed to any of those approaches, or suggesting that you shouldn’t use them. They are great practices, and great tools to use for system design. You should learn them, try them, and get good at them. What I am suggesting is that the focus should be shifted a bit.
There is a key word here – Experience. When a user actually uses the system, they don’t experience use cases, or wireframes, or any of the other design stages that you go through. They experience the user interface. You delight your users by delivering a great experience through the user interface. It’s not just the way it looks, and it’s not just the way it behaves. It’s the combination of the visual and the audio and the sensory experience of using the interface with the mental experience of navigating through and using the system. The user experiences all of those aspects of your system together as an integrated whole. It all has to be good, and it all has to be good together. Like a symphony. Everyone has to play their instrument well, and they all have to coordinate and play them well together. So the focus here is on delivering the full experience as early as possible and iterating on the full experience as a whole.
Consider this. You need to design a game. Is the physical interface for the game in-person in the real world, or digital on a screen? That is a hugely important detail. There are a tremendous number of considerations that need to be taken into account in the physical world. Safety, cost of materials to play, and so forth are all central features to the experience of playing the game. For something like football, or rugby, or martial arts, or war games – those are critical considerations. Even for something as tame as a board game, things that work well in the digital space don’t necessarily work well in the physical space. Shuffling cards and moving pieces around is trivial in digital land, but can be cumbersome in physical land. Even with the exact same ruleset, the experience that a user has playing the game can be completely different. The physical interface that the user interacts with matters a great deal.
There are also practical system design considerations that come into play. Many hard to change decisions about how information should flow through the system have to be made. The User Interface can play a significant role in how those decisions should be made. Deciding on whether to use push vs pull messaging, deciding on which areas of the system state can live in, deciding on what state needs to be persisted… these are all decisions that may be influenced by the user interface. The user interface defines many of the constraints for the system.
Hopefully by now I have convinced you that it’s at least worth considering emphasizing the user interface earlier in the system design process. Without further ado, here is what this process entails, loosely in order:
- Define the physical interface the user will use to interact with the system. Is it a GUI, or a CLI or other text-based interface? If it is a GUI, is it primarily mobile, i.e. small screen space, or desktop or TV, i.e. large screen space? Will there be more than one physical interface?
- Define the actions that the user can perform.
- Define the states of the system that the user can observe.
- Define the views will display those system states.
- Define the controls that will dispatch those actions.
- Define the screens, pages, or other high level views that tie those pieces together, and the navigation between them.
Conclusion
Now that we have established our process for designing this system, we are ready to move on to Part 3, where we will apply this process to design the Game Client.
