Atomic design

I recently read Atomic Design by Brad Frost. It was like a breath of fresh air – look! someone else is thinking the same, phew, I’m not alone. And not only that, someone else took the time to write a book and formalize everything. I sincerely believe that the book should be a mandatory read (it’s easy and takes only a few hours) for anyone involved in web projects – UX designers, visual designers, copywriters, front-end developers, back-end developers, testers, project managers, CTOs … anyone! Are you in the web business? Then read it.

Why do I liked it so much? Not only because it lays down some very good design principles and offers a common language to it, but mainly because it preaches a mindset change.

And now I come to the point where I want to tell you about my experience in this field. About six years ago, about the same time Brad started to apply the principles in his book, I was working for a major IT company. Mobile web was on the rise, but the company had no presence there. The desktop website was rendering on mobile just as a zoomed out version, making it unreadable and, of course, unusable. So I pitched the idea of building such a mobile web presence to my manager and I was in luck. I was tasked to create a proof-of-concept and the idea caught. One other manager was on board, so this way a new team was born. The proof-of-concept went live so that we can actually get some usage metrics.

Few months later it was another lucky development. Periodically the company was going through brand redesign. And this included the web presence too. Frankly speaking, my case was not exactly like the ones in Brad’s book. The company had structure and clear brand, including web, guidelines. They even had a governance team. But the problems were from another nature. First, to give you an idea of the magnitude, the company website consisted of hundreds of thousands of web pages and tens/hundreds of web applications. A lot of teams, even external agencies were working on these.

These were raising some very interesting challenges:

• Redesign was tedious, long and expensive. Many people for many months were working on this updating all these. Many times entire sections or applications did not benefit of the facelift, so the same website had different living designs.
• Because the web guidelines were quite extensive, the learning curve for creating web pages and applications was very steep. Thus high costs.
• The governance team was overwhelmed and most of the time busy with checking websites if they meet the standards they put in place. Due to this check, going live with a website was delayed, sometimes inexplicably for the developers and stakeholders
• Special needs of some development teams were almost never addressed so this was ending up in frustration and either going rogue or doing an ok-ish work with the sole purpose of just delivering something

Then I said to one of the UX designers:
– Cool! We have now the chance to do things the right way. We build not only a mobile presence, but a responsive web presence for all the devices and we will build it like a toolkit that can be used by everyone.
– Nah! Building such a toolkit will be very tedious. Not technically, but politically, to get the buy-in of all the high levels involved.
– Then let’s do it at a smaller scale to show them the advantages.
– Yup, here you may have something, let’s do this for mobile.

Then I connected directly with the UX team and asked them to create a list of semantic components. I explained them the concept of semantic design(CSS), its advantages and the fact that it doesn’t add up any work – it’s just a paradigm shift. They were very open (maybe I infected them with my enthusiasm, maybe they wanted to try something new) and they agreed. After just a few iterations we had an entire box full of semantic components. At that time I wasn’t aware of atoms – molecules – organisms, even though we organized them incrementally too. But I think this naming convention is much clearer.

I just want to make a small parenthesis here – the biggest challenge here was finding good names and most of the iterations were related to it. We even applied this when naming colors. I believe if you cannot find a good, SEMANTIC name to stand the test of style, then it would not stand the test of time. Test of style means that the name will make sense even if you completely change its style.

Initially, the components were presented in desktop style, but this was no issue. Creating a mobile style was fairly easy and fast. Only then we jumped to development – and it was a breeze this time. We even used the same names in CSS and the fact that we could reuse styles and components made all that planning effort and mindset change worthwhile.

We ended up with a toolkit in just a few weeks. And this was the output of a team of just 4-5 developers, not fully dedicated to this project. Now, other front-end developers and external agencies were able now to develop mobile pages. But how was this better or faster? First of all they got rid of all the web guidelines, a huge book to read and, if you wanted to be proficient, memorize. Now they had a few templates, a handful of components and just a few pages of documentation. If they stick to those templates and those components, their pages will be compliant. And here is how you get a quite fast approval from the standards team. Also this toolkit had embedded all the quirks of mobile development (back then were much more than nowadays 🙂 ). They were able to test their mobile pages on desktop browsers and have the confidence that they will work on mobile devices too. We, as the development team, took care of all the inconsistencies between different devices and browsers. This also gave them the opportunity to focus on their task at hand – develop mini websites fast and not care about a plethora of devices and associated quirks.

We also had toolkit guidelines, but ours were much simpler: do not introduce any new CSS classes or any new custom tags – just stick to our templates and components. Would you think it’s too restrictive? Not a chance. We also advertised to all our users that we will create ourselves any new components that they might need, if the current ones are not sufficient. And we got a lot of requests. But most of the time, those requests were practically a misunderstanding of the naming convention – they were looking for synonym component. We ended up adding synonyms to the documentation. And to make it official, we always responded with a link to that documentation. Sometimes, creating a new component wasn’t actually necessary, but just tweaking and customizing an existing one. This way the UI toolkit became more powerful and the documentation more comprehensive with each request coming from our users. And the number of requests was decreasing, freeing us the time to extend and improve the toolkit.

For static pages we had templates and components developed in …, actually the name of the tool is not important, but the fact that the users were not starting with a blank page. And the learning curve was not steep anymore. We even had JSP templates and custom tags available for web application development. We also created a transcoder from desktop pages to mobile optimized pages using the same toolkit.

And now I will tell you about two cases demonstrating the power of this approach, cases that stuck into my mind.

Less than a year later, by the time our toolkit became the one stop shop for mobile pages development, the time for a new company-wide redesign came. Most of the components stood the test of time and they just needed a facelift. Probably the most eye-catching facelift was to move from a black background to a white one. I’ll tell you later why I revealed this detail.

After UX and visual designers hand us over the new specs, for us was mostly a matter of rewriting a new CSS. Which we did in less than 3 weeks. When we were ready to go live, the desktop team was simply amazed:
– What? We haven’t finished yet the homepage. But I guess you did it only for a few pages, so it’s not actually ready to go live yet.
– No, we did for ALL the pages.
– Including the transcoded pages?
– Yup!
– For all the countries and languages?
– Of course.
– But you could not go live, we’re not ready.
Then the frustration was on our side and of another kind. But they agreed a compromise – to change the style just on the homepage and all the subsequent pages to remain on the old style. Most probably hoping that this would buy them another 2-3 weeks at least. Next day we came up with this version – in the end was just a matter of conditionally including one CSS or the other.
– But we also want to do some A/B testing and release the new design gradually.
– Ok, no problem, we already have support for this. We just need to know the target users for A and B.
Finally they let us go live with the new version in full. Few weeks later, they managed to release the homepage, many months later approximately 80% of the pages got the new design. A/B testing never happened.

Next day, after we went live with the new design, one of the front-end developers came to my desk and told me:
– I was developing yesterday a mobile page. In the evening I saved it and shutdown my computer. This morning I came, opened it and it turned from black to white. But I swear that I didn’t do anything.
I started laughing and I assured him that it’s fine, that this is the new redesign communicated by the standards team just few weeks back. I have to admit that I was happy about this level of upgrade. But we also sent a communication stating that front-end developers don’t have to do anything to get the new version. They just have to use the same tools, guidelines and toolkit. The replies were almost instantaneously: “We want this for desktop too!”

This is how we got the buy-in for creating a new RESPONSIVE toolkit. But that’s another story.

Update Jan 24th, 2018 (thanks to Meghan)

There are just a few, but very valuable things that I took from the “Atomic Design” book. First of all this book formalizes the entire process and gives pretty good names to everything.

I was using the term of semantic design, but atomic suggests the idea of modularity. On the other hand, semantic clearly states the separation between content and style. We were using the term of components, and even though we were describing them incrementally, I think atoms-molecules-organism makes a much clearer separation and gives a better idea of magnitude.

Another nice idea is the clear separation between UX comps and visual design. If you do this, it will be an additional check that your design system is both modular and semantic.