To deliver a product that involves design - from research to screens and usability - and its implementation by a development team can be a big challenge for all parts involved. If we aim to really address users needs and deliver high quality products and meaningful experiences, it’s important to have a team aligned and fully integrated.

The interaction between stakeholders, designers and developers normally involve a lot of friction and divergence of concepts and vocabulary. The back and forth between development and QA normally take a lot of time and effort till things get quite right. Besides, people from different backgrounds tend to have diverging perspectives about the value and the challenges of implementing an interface. Developers get frustrated when faced with a non negotiable design, seemingly impossible to implement, while designers can be angry seeing their conceptions poorly executed and stakeholders impatient with a product that never gets done.

These problems can be mitigated by a solid management process and a conscious effort to create a common ground for communication. Following a path in the direction of the implementation of a Design System can be a powerful tool to achieve that.

In this talk I’m going to share the results of the gradual improvements adopted by our team in an effort to make these interaction smoother and to deliver a product with higher quality standards and more aggregated value to our client. I’ll explain how the processes we introduced to our interactions were able to impact our productivity while improving the team’s and the project’s health.

Outline

1. Basic definitions of a Design System
   1. Why having a Design System at all? The advantages of having consistent and predictable patterns for design implementation
2. What it means for a developer to implement a Design System
   1. Creating a common vocabulary between Design, Development and Stakeholders
   2. Reflecting the Design System structure in the project’s - components, files and variable names organization
   3. Having predictable patterns to work with
   4. Being able to easily QA our own work before submitting it
      1. How making a QA checklist improved our validation process
3. Quick introduction to the project’s scenario
   1. The redesign of a platform with lots of legacy code and unclear business rules
4. Processes developed to improve our teams interactions
   1. The complete workflow and its transitions from first ideas to production
      1. The Planning Board and its rituals - ideas, research and specification for development
      2. The Design Board and its rituals - research, low and high fidelity prototyping, client and development team validation
      3. The Development Board and its rituals - development, code review, QA and delivery
   2. The Specification Meeting
      1. Checking for available data
      2. Checking the feasibility of desired interactions
      3. Using available components or estimating the development of new ones
      4. Checking for empty and loading states
      5. UI elements states - don’t forget the hover and focus states
      6. Evaluating the effort to implement desired interfaces or thinking of more viable alternatives
   3. Interacting with the Stakeholders
      1. Constant feedback from the first design ideas to the development challenges
      2. Keeping non technical people informed of the limitations encountered during implementation
      3. Proposing more viable alternatives when faced with technical obstacles
      4. Being clear about delays and tasks that will take a long time