All stories

Modularity in Web Design

How we deal with it and built our own workflow for daily business

12 min read simon.jpg by  Simon Kratz

Modularity in Web Design.jpg

It’s safe to say that modularity, a component based workflow or atomic design thinking isn’t something new for you if you’re designing for the web nowadays.

But did you ever find yourself wondering about how to implement it into your daily business with real clients, a ton of hassle, constraints and concerns?

No worries, i can assure you: it’s not rocket science and not that far away from your „comfort zone“ — you will just need to reconsider your current habits and accomplish a new level of designing for the challenges today. Just give it a try – you’ll never regret it. Trust me.

What the hell is atomic design or ? not yet the hundredth description about that shit

Hint: Skip this part if you don’t want to read the 1004th description of what Atomic Design is. In a nutshell: Atomic Design is a design approach for creating todays web experiences, which came up in the time when the web got responsive. Digital devices got more diverse and web-designers went panic cuz their pixel-perfect designs had to go more flexible. It means creating a design system of pieces that can come together to create elements and templates we can reuse over and over again  –  it’s about designing the core of the system. If you’re curious, read more about the entire process here  – shout out to the incredible @brad_frost who pioneered in that field.


Top 3 reasons why we’re designing modular


The modular design approach provides us flexibility we need for working with the unknown needs of the future.

Todays digital world is rapidly changing — the digital landscape has changed and totally new requirements are popping up every day. As designers, we are here for creating new solutions and make users experiences as much comfortable, accessible and delightful as we can. Exciting, isn’t it? But if we want to keep on track we can’t think in static layouts and have to get rid of pixel-perfect layout thinking. If not, you’re going to kill yourself. It’s reasonable to say that we can’t stop the digital revolution — but we’re able to design it.

New components and modules which are responsively designed, ensure a consistent user experience over a large amount of todays devices.

Nobody knows where the web journey goes and how our digital future will look like. But we can be prepared for that and modular designed web experiences are certainly an important foundation.

Design Modular To Build Modular — Style Guide-Driven Development and Dev-Thinking

Our devs are saddled up to write clean and maintainable code that can easily be handed off and taken over. And this makes total sense for us as designers as well, because we’re not the last link in the chain. Our output should be totally understandable by the developers in order to build the solution we all want. And how should that work if we’re not organised and well structured in our design process?

Therefore we’re working with living styleguides. Our developers are coding piece by piece, starting with general stuff like colors and base typography until components to building full pages. Ultimately they roll out an entire living styleguide for each project. Why „living“? Because it’s constantly growing — the things they develop and that have been already worked out are going into an online application which collects all pieces and the entire system of components. It’s more or less our style inventory and documentation in one place. It provides access for the designers and the clients as well and gives us the opportunity to (re-) check the style and behaviour of design tiles and iterate if needed. So it’s just reasonable to structure our design process in a similar way to anticipate a bunch of work that has to be done anyway.

Additionally from a technical perspective, the open source CMS Drupal8 is our agency’s draft horse. Among plenty of features Drupal is pretty comfortable and flexible in arranging your contents. And that’s a huge benefit for the user. Imagine how convenient it is for a client if he’s able to arrange and organize his page components, sections and modules as he wants. Sounds pretty cool — their pages would never look the same… but heads up! This makes it much more ambitious for you as a designer to be prepared for nasty surprises. Defining a bunch of guidances and (design) patterns for components behaviors is very important at this point.

Modular design is consistent and consistency saves time and money

Good design is consistent and consistency makes your design great. I’m not saying that components we reuse over and over again should look totally the same to achieve consistency. No. Nobody wants a visually unappealing website which always has the same patterns. You have to find the right balance between a meaningful and stringent use of recurring elements like typography and colors to maintain consistency and the exploration of unconventional, new ways to tell your storys. Don’t forget not reducing consistency just on visual patterns — there’s another side to guiding the user through-out your (web-) experience like the consistent use of behavior patterns of your modules.

To summarise you can say that modularity in web design boosts your entire process, no matter if in design or development.

For example you’re not designing web page no. 32 in the third language. No. You’re designing modular, repeatable elements and patterns and define several rules about how they should behave in several combinations. The rest will happen in the browser — absolute rapidly and efficiently.

How we’re designing (in) our own modular way

Hint: We’ll be only scratching the surface of introducing our „workflow“, but the following lines will definitely give you a brief overview, how we’re dealing with daily demands. There are, of course, a ton of things you have to consider for each client/project beside the actual „process“.

Discovery phase

Mostly we’re starting a new web-project with the discovery phase. Its mainly goal is to getting to know each other (client and agency), trying to understand where the journey should go and how we can get on the same page to evolve epic solutions together. Usually the largest part here are strategic tasks like evaluation, screening, analysis, research, workshops and more…

Therefore we’re designing a couple of „Visual Design Visions“/ Look-and-Feel-Pages — yes, you read correctly — we’re designing pages right here. But that are not the „final“ pages for the end result. It’s rather a long tube with several components/modules which are designed completely detached from real content and final storytelling. It’s just to give an exploration and feeling of how could a final page or the final experience (in terms of animated prototypes) could look and feel alike — it’s more or less to literally discover the whole visual thing.

To be honest, we determined in former projects that it won’t work out for us to create the entire design system including „style tiles“ approach together with the client from ground up. It burned our budget most of the time completely down and in the end nobody had an idea of the big picture.

That’s why we came up with the idea to present design visions in the first step to roughly visualize in which direction that long journey can go. After getting that big picture on both sides we break these visions down into individual pieces. After iterating these pieces including first feedback, they provide a good foundation for building the entire design system including dozens of components which are designed on basis of real requirements and specifications.

Wireframing & Specifications

Now it’s getting deep into the entire concept & specs thing. We gather the overall needs and creating several wireframes/mockups for whole templates/pages regarding to contents and functional features, not in terms of visual design. This helps the client to get the „big picture“ of the latter pages and how the components and elements come together.

Deriving from that we’re able to define an entire specifications catalog. So, this document is the project bible which collects the entire (technically and content-related) requirements of the project. That specs doc gives also the client a detailed overview, what he has to deliver in terms of contents and what he gets in the end result from a functional point of view. While the specs doc is constantly evolving, backend-development and the whole design process started already. Regarding to the design part we’re setting up the entire design system of pieces on base of the specification-catalog and the already existing „vision“-pieces.


Sketch is a tool to solve the design challenges of the future. It’s entirely focused on user interface design, incredibly fast and boosts your workflow on a complete new level — especially when you design things modular.

Sketch supercharged our digital design workflow and in the meanwhile i can’t believe that there was a time where we designed for the web without Sketch — and that’s not hyperbole.

It’s perfect to create design systems and visual patterns beacause its heavy focus on the entire organization of multiple pages, artboards, shared styles and symbols. Latter are the major key for ultimate time saving and the heart of Sketch. Why major key? I mean, repeating elements is something very common: nav, footer, buttons, teaser,… all sorts of things. But you don’t want to change the style of an Call-to-Action-Button in 48 different boards or drafts. Now you have Symbols. And they will make the whole stuff for you — automatically. You can copy and paste Symbols throughout your designs. Change one, and all of them will change. Yes, quite similar to Smart-Objects in Photoshop. But totally different. Symbols give you the flexibility to nesting and overriding elements in a rad way. And that makes the whole thing so efficiency. Convince yourself. It’s a blast!

These days web projects are permanently growing and evolving and with creating design systems you build definitely a great foundation to be prepared for that.

But with new requirements in daily changeable workflows your tools should cover new needs as well. And that’s what make Sketch absolutely indispensable. Sketch is open for everyone and so there’s a huge community developing tons of plugins. It’s safe to say, that there is a plugin for everything you need to optimize your process in Sketch. Everything is served for leveling up your workflow! What are you waiting for? Let’s have fun with this!

(Animated) Prototyping — bring your epic ideas to live

Yes, your screen-designs are beautiful. Really. But that’s only half the job. Users expect easy accessible, attractive experiences that are fun and sexy while consuming the right contents. And that’s not reachable with your static layouts in Sketch.

Todays web experiences come with strong (micro-) animations and transitions that make sites in subtle way more appealing and alive and let the user explore storytelling and products intuitively.

That’s one of many reasons why we prototype our ideas in an early stage. First you can explain your thoughts in a easy and fast way — an animated prototype says much more than static screens. They provide the general idea of what it should look and especially feel like along with functionality in the same place. Everyone can get on the same page. Not only the client but rather the entire team to discuss things like functionality and how to solve problems.

It’s totally not important to have an awesome looking prototype in the first step — your first prototypes can be for the trash after testing it. What really matters is to have focus on what’s important for the user on his customer journey. Iterative prototyping and real feedback is a total boost for improving user experience.

At the end it’s also a pretty nice capability to sell your concepts — clients are always excited and easier to convince if they can explore base functionalities of their new product on real devices in a pitch or early stage phase.

Collaboration matters

To keep it short: We use a few tools to communicate between all disciplines within our project-teams and to get our stuff handed-off. Slack, Zeplin, and Trello are integral parts of our daily workflow and have a huge impact on involvement of all members. To cover the lack between design and development there are dozens of things that should be considered and could help you.

  • come early together to get everyone on the same page
  • meet for daily stand-ups to know everyones current state
  • discuss early experience ideas directly with a dev to ensure the practicability in terms of time and budget
  • set priorities
  • don’t design things that won’t get build
  • use same names/titles for components to avoid lacks in communication — make sure that everyone in the team speaks about the same things
  • be organized — make sure to name every artboard in sketch as well (there is nothing more bad as a huge mess if someone needs to edit your designs and can’t get through)
  • specify all requirements before you start designing (e.g. each functionality of each module or component)
  • show your work early and often in your team
  • ideate, prototype, test, (fail), repeat

Wrapping up

Like mentioned above you can read the hundredth article about the principles of atomic design or component based web design — but you won’t bring the ball forward if you don’t practice, practice and practice by your own. The truth lies in trying here.

Every project is different, so you need to find out for yourself what choice suits you the best. This article might help you making the right decision. The workflow described above helped us incredibly often to achieve our goals in a fast and efficient way with both small and large digital projects. I’d love to hear your thoughts and how you’re dealing with that daily design and process struggle. What’s your process like? How are you improvements regarding to your process?


You’re still reading? So, I hope you enjoyed this article — if you’re curious check out the following master pieces that will help you to bring your stuff on!

Alright! That’s all. Thanks for reading! Let’s talk soon!

About the author

This is Simon

Jump or you'll never fly!