Many projects have a separation between the design team and engineering team; in a perfect world both teams can work in harmony. The design team can hand off a design for a new feature and the engineering team can implement that design without warping it into something unexpected.
The reality of this isn’t as black and white, however; discrepancies between design handoffs and what is developed are a natural hiccup in development processes. That disconnect is what Design QA aims to solve: offering a space for design and engineering to collaborate before code reaches QA or even Production in some cases.
UXD and Design Collaboration
There is a difference in how design looks in a static comp and how the design looks and feels in the browser. Seeing the difference between static designs and interactive design in the browser is the perfect space to facilitate collaboration between teams. A practice I have personally used within my teams is having the designer who worked on what I’ve implemented see their design alive in the browser. Together on a screenshare, we walk through the new implementations.
Early and often collaboration between design and development is ideal, but not always perfect. Sometimes features get rushed or questions might not be apparent until mid-way through developing a feature. By collaborating during a Design QA session, design and development can review work and walk through any questions that have come up since development started.
A few questions that are commonly addressed during design QA sessions are:
- Does this feature’s spacing/layout feel appropriate in all viewports?
- Do state changes like hover/focus/active look as expected with wanted transitions?
- Can engineering use an existing code pattern over a new pattern being introduced?
- Can we refactor any unnoticed deviations within the designs that go against existing patterns?
Having collaboration in the workflow can be invaluable for a healthy product. This step in the workflow is best done before you merge a PR into a test branch or master. This follows a goal of always merging the most polished and complete code possible to test in production environments.
Screenshare: The Optimal Design QA Medium
The root of the Design QA practice is centered on design and engineering collaboration through screensharing. In this environment the engineer walks through the features built and both disciplines can review them. I consider live collaboration through interactive screensharing the most important aspect of the Design QA practice. Slack screensharing is seamless with how we communicate within DockYard, and using the screensharing tool in Slack is the medium DockYard prefers.
While collaborating, focus on the acceptance criteria of the feature. Think about how the user would interact with the feature and stress test what was built. Stress testing the feature with multiple disciplines will reduce the amount of bugs that hit QA, and different mindsets looking at the feature will provide a more well-rounded critique of how the feature looks and feels in browser.
Document your changes
When you are tinkering with the look and feel of the design during this pairing session, it is important to document deviations from the original designs. Product owners commonly approve designs before they are worked on by engineering. When this happens and you make changes during Design QA, it is necessary to note those changes. This practice of communication and documentation can make for a better experience for you as a developer, future developers, as well as the QA team reviewing the features.
Communicate
Communication is a key best practice you can have within your team, especially communication between disciplines. Generally, designers and engineers have different ways of thinking. When you get those two different mindsets in a collaborative space, the end result will be felt within your application and most importantly by your users!
Having the perspective of both designers and developers working together in a collaborative state facilitates the creation of a well-rounded application. Taking extra time to comb through the small details of how the app looks and feels in the hands of the user will lead to cleaner code and a smoother experience. Having this Design QA process in your development workflow is a practice that is impactful for the most important person, the user.
DockYard is a digital product agency offering custom software, mobile, and web application development consulting. We provide exceptional professional services in strategy, user experience, design, and full stack engineering using Ember.js, React.js, Ruby, and Elixir. With staff nationwide, we’ve got consultants in key markets across the United States, including San Francisco, San Diego, Phoenix, Dallas, Detroit, Miami, Pittsburgh, Baltimore, and New York.
