How we created our Designer-to-Developer heaven
When I joined the company in 2017 the designer-developer-experience was like this:
Designers were sitting with designers in one space of the office, throwing their final_final.PSD file over the fence to the developers, who were sitting in a different space or even a different building. Then the designer disappeared because the next project was waiting for their attention. Meanwhile the developer started to make sense out of what they got from the designer. When the designer saw the final project weeks or months later, it often had little to do with the initial submission: different layout, different colors and new freestyled components that never went over the designers table.
Since then we have come a long way. Today we work together super efficiently. Designers and developers share a language. We respect each other because there is a deeper understanding for our professions. Now our different ways of thinking complement each other and result in well designed, fast and scalable products. In this article Katja (Hocke) and Markus (Siering) describe what happened to get to designer-to-developer heaven.
1. Team Structure
sum.cumo is a tech company in its core. Most people working at sum.cumo have a title with the word “developer” written on their business card. As the company and the complexity of projects was growing, there also appeared a new species at sum.cumo – the UX designer. They brought the user centric view and lots of knowledge about methodology, user testing and research to the table. In the era before the UX-Designers, our Visual Designers were doing the UX job more or less well, often more out of a gut feeling instead of profound data, research and experience. Or even worse, good usability was no concern at all. The only interest of the stakeholders was to deliver new features as fast as possible.
We had to join forces. By building cross-functional project teams we got the UX Designers implanted directly in the heart of the product development process. We always try to staff our teams so that besides the other professions and roles, there is at least one team member who is a dedicated UX designer. For us the perfect triangle that produces the output “I would recommend the product to my friends” is made of the disciplines UX Design, Visual Design and Frontend Development working very close together. And we literally reduced the distance between the disciplines by mixing them together in one team space in one office. They have to scribble and talk and smack their heads together and meet for a beer at the rooftop terrace after the job is done.
2. Design tools
First of all, we finally got rid of old-fashioned tools and habits for UI design. Photoshop is for image editing & composing. But it does not fit the process of developing digital products.
These are exciting times for digital designers, since there is a huge variety of great and inexpensive tools out there. Tools that fit the needs to create responsive and modular designs. Tools that support the same logic and structure which a frontend developer would use when building an interface. This helps designers reduce unnecessary complexity in the layouts and think about different states of the design from the beginning.
What differentiates a good designer from a great designer is that they will not only deliver a brilliant design inside the layout program, but also make sure that the idea is bullet proof when it comes to frontend execution.
Our design toolset we currently use is the following:
- for exploration of UI Design directions
- for Design Systems and Libraries
- for images
- and sometimes for mock-ups
- for complex vector graphics (simple icons are mostly created in Sketch directly)
- for user flows and design prototypes with simple interactions and transitions
- for collecting feedback internally and externally (e.g. with the client or potential users)
- for developer handoff
- for micro interactions and animations
- for very functional high-fidelity prototypes
3. Connected workflow
Our designers work in an agile environment. We always try to have at least one UX designer and one UI designer per team. In the past designers were often perceived as a bottleneck that slows down product development. Before creating output, designers usually ask a lot of questions. Because they take their time to understand the brand, the problem and the users. There is a constant friction between business perspective (e.g. competitive feature-set and time to market) and user perspective (thorough understanding of the problem and the best solution to it).
To save time and still give the designers enough time to discover and explore, we started parallel workstreams.
While UX designers make research, create personas, align requirements and put the results in wireframes, the Visual Designers develop the brand design and it's visual language inside the product
When designers have first rough drafts of the UX and/or UI our developers start building the structure. Meanwhile designers work on the details of the design.
Master Component Library
For many of our projects we use Bootstrap as a framework. So, we came up with the idea of a Bootstrap based master component library for Sketch. The sketch file contains a system of well-structured nested symbols with responsive behaviour and overrides plus documentation. Next to the designer sits the developer who’s got a Bootstrap based Component Library (even with the same naming) inside Storybook.
These are the benefits:
Reduce repeated effort (designers don’t have to come up with a design system from scratch each time)
Reduced risk of incomplete developer handover (such as missing states of a component)
Lesser trouble with implementation of the design in code (Design close to the technical basis)
More speed in the initial phase of component design
Shared language of designers and developers
These are the downsides:
Designer have to get used to the new workflow: editing, customising and adding to an existing system needs a different mindset than starting on a blank artboard
Designers might feel limited in their creativity because a lot of interface basics are already defined
We still have that totally free exploration phase where visual designers don’t even think of libraries. In this very first phase of a project where a new design is created, our designers produce dirty sketch files with no system at all. And that’s ok. We want a lot of room for creativity, for exploring different directions. Next we print. Yes, digital designers make use of printers too. We like the have all the rough designs on the wall. For judging and discussing them in the group.
After the free experiments are condensed into a design language and everyone agrees on it, we take our basic design rules and put them into a copy of the master library. Usually we start by customising and updating the basics: colors, typography, logos, buttons. And then we proceed with the more complex elements like inputs, dropdowns, checkboxes etc.
Although we know these elements might change later in the process, we export a developer handoff with Marvel. This is the starting point where our frontend developers begin implementing the actual design in their Storybook master copy. Over time, the system grows, and the Marvel link is updated with more components.
We try to user test early design prototypes as often as possible, learn from the feedback and let it flow into our product backlog.
4. From design to frontend
With the design process clarified, let's have a look at the frontend part of development. Depending on the requirements of each project, we begin the project ramp up while the design is in the exploration phase. This includes the basic project setup with a lot of technical background stuff that by now is taken for granted for every frontend project. We mostly use our best practice boilerplate VuEcoSystem that collects our knowledge throughout previous projects. For the UI components, we mostly use the Bootstrap based library we've build up with our designers.
With the initial setup done, we can start implementing what's already designed. In this project phase, we mostly work in Storybook. in that way, we can make sure our components work well in isolation. This ensures reusability across the whole interface as the project progresses. In this step, we complete hand-off from Marvel to code.
Our todos depend on what the design wants – sometimes, we can take the already present basic components and apply special styling to them – as with the design, we also start with adjusting colors, typography, logos and the buttons. For every project, there are interface elements that do not fit into the "usual" set of interface components we need. These are custom built components which require a bit more effort to create, correctly implement and adjust according to our design.
This whole process never really stops for any project – the amount of newly created components simply slows down over time.
Developing the components in Storybook first leads to two interesting aspects.
For one, we make sure that all our components work on their own without any "outside" influence. This reduces the risk of introducing bugs because of unintended effects that other parts of the interface could introduce (technical sidenote: e.g. a CSS class that affects a component but comes from a different component). Through this process, the later implemented interface becomes more robust and we experience less issues and bugs when the project is (going) live. It is also very simple to share these isolated components with their different states and interactions with our design people and product owners to have them check the implementation against what was designed. This sounds simple, but having an actual link to a component implementation is very powerful. Before using Storybook, we had to send orders like this to people for checking a part of the interface: "Go into the account view. Then click on the "set new password" link. Then type a password with only three letters. Press enter. Now you can see the error box with a sample text." Now, we can "just" send a link that lets people change the error box state, click on buttons, switch the text etc. Very helpful.
On the other hand, though, building isolated components unfortunately leads to exactly this at first: Isolated components. Of course, our clients, designers, project leads etc. would like to "see something" in the browser that at least resembles what they saw/created in the design. This process needs a bit of moderation in the component creation phase. The upside here is that implementing the different views of an app is way faster as soon as the components are created and usable.
In the end, we arrive at a well tested, robust set of components that seldom need adjustment or massive refactorings. Which, in the end, saves us as a team from a lot of complicated efforts and saves our clients a lot of money that would otherwise be spent on iterations, refactorings and bugfixes.
- Change of team structure (from department-wise structure to cross-functional teams) leads to way better communication
- Using design tools specialized for designing digital products
- Changing the design workflow from page driven design to component based design
- Working with Design Libraries/Design Systems
- Establish master setup, a library based on the FE framework your developers are using (ours is Bootstrap)
- Designer-to-Developer Handoff in Marvel (component library with all states and assets + sample screens)
- Frontend implementation of components happens in Storybook first, in the actual interface later on
- Communication through the whole process!