Sketches are sketchy

Why designers and developers can mutually benefit from working together, both in terms of communication and efficiency

In my experience, too much time is spent miscommunicating ehen it comes to software development. The old culture of handoffs and sketches are still very much alive, but this environment is in the process of changing, designers are more involved in development and developers are more involved in the design process. I have first-hand experience in how a design system can make communication and co-creation between design and development a whole lot easier

How the development process (unfortunately) often is

The standard way of developing solutions is that a designer designs a sketch or several sketches representing this solution.
The sketch gets uploaded to a Trello-board (or something similar) and time goes by and the sketch will be prioritised up and down until finally being ripe for the taking for a developer. The developer will to her best ability try to decipher what it was the designer meant.

Sketches are usually just handed over from designer to developer

This translation of sketches into code might have several outcomes depending on the designer, the developer and the communication between them. First the ideal way: The solution is correctly translated and quickly built, everyone is happy! Unfortunately there are other, not so ideal outcomes: 1. The sketch gets misinterpreted and the solution ends up being completely different from what was intended. 2. The developer and the designer have to spend a lot of time going back and forth to verify each step to ensure that the result will be as intended. 3. The solution looks and behaves as intended but the developer has to make a lot of tweaks and hacks to make it juuuust right ending in big, bad and hard-to-maintain code.

A metaphor for a design system

So to show the advantages of a design system i give you the metaphor of building a chair. The chair represents web-application and the wood represents the code, the chair is made of wood. If a designer was to design a chair it would surely be an advantage to know a bit of the properties of wood, how to best utilise it and what its possibilities and constraints are. (i.e. designers should know a bit of code).

Designers should familiarise themselves with the materials that will be used

In this metaphor the developer is the carpenter, and the designer hands over the instructions for the chair (the sketch). Building it from scratch she would have to go into the woods, chop down and process a tree every time the designer sends over the instructions for a chair. It would be much easier to go to the store and pick up the pre-processed parts that are needed that beforehand has been made by the designer and the developer together (the store being the design system). Even better: let’s skip the instructions (sketches) altogether, everyone knows that instructions for assembling furniture is the worst! Let the designer go into the store and pick out the pre-made parts herself and build a prototype of the chair. This eliminates the need for a translation of the design since it is already made using the standardised materials that the developer would herself use. If needed the designer and developer can together continue to build on the prototype ensuring that they make the best chair possible both in terms of the user experience and the quality of the material (code).

booster conference.030

How to build the system

The way we build the system is that we build the materials together as we need them. The level of specificity what you would want to build the system can vary. If you choose to just standardise the individual parts of the chair separately or the entire chair itself depends on what your goals are.

The smaller components, the more flexibility

The smaller components, the more flexibility, i.e. you can build more unique chairs by using the same components, but you might rely a bit more on documentation and instructions to make sure that one variety of chair looks the same different places.

Bringing this metaphor back to what it represents: a design system can be made out of groups of components or the individual components. In the design system we built we have smaller components that offer us great flexibility.

booster conference.035

How to use the system

Instead of sketches, I as a UX designer ideate and create prototypes in HTML and css. By doing this we have much more control over the development of our solutions both in terms of usability and the quality of the code, and we make co-creation between UX and development a whole lot easier.

I’ll end with an example of the advantages of a design system. On the development of an application we spent 5 days building a simple frontend prototype of a solution using the design system with some functioning backend, lets call it “solution A” that we believed fit the user needs. When testing it with real users, the message was clear: “Please promise me you won’t make this”. Getting the same type of feedback from several other users I brought the insight back to the team and we decided to act quickly. This was a Wednesday, on Thursday we built a radically different frontend responding to the user needs and on Friday I tested it on users again. The response was completely different, it fit the users need in a way Solution A absolutely didn’t.

If we didn’t already have the components needed to assemble a new version of the frontend, it would have taken a lot more time for me as a designer to design and then hand over to a developer to build. And an extra bonus is that every time we build by using the design system it is easier to make something that is coherent with all the other applications in our system.

To sum up

A design system offer designers and developers the tools to co-create making it easier to quickly prototype, test and build the best possible solutions both in terms of the user experience and the quality of the code.