Working as a UX designer on an agile team opened my eyes to new ways to experiment and collaborate. Focusing on communication validated and empowered me to try new things and speak my mind. The agile engineers and I explicitly shared a common goal; we were flexible, built faster, and innovated. Conversely, I noticed that my design peers rarely worked collaboratively with other designers, and had little exposure to other design work. What if we could increase visibility and improve our innovation simply by allowing designers to collaborate the way agile engineering teams do?
Aiming to increase sharing not just within the respective product teams, but also with others in the design community, I took some of the engineers’ everyday principles and turned them into agile approaches the design team could practice for faster decision making, improved collaboration and increased overall designer satisfaction.
In this article, we’ll review five engineering principles and processes that can be directly translated to the design discipline.
1. Turn Code Reviews into Peer Reviews
Typically in software or application development, there is one code base that is shared among many engineers. Since so many hands touch the code, it is imperative that the code base doesn’t regress. Engineers review each others’ code to keep code quality and readability high.
Obviously, extensive coding is not expected in the world of UX design, but we can still translate this to the design discipline. Regular peer design reviews are a great way for designers to learn from one another, and also to strengthen their feedback skills—both giving and receiving feedback. It also allows for designers to act as a system of checks and balances, making sure any missing flows are documented, aligning with the product ecosystem, and adhering to company style guide colors and patterns.
At Intuit, our design patterns team holds bi-weekly office hours as dedicated time for designers from multiple business units to get feedback on the patterns they’re implementing in their products. Other approaches for getting or giving feedback may include holding monthly portfolio reviews, or weekly lunch-and-learns where designers rotate critiquing each others’ designs.
2. Turn Paired Programming into VsD + IxD Partnering
As I mentioned, code is typically shared among engineers on an agile team. Often times one engineer will pair up with another engineer at a single computer. This is known as paired programming, and it saves time and headaches, since engineers are more likely to discover bugs as they work together—literally, two heads are better than one.
For designers as well, working in pairs can output better quality. On many projects, a visual designer (VsD) and an interaction designer (IxD) both attend a product planning meeting, absorb requirements, go back to their desks to work, and then come back with design concepts that look vastly different. Alternatively, on projects following the waterfall methodology, the IxD is responsible for creating the design process, and the VsD doesn’t have any input until after the interaction designs are complete and approved.
IxD and VsD partnering up and attacking designs.
This can result in (at best) decent designs that could be better, and (at worst) requirements lost in translation, or wasted work on the part of one or both of the designers. Overall, the VsD and IxD should have constant communication, so that designs are influenced by both minds from the start. Regularly scheduled partner work fosters that communication for better cohesion and quality designs.
There are several ways that design “pair programming” can happen:
- Designers can spend a half hour discussing which requirements to tackle first, and how they plan to tackle the tasks, before each begins to design separately.
- Designers can divide the workload, and clearly define who will work on which interactions or visual elements.
- Each designer can create both visual and interaction specs for a specific feature or platform (i.e. iOS and Android use different patterns, but the functionality should be the same).
- One designer can take the lead on a task, sketching out ideas on a whiteboard while the other offers input.
3. Turn Refactoring into Revisiting Source Files
For software engineers, refactoring tries to make code clear, simple, and elegant without changing functionality. In other words, when engineers refactor, they clean up their code. Code is more maintainable when it’s written with better readability and less complexity. Agile development encourages engineers to refactor as they work, in order to allow the team to move forward more quickly.
Like roommates sharing a kitchen, members of a design team should clean up after themselves. On my team, designers constantly share files so that we can reuse icons, colors, patterns, and interaction elements. But if another designer sends me a source file with over 100 layers, it’s so confusing that I’m likely to redraw the entire thing from scratch, which wastes time and increases the likelihood that our final product will feel disjointed.
Revisiting source files after delivering mockups and specs is good practice. It’s highly likely that other designers will work on a similar feature or interaction later in the project, so we always want to create source files that make it easy to build off our designs.
When working with source files, there are best practices we can follow. In Photoshop, for example:
- Clean up and organize layers in the PSD files
- Make sure layers are adequately and logically named
- Get rid of any perceivable unnecessary metadata (such as hidden layers, duplicates, or off-canvas elements.)
4. Turn Daily Standups into Design Standups
On an agile project, every work day the team meets to bring everyone up to speed on the key project deadlines and updates. Engineering standups are typically 5 to 15 minutes long. Each engineer gives a work update, asks for help if needed, and shares anything blocking their progress.
Having attended daily engineering standups, I now recognize how important frequent daily communications are to designers on a larger umbrella business unit. As a result, we now do multiple design review throughout the week where designers are encouraged to discuss their daily concerns as well as larger design issues.
5. Turn Sprint Demo & Retrospective into Design Retrospect
In agile development, at the end of each sprint (or internal short-term deadline), the team meets for a sprint demo and retrospective. A sprint demo allows stakeholders, executives, and customers to see the latest completed prototype, and to provide feedback as necessary. A sprint retrospective is a time for the team to discuss how the sprint went, in order to improve their collaboration and efficiency in future sprints.
We do not learn from experience. We learn from reflecting on experience
—John Dewey
After every sprint, my product team gets together to write down our thoughts on what went well, what can be improved, and what totally sucked; we call them roses, buds, and thorns. This may feel a bit like group therapy, but I firmly believe this dedicated reflection time helps strengthen project continuity and team cohesiveness.
The product manager on my team also writes up some product release notes explaining new features we put in, features we took out, and how we plan on measuring success, so that colleagues and stakeholders within the organization can understand what we’ve been doing, make sure it aligns with their fiscal year roadmaps, and see if we need additional resources.
At Intuit, teams learn from their successes and failures during a sprint retrospective.
Because projects are often deadline-driven, it may be difficult to find time to reflect. After all, there’s always more work to be done! However, it is important for designers to reflect upon what they have accomplished or what they need to refine, in order to improve the workflow and their individual work. Teams should proactively include a design retrospect in the design process, to discuss newly discovered best practices or flaws in the process.
Implementing Agile for Designers
As with any kind of change, a commitment to improving collaboration within the organization is the first step to implementing the benefits of agile. Most of these strategies are really just small tweaks to the everyday design process, and can be easily implemented. To get started, try some of these quick wins:
- Seek and give feedback to fellow designers. Hold peer reviews or office hours. Constantly seeking and giving feedback in the design process keeps design quality high.
- Work in pairs. Working with a partner, especially in a pair that complements each other’s skills, encourages collaboration and increases efficiency.
- Encourage designers to clean up after themselves and share source files the way they would want to receive them. Raw design documentation should be clearly organized and stored, for posterity.
- Share information about each designer’s work process and daily goals. Understand that shipping products and services is team-driven. By sharing working statuses and progress, the team can prioritize and rearrange work as necessary.
- Reflect and learn. Dedicate time to self-reflection in order to learn from past experiences so that the designers never stop evolving and improving.
- Read Elements of Scrum to dive deeper into agile practices, and further understand engineering processes and collaboration. Elements of Scrum breaks down principles and practices with practical examples and clear illustrations.
- Scrum: The Art of Doing Twice the Work in Half the Time contains engaging stories and use cases about process transformation, simplifying work, and increasing productivity. Though both this book and the Elements of Scrum are written primarily for engineers, non-engineers can consider how many of the principles discussed can be translated into any discipline.