How to Create Future-Proof Design System and Make it Easily Accessible for the Product Team
Nethone’s Case Study
I’m lucky enough to be responsible for the design of an awesome product. It’s based on machine learning technology — or AI as some people prefer to call it. Even though those buzzwords seem to be misused a lot lately, there’s truly cutting-edge technology behind Nethone. Trust me, we are about to become the real space police and protect access to satellites!
Being tech-driven means that the main focus is put on perfecting the technology itself. So, eye-candy design seems rather like nice-to-have than something absolutely necessary from the day one.
And that’s absolutely understandable at the beginning of product’s lifecycle when you need to keep the in-house team as narrow as possible. For that reason, the very first UI components and graphics were made by either outside designers or even developers. And surprisingly, they made decent enough job fabricating those initial Nethone’s visuals. But then came a time when I’ve got on stage to take full-time care of the product’s user experience and interface design.
Chapter 1 — Audit
First off, I decided to get to know the product the best I could. So, I had clicked through every screen of every use case imaginable taking notes. The aim was to write down every, even the smallest thing that needed to be taken care of — in terms of either information architecture, usability, look or even the narration.
Why is it specifically here? Is there any particular reason behind this flow? What is this notification trying to tell? Why the hell they used this shade of red?!
I’ve conducted a few effortful sessions of clicking and asking questions of that nature. That left me with a lot of insight and an ample list of things to improve or add.
At that point, I wasn’t ready to proceed with redesigning the product by any stretch of the imagination. The list was very long, uncategorized and kinda messy. It contained an insanely broad range of points — from major functionality redesign proposals to margin being 2 pixels off somewhere. It definitely needed some clean-up! So I started dividing it into separate todo lists — each for every area, like User Experience, User Interface, Copywriting and so on. After that, I’ve performed a couple of extra click through sessions. Yet this time more in-depth and focused on one mentioned area at a time.
At that point, I was one last step form accomplishing this great task of the initial audit.
Product development isn’t a one man’s effort. The tasks had to be confronted with the reality and prioritized.
Together with Nethone’s CPO and great people of the product-end team we started brainstorming. The most urgent needs as well as possible technical and business challenges which needed to be discussed. That resulted in final (at that point), reality-bound set of todo lists.
I was all set to start putting those into practice!
Chapter 2 — Establishing a Visual Language
Branding Materials
Having roadmap done, I was ready to proceed with an actual craftsmanship and creation. Before diving deeper into nuances I started organizing basic branding and branding-related components.
Establishing a so-called Style Guide sets a solid foundation for further UI/UX work. No doubt about it!
I started up with the obvious — collecting all branding materials in one, neat package. It turned out that all of those were in existence already. One thing left to do was to tweak them a bit and convert to the most common vector and raster file formats. Then I added an optional all-in-one .zip archive for convenient downloading or sending out to external partners and… that was it! So, nothing overly exciting about that bit, to be honest.
Color Palette
After that, I’ve switched over to establishing color set. Or, rather I should say — The Nethone’s Official Color Palette. Some of the primary shades were already imposed by the branding itself. But every interface needs more than those, of course. Especially one as complex as a dashboard-based web app.
I took a closer look at the most data-heavy component at that time then. Essentially, it was displaying all connections between various datapoints, indicating what they have in common. Pretty complicated, isn’t it?
But the complexity of that component helped me to create a neat set of secondary colors that would exactly suit current needs.
I’ve eventually ended up with 7 secondary shades. Those seemed like enough for that point. But I wasn’t happy with just ‘enough’ — future-proof was what I was aiming for! So, I’ve prepared simple instruction on how to change the current color by placing a dark or bright overlay on top of it.
One last thing I’ve closed The Nethone’s Official Color Palette with was adding distinctive shades for error and success messages.
Text Styles, Spacing Classes etc.
When it comes to the font, I’ve encountered a kinda strange problem while inspecting current styles and sizing. Typeface we were using — known and loved Montserrat — seemed to be rendered at least one weight thicker than defined.
So, what was set as ‘light’ in CSS looked like ‘regular’ or ‘medium’ on screen. After all, it turned out that some suspicious font version of unknown origin were used.
So, after updating to Google Fonts’ newest version the problem was essentially gone.
Despite this initial little hiccup, establishing text styles was rather straightforward. I’ve tweaked some sizes of preexisting styles a little bit for better proportions. There were some inconsistencies in using weights as well. In some places ‘medium’ (or ‘500’ if you prefer) was used alternatively with ‘semibold’ (600) for the same bolder subtitles and so on. Sorting those out has resulted in much shorter and cleaner list of text classes. As a finishing touch, I’ve expanded the list with extra large and extra small styles. Plus, I’ve recalculated the sizing to be provided in both pixels and scalable ‘ems’.
Establishing a neat set of spacings was a matter of checking the existing ones… and adding two extreme ones for extra flexibility. So, if I was to give some universal advice to anyone working on a design system I would say:
Consider adding your ‘extra larges’ and ‘extra smalls’ for flexibility in less common use scenarios.
…but not necessarily at the very beginning. More on that later.
Chapter 3 — Creating UI Component Library
Basic UI elements
After the initial research was completed, I’ve started to work on basic UI components. I cannot overemphasize how fundamental they are to the overall look and feel of the interface. Elements such as buttons, dropdowns etc. will probably be present on every single screen of the entire project! They need to be highly polished and well planned, then.
So I’ve carefully gone through every of those ‘universal’ components. There was no room for any rush in perfecting their shape, sizing and color. As a result, I’ve got a neat set of elements. They looked good either on their own as well as placed in a wider context of the whole UI. Last, but definitely, not least thing to design there was motion. I felt we needed something more sophisticated than typical idle — hover — active cycle. As for the buttons I decided to go with a circle-based animation. It grows to fill the whole element with ‘active’ color, then revolves back to initial state.
That gave the interaction organic feel and a sparkle of that infamous ‘wow factor’ I believe.
When it comes to how the specs of basic UI elements will be presented I’ve decided to go the old-school way. Of course, we use tools like Zeplin (that has replaced InVision in our workflow recently) on a daily basis. But to have all the dimensions, clear and as accessible as possible, I’ve prepared specsheets as shown below. The nice additional thing was that we kept it consistent with the branding guidelines prepared before.
Adding some context
As mentioned earlier, basic components don’t function on their own. They are just parts of the interface as a whole. So, a key to establishing seamless design system is going a step farther… by placing those in context.
That’s why here at Nethone not only do things like buttons or dropdowns have their own specs — but whole functionalities do as well.
Of course, making a detailed specsheets for each and every screen would be a definite overkill. Instead, major functionalities are described by the set of final screens/designs. There’s always more than one state for each of those — i.e. admin and user views differ, there are empty and filled states for tables etc. So, to make that as clear as possible the screens are grouped, labeled and have additional info. In general, we show and describe all mechanics for certain functionality to work there.
It serves as a kind of ‘source of truth’ for developers in terms of looks and mechanics. But, as mentioned before, for pixel-perfect specifications we use Zeplin.
Chapter 4 — Sharing the Specs
Then came a time to figure out how to share the specs. We needed a convenient way to write and update those to be sure that everyone, who’s interested is looking at the newest version.
You probably have just thought Google Docs, haven’t you? We had been considering it too.
But since our specs are mainly graphics and text combined we would need to make either Docs text documents (which is lame) or Sheets that link to documents within a Drive folder (which is inconvenient). Neither of those solutions seemed optimal to say the least. So, together with our great front-end developers we came up with something sophisticated, yet paradoxically simple and useful.
- First of all, documentation will be written in Markdown. It’s a plain text formatting syntax, meant mainly to be converted to HTML. So it basically consists of text classes similar to <h1>, <h2>, <p> and so on. Plus, has some additional capabilities of creating simple tables, adding images etc. It’s been out there for more than a decade now and since became pretty much a standard for writing all sorts of readmes and documentation. We decided to use it mainly because of its flexibility. That would allow us to meet virtually any possible need for our documentation to be converted to. So if one day someone would come up with the idea of making, say, paperback book out of it — boom, no problem!
- Markdown documents will be then pushed to dedicated GitLab repository. That gives us extra version control feature, provides changelogs if necessary… and allows for a little further magic. If you are new to using git services —don’t be intimidated with it. It’s really simple, even for non-programmers. I write specs in Atom text editor which has built-in Git integration. So, when done writing you are only two or three clicks from putting files into the repository. But you can always decide to go the traditional way of typing in ‘git pushes’ into console… and feel like a legit coder for a moment.
- With every push, a CI script will engage within GitLab. It automatically converts markdown files into a simple website. The site is based upon MkDocs — a tool meant to conveniently display Markdown-written documentation. It is beautifully straightforward and easily configurable with either preexisting or custom themes.
And that’s how Nethone Look Book came to life! One last issue was privacy. Of course, we wanted it to be accessible by the team members, but publicly visible website was a bit too much. So the site has been additionally set up to appear only for those who connect from within a company’s network.
That way we have got ourselves all needed specs in one, easily-accessible place. But it turned out that the Look Book not only benefits us —the front-end team. It became a go-to place for PR people, Customer Engineers and many more where they know they’ll find up-to-date branding materials and guidelines.
So, job quite decently done I guess.
Chapter 5 — The Future
But it doesn’t end at this point. Taking care of such a complex product as Nethone is a neverending challenge. The main part of it is keeping all of new the screens and features inline with the guidelines. It takes some taste and common sense to decide at what point it’s necessary to expand those with some new elements.
On the other hand, there’s nothing bad in iterating and changing the specs according to changing needs… or just because you forgot about something beforehand. As I mentioned earlier, it’s good to cover all of those ‘extra larges’ and ‘extra smalls’. It gives you flexibility but don’t try to force it. Stumbling upon real use case and updating the specs based upon it may give you much more refined results.
So find your balance, design for specific needs and don’t trust design system tutorials!
About Nethone
Nethone is the global leader in A.I.-powered KYU (Know Your Users) solutions that help enterprises from all around the world convert threats and challenges into well-informed, profitable decisions. Founded in 2016 by experienced data scientists, security experts, and business executives, Nethone is one of the fastest-growing FDP companies in Central Europe.
If you enjoyed this post, please hit the clap button below 👏👏👏
