The pixel perfect front-end

Dev Diary
Titelbild_thepixelperfectfrontend

Is it a myth or can we achieve it? What’s so bad about pixel pushing? Learn more about our collaboration between designers and developers and about how we learned to value the expertise.

Author
Lilla Fésüs
Date
September 20, 2021
Reading time
4 Minutes

Collaboration between designers and developers is essential for high quality software and allows bringing out the best from each party’s expertise. Based on our long-term experience, we have developed a design-dev workflow that helps teams to work together smoothly, boost efficiency and accelerates the onboarding of new team members.

Background

We have encountered several problems before establishing this design-dev workflow. It was meant to eliminate conflicts and reduce frustration on both sides. Let me give you an overview on three particular problems we were dealing with back then.

Different views: Little differences may not catch the eye of a developer, but may be important from design point of view.

Responsibility: Developer should not decide alone about differences in the implementation. Maybe those 3 pixels meant something.

Logistics: When and how to trigger a design review? How can we integrate it into our development workflow?

Design-Dev Workflow

activityDiagram

Not a fan of activity diagrams? Let me walk you through our design-dev workflow.

There are three main players in this workflow: the developer, the technical reviewer and the designer. In the following we will have a detailed look at the different stages and connection between the different players.

Development

Who: DEVELOPER

  • both design and development follows component-based design, which means concentrating on compositing a set of standard components to create new and more complex components instead of reinventing the wheel all the time
  • both design and development sticks to the predefined colors, typography and grid and tries to avoid exceptions

Communication

Who: DEVELOPER

  • in case of differences between design and implementation, even though the standard components were used, get in touch with the designer
  • choose an appropriate communication channel (Issue, Slack, in person…)

 

Comparison


Who: DEVELOPER

comparison
  • put design and implementation on top of each other
    with Zeplin pop out, Gimp or  sh -c 'xprop -f _NET_WM_WINDOW_OPACITY 32c -set _NET_WM_WINDOW_OPACITY $(printf 0x%x $((0xffffffff * 25 / 100)))'  on Ubuntu
  • the comparison is a control mechanism for both developer and designer
    • the developer controls his own work and can intercept bigger issues with the implementation before it goes into review
    • the designer can see the differences easier and decide whether it needs to be corrected or not
  • the overhead is not as big as it seems for the first time and the win and impact are worth those 5 minutes

Merge request completion

Who: DEVELOPER

  • no WIP
  • pipeline runs through
  • fill out MR checklists
  • assign technical reviewer

Merge request template

### UI/UX checklist - [ ] I have checked the UI regression test results and all the changes are clarified with the person responsible for design - Review of design: - [ ] Design was reviewed by the person responsible for design and the found issues are documented in form of comments in the merge request - [ ] Design was not reviewed, because there were no design changes #### Comparison with design <!-- uncomment the next line and remove the headlines below if no comparison had taken place There is no comparison with design either because there is no design to compare the implementation to or there were no design changes. --> img

It is highly recommended incorporating the workflow in the merge request template in order to help the developer keep in mind the required tests, tasks and todos.

Technical review

Who: TECHNICAL REVIEWER

  • can find technical and design issues
  • decides whether a (parallel) design review can start
    • a parallel design review can usually start if only small, no too risky technical issues were found and the found design issues are reasonable and again, not too risky
    • not too risky changes are those, whose fix will most probably not introduce other design issues

Trigger design review

Who: TECHNICAL REVIEWER

example
  • mention designer in a comment, this way he receives email and has a todo item in GitLab
  • comment has to be a thread so that the MR cannot be merged without resolving it first
  • prepare test data if necessary
  • mention relevant links and users, even link to UI regression test if necessary
  • mention already found design issues
  • mention uncertainties, open questions or shortcuts

Design review

Who: DESIGNER

  • comment instead of “reaction”, because in case of a “reaction” no email notification is sent
  • you can use separate threads for the found issues
  • use common sense

Merge

Who: TECHNICAL REVIEWER

  • fixes of design issues need to be technical reviewed again
  • design after fixes needs to be design reviewed again
  • if necessary, start a new loop by assigning the merge request back to the developer
  • merge if everything is done

     

Add-ons

First and foremost, adapt the workflow to your own team’s requirements. There are some GitLab specific aspects in our workflow, which might change in another tool of your choice. You can also try to incorporate the following two additional options that are undoubtedly useful, but are not core features of the design-dev workflow.

Approval

An approval from a designer can be additionally required to complete the merge request. Use default approval settings to enforce this rule, but allow it to be overwritten in each MR. Discuss the advantages and disadvantages of this approach and find a process that suits your team.

Follow-up issues

If something is not implemented or fixed in the given merge request, create a follow-up issue to keep them in mind and do not forget them.

 

Conclusion

This workflow works for us like an oiled machine. The comparison helps me a lot to catch bigger issues with the implementation before it goes into review and incorporating other parties’ expertise helps us to deliver high quality and beautiful software.

More of that?

Blog_Titelbild_SSR_APP
Dev Diary
Cut to the chase – What is an SSR app?
April 25, 2022 | 6 Min.
Titelbild_React Discovery Days
Dev Diary
React Discovery Days
March 16, 2022 | 8 Min.
rememberMe_Titelbild
Dev Diary
Remember-me like behaviour with JWT
August 12, 2021 | 7 Min.

Contact form

*Required field
*Required field
*Required field
*Required field
We protect your privacy

We keep your personal data safe and do not share it with third parties. You can find out more about this in our privacy policy.