What you need to create is a clear overview of the system you\u2019re all about to build \u2013 you need system design (not to be confused with a design system<\/a>). This sounds simple, but can be incredibly challenging in practice. After all, how do you go about mapping something that doesn\u2019t even exist yet?<\/p>\n “System design forces everyone into a shared common understanding before embarking on the process of building”<\/p><\/blockquote>\n System design, then, is an act of creative cartography \u2013 it is like creating a map in advance of creating the territory. But it\u2019s also incredibly valuable: it forces everyone into a shared common understanding before embarking on the process of building.<\/p>\n Maybe I\u2019m asking for trouble here: I\u2019ve chosen to write about what is probably the most abstract part of the entire design process, that of forming conceptual ideas and trying to inject a picture of those ideas into a colleague\u2019s brain. This is why many of us struggle with this stage. However, I think you can break it down into relatively simple terms.<\/p>\n In practice, system design work usually takes the form of a diagram: boxes and arrows describing the main parts of the product, and how they all connect to each other. As we\u2019ve written before<\/a>, a good system design defines the following:<\/p>\n Creating this map is often an emergent process that happens collaboratively at a whiteboard (still the best tool there is for creating system designs: quick and dirty, modifiable, collaborative, and impossible to get lost in details). Given that it might be another while until any of us sees a whiteboard again, tools like Miro<\/a> are a great digital alternative. But the ultimate output is almost always the same: a clear diagram illustrating objects and the relationships between them.<\/p>\n An example of system design for part of Intercom<\/em><\/p>\n You might think you can dodge this hard bit and just quickly talk it through instead. But language can be slippery: what I\u2019m thinking and what you\u2019re thinking may be significantly different, even though we\u2019re using similar language.<\/p>\n What\u2019s more, most products that require this level of mapping can get complicated quickly. It can also be hard just holding a clear picture of a complex system in your head.<\/p>\n So you need to be able to diagram those ideas out. Get your map down on paper. And most importantly, the team needs to get aligned on what we\u2019re building.<\/p>\n Getting to that point, however, can be tough. Here are some common challenges you might encounter:<\/p>\n Herein lies the very point of doing this work. All of the things that make a canonical system design difficult to nail down are the reasons it\u2019s worth doing. It\u2019s difficult because it forces you to resolve ambiguity, ferret out unknown unknowns, get super-specific about how the system will work, and agree on it all.<\/p>\n The goal is to hammer out these differences early on, while doing so is still cheap. You don\u2019t want to realize you\u2019ve all been singing from different hymn sheets several months into building something, and then take on an expensive course correction. You want to figure all that out at the very start.<\/p>\n “You need to create the scaffolding for how you want your stakeholders to interrogate the system design”<\/p><\/blockquote>\n So inevitably you reach the point where you think you have something you\u2019re happy with. Now you just need to get everyone on board.<\/p>\n Just like when you\u2019re presenting mockups for feedback, it\u2019s not enough to just present your work on screen and expect instant alignment. As a designer, you need to create the scaffolding for how you want your stakeholders to interrogate the system design and structure their feedback, and not get sucked back into the misalignment that your work is intended to solve.<\/p>\n Most likely you already know how to do this. It probably happens all the time in Design Crit<\/a> when giving UI feedback. You deliver your comments in terms of generally agreed principles.<\/p>\n For example, when giving UI feedback I try to frame any feedback as objectively as I can. \u201cI don\u2019t like the way you laid out that toolbar\u201d is bad feedback: it\u2019s subjective and closed-off. \u201cMaking the toolbar layout more like our other menus would increase consistency\u201d is better: it\u2019s couched in a well-understood principle (consistency) and opens the door to discussing rationale tradeoffs.<\/p>\n “There\u2019s no Fitt\u2019s Law or Gestalt Principles for boxes and arrows”<\/p><\/blockquote>\n This approach to giving feedback is well-established when critiquing UI design, but there\u2019s no Fitt\u2019s Law<\/a> or Gestalt Principles<\/a> for boxes and arrows. And so in many cases the feedback can quickly become loose, reactive, and subjective.<\/p>\n When faced with a recent situation like this at Intercom, a group of us aligned on the following principles for assessing a system design. Rather than assessing the design and relying on overly subjective interpretations (“I don\u2019t like it,” or “That\u2019s not exactly how I think of it”) we tried to assess how well the system design stacked up against the following criteria.<\/p>\n (Note that these are not presented as universal principles of system design, but rather ones that worked for this specific project. Hopefully they are useful examples, but I urge you to take a shot at your own list.)<\/p>\n Don\u2019t add complexity to the system to solve hypothetical problems we might face in the future. Thinking ahead is great, but we shouldn\u2019t take on the burden of planning for eventualities that might not even happen. Let\u2019s not try to boil the ocean.<\/p>\n If we can make the system more open-ended without adding a ton of complexity to the system or adding lots of work, that’s great. But otherwise let\u2019s stay focused.<\/p>\n Can we make this simpler? Are we making too many assumptions about how this may need to be extended in future?<\/em><\/p>\n A successful system should be easy for users to understand when they interact with the product<\/a>. They will need to look at the UI (when we design it) and be able to roughly figure out what the parts of the system are.<\/p>\n For example, Slack clearly exposes itself, where it\u2019s possible to discern the underlying system by looking at it \u2013 there are channels, inside each channel there’s a stream of messages, each message can have a thread, etc.<\/p>\n Can the correct user mental model be expressed via the UI? Is the architecture of the system evident in the interface? Will users be able to figure this out without an explanation?<\/em><\/p>\n We will accept less efficient workflows and higher learning curves for one-time tasks if it means we get to make common tasks faster and simpler.<\/p>\n Assuming there’s a certain burden of functional complexity that the system must carry (Tesler\u2019s Law<\/a>), then think about where you can live with having more complexity. For example, it\u2019s more acceptable for it to be difficult for a manager to set up a team (which will happen once) than it is for a customer support rep to reassign a conversation (which will happen dozens of times a day).<\/p>\n Does this system require too much complexity up front? Are the least-used parts of the system over-exposed? Which users interact with each part of the system?<\/em><\/p>\n Don\u2019t get distracted by the implementation details. Remember, you\u2019re not designing the entire product when you\u2019re designing the system: you\u2019re designing the major interrelated parts of it. The system design needs to describe the shape of the solution. It doesn\u2019t need to answer every detailed design question.<\/p>\n Try to figure out what are the core things that the system can handle and what things you will be able to solve by designing the UI, or with clear workflows, or settings if needed.<\/p>\n Is this the right zoom level for this diagram? Do we really need to solve this part of the problem at the system level?<\/em><\/p>\n One of the dangers of moving upmarket (i.e. focusing on larger customers) is that you can alienate and create unnecessary complexity for your smaller customers. It’s too easy to design just for the needs of your most demanding users. The most elegant systems allow for simple use cases that then scale up as needed.<\/p>\n Intercom, for instance, is used by two-person startups who want a way to chat with their customers, and it is also used by huge teams with complex needs. You want a system that works simply for the little guy and scales up in complexity for the big guy.<\/p>\n What parts of the system are relevant to all users? What parts are niche?<\/em><\/p>\n All other things being equal, choose a system design that\u2019s most similar to what we currently have: less for us to build, less change for our users to adapt to.<\/p>\n System design is an ongoing process, rather than a once-off project. Your product will evolve, and anytime there is an expansion of what the product does, or a change in how the product operates, that’s where the adjacencies in the existing system becomes a factor to assess.<\/p>\n Adjacency is beneficial because it reduces change aversion or it reduces the barriers to understanding what the new version of your product is.<\/p>\n How hard is it to get to this from what we have today?<\/em><\/p>\n Like I said, these are not universally applicable principles, but hopefully they serve as an example to help you to assess and present your own system design work.<\/p>\n “System design is like creating a map of the complete product to act as a guide for the product teams that build it”<\/p><\/blockquote>\n Ultimately, system design is like creating a map of the complete product to act as a guide for the product teams that build it. The art of system design comes in judging the scale just right \u2013 providing enough information to give an accurate sense of the terrain and not so much that it risks becoming a 1:1 representation of the product, like the proverbial Borgesian map<\/a> that exactly covers the territory it is merely supposed to depict.<\/p>\n Get it right, and you\u2019ll have an invaluable document that will align your whole team around a shared understanding, and a powerful tool to help you navigate the complexities ahead.<\/p>\nCreating a system design<\/h2>\n
\n
![](\"https:\/\/intercom.com\/blog\/wp-content\/uploads\/2017\/07\/Artboard@2x.png\")
<\/p>\nAgreeing on a system design<\/h2>\n
\n
The purpose of principles<\/h2>\n
Principles of good system design<\/h2>\n
1. Keep it as simple as possible to address today\u2019s known problems<\/h3>\n
2. Ensure that it’s legible<\/h3>\n
3. Move complexity to infrequently used parts of the system<\/h3>\n
4. Don\u2019t take on non-core problems<\/h3>\n
5. Build it to scale from simple use case to complicated use case<\/h3>\n
6. Prioritize adjacency to the existing system<\/h3>\n
Chart your own course<\/h2>\n
\n