A product like Teamleader is constantly evolving to fulfil consumer needs, so the design needs to evolve too. Enter Ahoy, the Teamleader design system.

Getting started


It is important to have some kind of methodology but keep in mind that this is not a waterfall model. Product goals change over time so there will be a need to go back and forth between phases.

Establish a common language

As Stanley Wood from Spotify explains in this article, it is important to establish some keywords that are crucial to the goal of the product and can be used as a reference throughout the whole design process. It gives us a way to validate and review the designs with the whole team and open up a discussion.


Get started by reviewing the wireframes and look for an interesting piece of UI. From there, we experiment and explore in order to land on a couple of key screens designs. These are used as a deliverable to start the discussion with the team and iterate. Moodboards, research, quick sketches, and (if available) an existing style guide helps us to get the tone and voice of the design just right.


Before creating components that work, we need to see and test them in action. Therefore, it is important to design full-size key screens and extract components after sign-off. Keep in mind that this is not a one-way street. We will need to adjust/improve components to make them work in new contexts and adjust screens to fit the components in.


After sign-off, lower level components are added and refined by adding edge cases, different states and hierarchy. This is done by continuously checking them in various contexts to ensure the robustness of the components. From this point on, user stories and the wireframe are our guides to create the remaining components and screen deliverables.

By involving development straight from the start, the hierarchy between the design and implementation stays in sync. This enables incremental design reviews that focus more on the usability rather then fixing visual details further down the road.



Nested Symbols in Sketch give us the flexibility to build a stack of components that can be reused and combined. These components will be key for our designs to be consistent, scalable and flexible.


Abstract makes it easy to share and version the Sketch components. Other designers can make use of your patterns by importing them as linked libraries in their projects.

Syncing with Zeplin turns the designs in easy to read documentation for the development team. For us, it works best when we provide two separate projects: one for the full screens and one for the components. Tags and divisions are then used to tie the right components and screens to user stories and sprints.


When building components, it is important to think about a naming convention from the start. This will not only make it much easier to pick the right symbol in Sketch but also help development to search when exporting the whole thing to zeplin. Some rules we follow:

  • Use ‘/’ to create levels
  • Use ‘+’ to tell what the symbol contains
  • Prefix symbol instances with emoji to get a visual anchor in the properties pane


There are many Sketch plug-ins available to speed up the workflow, here is a selection of our most used ones:

Plug-ins are great but for the lower-level components, we try to not depend on them too much. You don't want to update your entire library whenever a plug-in stops working.


Primitives are single, non-divisible elements that are the foundation of our visual style. They are combined into the lower-level UI blocks. See Tim van Damme's practical guide on organizing components.


Brand and UI Colors are added as symbols. These can be used to color icons or other elements in a flexible way. The primary colors relate to the brand and are used for typography, backgrounds and borders. The secondary colors add extra meaning to a component. E.g: Error, Success, Warning.



Currently, text styles are hard to maintain in Sketch. Every time a different color or alignment is used, a new text style is created. This results in a massive and cluttered list. It is better to keep a list of used typography (one color and left-aligned) in your symbols page and use that as a reference.

Level One


These lowest level symbols can be nested in higher level components.


Icons support various actions and metaphors all across the product. They are designed to work in small sizes, play nice with the typographical context and to look consistent when used next to each other. See Guidelines for creating UI icons.


It is best practice to prefix icon names with the dp-size. This makes it easier to select the right icon in the Sketch symbol library. It also tells development the appropriate size for implementation. E.g: 24x24_metaphor, 18x18_metaphor,…


Instead of creating symbols for each individual color, it is better to stick to one single expanded shape that acts like a mask for the above mentioned color symbols. See Tint icons using nested symbols.


Tinting of the icons happens in development so it is possible to serve the icons in only one color. To do this, we’ll need to create a separate file that lists all the expanded shapes. From there, the assets are uploaded to a git repo where development can pull them from.


Depending on the type of asset, the original file can be kept in Sketch or they can be grouped in a central git repo as described above. Evaluate with the development team to see which one works best.


  • Visuals/Logos
  • Visuals/App icon
  • Visuals/Spot Illustrations
  • Visuals/Editorial Illustrations
  • Visuals/Avatars
  • ...

For more information on classification of visual assets, read this great article from Meg Robichaud or take a look at my slide-deck on Scaling Visual Design (.pdf 15mb)

Level Two

Lower-level blocks

Build with the primitives, these are the smallest components. They are flexible, reusable and fit multiple use cases.

Lower-level blocks are tagged in zeplin for the development team. From there, they are implemented as reusable snippets of code and listed as an overview on device. Focus on the visual design details in this phase will prevent back and forth further down the road so there is more time left to deal with larger scale challenges.


  • Actions/Buttons
  • Actions/Form Elements
  • Messaging/Status
  • Messaging/Banners
  • ...

Level three

Mid-level blocks

The more advanced symbols. These form a feature or a distinct section in the interface.

Level four


Mid-level blocks stitched together where the design makes sense for the stakeholders, testers and users. These will be used to produce screens with actual content.


Instances of templates that have real, variable content. At this point, we usually detach the instances from the symbols so it is possible to input variable content without creating redundant symbols.


  • Test the design with the supported languages. E.g, words in German or French are often longer that the English version
  • Truncated or multiple lines on overflowing content?
  • How do empty states look?
  • Bad photo quality vs. good photo quality?
  • Which user generated content types (lists, links, paragraphs,...) are possible in patterns?


Feedback can sometimes be tricky to translate in effective design solutions. Often, this is because the feedback is limited to a proposed solution.

We all get the question sometimes to make a button ‘pop’ more by increasing the size or to use an off-brand color. What a stakeholder likely means is: “Can we do something to increase the click-through rate of this piece of UI” and proposes a bigger button as a solution. By showing the structure of the system, we can show the impact on a bigger scale and shift the discussion to the problem (click-through rate) rather then the solution (a bigger button).


The design system is not meant to be a 'pretty picture' that is disconnected from reality. List all the patterns, including the older, deprecated patterns that are still in use. This will surface low hanging fruit and encourage the team to refactor those parts.

With larger issues or changes, it is useful to have an implementation strategy. One of the things we did at Yelp is whenever a certain feature is touched, the context of that feature needs to be reviewed and updated as well.


The overview of all the elements and how they interact shows how a design change can affect the whole product in a positive or negative way. It gives a clear view on weighing out the pros and cons in terms of effort to make the change as well. Yelp summarizes this in the following ruleset:

  1. Use the pre-established patterns
  2. No, really, please use the pre-established patterns.
  3. If the pre-established patterns do not solve your design problem, you have two options:

Deviation of patterns is allowed in a growth track with a/b testing. In this phase, the rigid design system will stand in the way of experimentation. Just make sure to follow up with ‘a’ or ‘b’ when the experiment is successful.