- Product owners
As Conway’s Law suggests, “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” Therefore, any communication issues in your organization will be reflected in your product’s build. Whether it’s unaligned buttons, wrong offsets, jagged assets, absent shadows, poor animations, or flawed breakpoints, these issues are representative of the organization’s core structure.
As such, design plays a vital role at Mirego in helping us bridge the gap between cross-functional teams to ensure that our core organizational structure is represented within our product. It should go without saying that the design, QA, and development teams, should have a solid relationship. Moreover, implementing design QA processes allows us to refine our workflow to remove any friction or frustrations between developers and designers, as well as to optimize the user experience with minimal budgetary implications.
Why design QA? For starters, usability allows us to measure the quality of the design as well as the overall user experience from end to end. Secondly, code quality and UI quality should go hand in hand in order to build great products and design memorable user experiences.
Design is not just what it looks and feels like. Design is how it works.
Unfortunately, implementing processes that foster open communication and facilitate collaboration between cross-functional teams can prove to be quite challenging. Having worked with other teams in the past, I can confirm that it’s not all that easy to get a clear overview of what 2-4 developers or designers are working on simultaneously despite the fact that they may be working on the same project. There’s a gap that needs to be addressed. At Mirego, we’ve implemented efficient work processes that bridge these gaps and allow us to focus on perfecting the user experience to build betters products. Here’s how we went about it.
Finding the Problem
Truth be told, design QA is generally viewed as an afterthought. In other words, it’s considered only when the sprints are completed or once the build is ready to be released. More often than not, the design QA process isn’t integral to the app validation process, and it should go without saying that working backwards is frustrating and efficient. In fact, it fosters an antagonist relationship amongst developers and designers. In short, it’s unproductive. Furthermore, going about the design QA process in this way comes at the risk of forgetting those little, yet very important UI details which may result in missed or neglected user-facing touchpoint opportunities and a shakier overall user experience. Adopting an ongoing design QA process allows teams to iterate as they flesh through the details and address any potential core issues. At the end of the day, it’s about working preemptively as a team to foresee these critical shortcomings and ensuring that the user experience is flawless, from beginning to end.
Working Together to Find Solutions
Once we picked up on these issues, we worked as a team to brainstorm various solutions to this problem. Here’s a quick recap of the interesting elements that were brought up during this discussion:
- Allowing designers to work collaboratively in GitHub to improve and facilitate cross-functional team communications.
- Tagging designers in any UI-related pull requests so that they can validate the UI while the developers code to improve efficiency.
- Giving designers permission to make adjustments in real-time when needed.
- Keeping the design team involved from beginning to end so that they can track what is being done and when it’s being worked on.
- Improving communications and work processes between the development and design teams to make sure that they collaborate in a timely fashion. For instance, using the pull request process for both teams would be helpful as the comments are in chronological order, which would keep all team members focused and on the same page.
Defining the Process
After browsing through our lengthy brainstorm notes, we came to the conclusion that implementing a pull request process would be an efficient way to go about optimizing our process in a manner that’s beneficial for both teams. Here’s what we came up with
- Step 1 - The designers create mockups; then the developers integrate them.
- Step 2 - The developer tags the design team in all UI or design-related pull requests so that the designer can verify various UI elements such as the font, colors, animations, or other.
- Step 3 - The developer adds phone screens in a variety of sizes (iPhone 8, 8+, X, or other) so that both teams can verify that each screen format looks flawless and functions as it should.
- Step 4 - The designer chooses whether to accept or refuse the pull request, and may leave comments with the developer himself, or use Github to suggest any modifications.
- Step 5 - With this critical feedback on hand, the development team can proceed to modify the UI elements highlighted by the designer and can follow-up for validation using another pull request once it’s all done.
Now, once the sprint is over with, or once the build is released, the designer won’t have to review the app in its entirety to ensure everything is in place and running smoothly. Implementing this process has streamlined our work and bridged the gap between the design and development teams.
I realize it may not seem like much, but this easy fix could drastically improve your work efficiency and productivity. Fostering open communication and adopting integrative work processes between the development and design teams will open the floor to interesting UI and UX-related conversations, and will give everyone a clear overview as to the project’s progress for each sprint. At Mirego, not only do we challenge ourselves, but we also challenge our work processes. And, it’s this adaptive and open mindset that pushes us to improve our work processes, and empowers our teams to build world-class digital products renowned for their excellence.
Thanks for giving my article a read. Feel free to give it a share if you found it valuable.