Our agile approach to developing design systems
And why this minimizes the risk of failure
As a client, have you ever been afraid that an agency might not deliver what you had in mind? As an agency, have you ever feared that the client might find your new design too bold? Neither of these fears is unfounded – as a matter of fact, one time, the result of this type of disagreement ended up changing the way we run our company for the better. After three months of hard work developing a new visual brand image for sipgate, they rejected our preliminary draft. We, however, managed to turn this supposed failure into a resounding success after reflecting on what went wrong.
Before we begin, it is important to mention that sipgate had already carried out a great deal of strategy work with high-ranking experts in the run-up to the project. So the initial briefing we based our work from was largely based on results developed by external service providers instead of direct dialogue with the sipgate team. Upon presenting the preliminary draft to sipgate, it quickly became clear that although we had worked along the guidelines outlined in the briefing, and that all of the functional requirements for the design system were met; our preliminary draft didn’t sit right for the sipgate team. What happened? In short, we interpreted certain nuances of the brand’s personality in a completely different way than they were meant by the sipgate team. Brand attributes such as „stylish and geeky“, which were agreed upon and defined in advance, offer plenty of room for interpretation and ultimately mean something different for everyone. Subtle distinctions such as these ended up being the main problem with our work.
This challenge taught us a very valuable lesson: a deep understanding of your client’s brand personality is essential in every branding process and should never be outsourced. No matter how much you communicate with your clients, it is nearly impossible to develop a common understanding of what they want for their brand without creating one together, through active dialogue. Since then, we have consistently insisted on holding at least one joint workshop with all stakeholders for the kick-off of each project – regardless of whether we implement a classic or agile work process. In the case of the sipgate project, we added an additional step to our regular communication process by implementing agile collaboration principles that their employees were used to, to our design process.
The changeover to an agile process loosely based on Scrum principles was a challenge, as it is a framework that wasn’t explicitly designed to account for two teams working in two different locations. The first step was to define the length of design sprint periods for our collaboration with sipgate. We settled on two-week sprints beginning with a kick-off meeting for »Backlog Refinement« and »Sprint Planning«, where we defined the expectations and goals of each sprint. We then created our own internal g31 »Sprint Backlog« and prioritized our tasks to construct a usable design system product at the end of the two weeks. This is known in the Scrum community as an “increment”. To make the best use of Scrum principles, it is important to ensure that the tasks are small enough to complete within the given timeframe. For example, the backlog shouldn’t list »corporate design« as a task, but instead, list a subtask such as »typography system« to be completed during the sprint. If this subtask is too large for the defined time period, it should be subdivided until it can be solved in the time allotted. To stay with the previous example, useful subtasks could be, »Font selection«, »Font sizes«, or »Spacing«, etc. Upon completing these »increments«, we reviewed the results together with sipgate and checked whether they could be directly incorporated into the design system or if we would have to plan another sprint to make it fit.
All told, our processes during the sprint were not that different from the way we had structured design processes before. According to Scrum principles, we should exchange ideas once a day in a 15-minute daily Scrum meeting. While this type of scheduled interaction may be something noteworthy in software development – which is perhaps why we imagine software developers to be introverts perpetually stuck behind a keyboard and pale due to lack of sunlight – it would simply be impractical for us not to discuss the status of the project or exchange ideas throughout the day. Whether it’s a chat over coffee in the morning, or at the end of the day, idea exchange and updates had already been occurring naturally in our design process. Another habit we had long since cultivated helped us to avoid unnecessary work during Sprint Reviews – pinning current designs to our office walls. We regularly hang sketches and drafts on the wall for discussion (yes, even web designs). In doing this, discussions flow freely throughout the design process and specific problems are addressed in real-time. Another benefit of displaying designs on the walls is that organizing meetings doesn’t require any specially prepared presentations to visualize, which is in line with lean working methods.
Today, our agile design processes resemble how they were back then, but they always undergo fine-tuning based on the needs of the individual order and client. In our opinion, there isn’t one perfect agile process anyway, there are too many variables to take into account. However, our implementation of subsequent processes have had one thing in common so far: we plan at least four weeks of preparation time before we move on to the actual sprint phase. This allows us to immerse ourselves with the new project or topic at the outset and allows us to construct bold first drafts and visual experiments free from time pressure. This unsupervised time is important, as few clients have a good enough understanding of design principles to be able to make sense of technical or visual sketches, which are often still raw in this early project phase and may create some confusion.
The advantages of this approach benefit both sides greatly. By constantly involving clients in the design process, they can formulate their wishes and requirements much more precisely than in a one-off briefing. At the same time, as an agency, you benefit from this ongoing exchange and have much more opportunity to promote a common understanding of design. In short, this structure allows people to talk to each other much more frequently, intensively, and purposefully. In our experience, this inevitably leads to better results.
Of course, there are still plenty of potential challenges throughout the design process. If you don’t approach issues in a focused and consistent way, there is always the risk that the project will get out of hand. For example, it is always appealing for clients to explore every possible direction a project can go in detail – it saves them from having to commit themselves. At the same time, of course, this costs time and money and, in the worst case, leads to frustration on both sides. Here it is always necessary to weigh up together how many iterations are really necessary to reach the desired goal.
Since learning these valuable lessons, explicitly defining which process is right for the project at hand is one of the first things we consider at the beginning of each collaboration. In our experience, our rule of thumb is: the more complex a task is, the more important it is to engage in agile cooperation with our clients. Design processes are also learning processes – on both sides of the client-design agency relationship. Regular feedback loops help to gain a deep, common understanding of complex problems as quickly as possible. Working in short design sprints also ensures the work does not stray from the path we choose and, if it does, that we quickly get back on track. This allows us to adapt to changing requirements and to incorporate newly gained knowledge both quickly and effectively into ongoing projects.
Nevertheless, agile work processes are not a panacea. There isn’t one perfect process that works in every circumstance and can provide the best outcome every time. There is, however, processes that can best suit a specific team, project, or client. Despite these advantages, even complex projects can be excellently handled within a classic design process if you do your homework beforehand – with a sufficient briefing phase and a detailed strategy. In the end (as always), it is less the process itself that matters, but rather the people who work together within certain frameworks. At the end of the day, processes are only a means to an end – no more and no less.