Working towards a MightyNet UI Design System
As the MightyNet web application grows with more features to support Mighty Action Heroes, so does the need to have a consistent interface design and a modular component-based architecture. As part of this process, I wanted to share some thoughts on what a design system is, why you might need one, and why we felt like now was a good time to put these practices into motion. I’ll also briefly dive into some of the challenges we encounter when adapting an existing design language into our own. It’s my hope that this will help you see the importance of having a cohesive interface, how it creates a consistent, predictable user experience and the importance it has to front end development as well.
A design system is essentially a set of visual rules and guidelines that determine how your application looks and feels. It’s similar to a brand guide, in that it’s a document that lays out the dos and don’ts of how your application should look and feel. I personally am also a fan of Atomic Design principles, which structure the design process as creating individual components — the atoms of your design guide — that can then be used to create the more complex components, layouts, and eventually pages; the molecules, cells, organs and organ systems, if you will.
Thinking about it this way is also really helpful from a development perspective. In developing React applications and web applications in general, a component-driven architecture is de-rigour — it maximises DRY-ness*, creates a single source of truth on how a component is implemented so that the process is relatively painless if it ever needs to be changed or upgraded, and it creates an abstraction so that you as an engineer aren’t having to worry about the individual components when building a page layout or application functionality.
* DRY — or Don’t Repeat Yourself is one of the fundamental tenets of programming. Usually, repeated code means that you either haven’t thought about what your application is doing, and thus haven’t structured it properly, or your team isn’t communicating on proper project structure. Despite best efforts, this stuff happens: designing a product is an imperfect process. It requires balancing uncertainty and flexibility with timelines and hard decisions on prioritisation.
Putting it into practice
Design systems are a lot of work, which is usually why it doesn’t always make sense for small applications, or one-off projects or landing pages. However, if you know you’re going to be working on a large application long-term, the earlier you can put a design system into practice the better. A design system can be adaptive, much like a code base. Design systems can have the equivalent of bugs, where rules conflict with each other, or areas where a design is breaking the rules of its system. Having the development team work closely with the UI/UX team helps resolve a lot of these issues, since they usually surface during implementation if using components built from that system.
Dealing with over-componentisation: Early on into the implementation process, it may seem like the design system is getting in the way more than it’s helping. It can feel like the codebase is over-componentised and we’re creating more exceptions than rules early on in the process. There’s no universal answer for this, and at Mighty Bear we vacillated between how best to structure components for a while — creating them, uncreating them when they got too messy and then creating them again. This is normal, and I think long-term it’s important to stick with it, especially if you know your application is going to get bigger and more complex. It’s also helpful to have your inconsistency laid bare before you have it in code, so that you can revisit whether your decisions make sense.
Styling using Tailwind: In previous projects I have worked on, I have used various CSS strategies and approaches. Using a Bootstrap, Foundation, or a Semantic UI is a quick and easy way to get a consistent and clean look for an application. It’s great for developers who care more about function than form, and just want something that works. I think of it a co-opting a design system. For more bespoke projects, I have also written custom CSS or SASS code or gone for a modular approach. There are benefits to this: rolling your own styles does make it fully customisable, but usually come with their own hassles like auto-prefixing, browser support, poly-fills. At Mighty Bear we’re using Tailwind, which does mean we don’t have to deal with CSS directly for the most part, but is closer to rolling your own than it is to a CSS framework like Bootstrap. You’re essentially free to do as you please.
### Putting it into practice
Design systems are a lot of work, which is usually why it doesn’t always make sense for small applications, or one-off projects or landing pages. However, if you know you’re going to be working on a large application long-term, the earlier you can put a design system into practice the better. A design system can be adaptive, much like a code base. Design systems can have the equivalent of bugs, where rules conflict with each other, or areas where a design is breaking the rules of its system. Having the development team work closely with the UI/UX team helps resolve a lot of these issues, since they usually surface during implementation if using components built from that system.
**Dealing with over-componentisation:**
Early on into the implementation process, it may seem like the design system is getting in the way more than it’s helping. It can feel like the codebase is over-componentised and we’re creating more exceptions than rules early on in the process. There’s no universal answer for this, and at Mighty Bear we vacillated between how best to structure components for a while - creating them, uncreating them when they got too messy and then creating them again. This is normal, and I think long-term it’s important to stick with it, especially if you know your application is going to get bigger and more complex. It’s also helpful to have your inconsistency laid bare before you have it in code, so that you can revisit whether your decisions make sense.
**Styling using Tailwind:**
In previous projects I have worked on, I have used various CSS strategies and approaches. Using a Bootstrap, Foundation, or a Semantic UI is a quick and easy way to get a consistent and clean look for an application. It’s great for developers who care more about function than form, and just want something that works. I think of it a co-opting a design system. For more bespoke projects, I have also written custom CSS or SASS code or gone for a modular approach. There are benefits to this: rolling your own styles does make it fully customisable, but usually come with their own hassles like auto-prefixing, browser support, poly-fills. At Mighty Bear we’re using Tailwind, which does mean we don’t have to deal with CSS directly for the most part, but is closer to rolling your own than it is to a CSS framework like Bootstrap. You’re essentially free to do as you please.
Design System Considerations
The MightyNet web app takes a lot of visual design cues from old (I felt pain writing that word) Windows 95–98 interfaces and 80s-style synth-wave colors, harkening back to the heyday of cheesy action movies. However, the design system cannot just be adapted wholesale. Considerations need to be made for the fact that it’s not the 90s anymore, starting with:
- Responsiveness: Windows 95 had to contend with one CRT monitor in a 4:3 aspect ratio. Modern websites have to look good at everything from an iPhone SE to an ultra-wide 8K display and everything in between. You cannot design for one screen anymore. The design must be adaptive.
- Touch sensitivity and gesture interfaces: With a desktop interface, you are limited to hovering, clicking, and scrolling. However, hovering is not something that works on touch interfaces, which means it’s important to accommodate a touch-sensitive way to present hovered information. Accounting for touch sensitivity also means the touchable target also needs to be large enough to be pressed on touch devices.
- Accessibility: A lot more effort has been put into making the web a more accessible place for people with impairments and disabilities like colour-blindness, partial or complete visual impairment. These conditions mean there are certain standards that must be adhered to, even if they don’t necessarily have an analogous representation in the design system
- Convention: The modern web has certain design conventions that make sense to adhere to — a navigation bar at the top of the page, hyperlinks, non-overlapping content. This means a balance needs to be struck between adapting the mechanics of an interface wholesale (multiple overlapping windows, window menus, context menus, taskbars and start menus) and sticking with conventional web interface design. In this case, the guiding principle to remember is that style shouldn’t get in the way of functionality. The user shouldn’t be confused about how to navigate your app — you want to keep the cognitive load of navigation to a minimum so that they can focus on what they want/need to use your app for.
- Limitations vs stylistic choices: The old Windows OSes were doing the best they could with the technology they had. For example, they used font hinting in order to improve legibility at smaller sizes, and that gave their typography a certain look and feel. When implementing something that feels like that, it’s also important to recognise how far we want to go in emulating the problems that it had to deal with. In our case we choose to have a modern font that overcomes a lot of the technical limitations while still visually throwing back to that aesthetic.
Design at the end of the day, is visual problem solving. It’s important to have logical, consistent approaches to problems that follow a simple rule-set. A design system is the product of that process. A logical, well-thought out system is a real asset for front-end development because as developers, we are codifying those design rules into, well… code. The cleaner, more elegant and well thought out the design, the cleaner your codebase will be (hopefully!). In the following months I hope to be able to share more information about how we’re tackling these problems, and our progress with the visual language of the MightyNet. Until then, I hope this has helped clarify why having a system might be a valuable investment for your applications.
Working towards a MightyNet UI Design System was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
