Miranda Sawyer

Roles: Lead UX Designer

To comply with my non-disclosure agreement, I have omitted confidential information.

Role

I accepted the role of Lead UX Designer for the North American online ordering platform a year into the project. I had been on agile projects before, but this was my first continuous improvement and continuous deployment project. It brought its list of pros and cons. When I took over the role there were six teams, six designers, and 80 people in various roles dedicated to the program. My primary role as UX Lead was to solve problems and fill in gaps. My primary tasks were to:

1. Resolve any blockers
2. Review and approve all work
3. Troubleshoot any issues related to UX or UI
4. Provide coverage during vacations and staff changes
5. Mentoring six designers 

The First Retro

Each month the Lead UX Designer was responsible for a retro to gather feedback from the Product owners, Product Manager, Lead Enterprise Architects, and designers. There was a great deal of problems to solve that revolved around design operations. I remember sitting at the first retro and feeling completely overwhelmed, that I had taken on way more than I could chew. These were the main problems that came up in the retro. 

1. Lack of awareness and collaboration from the designers
2. Lack of due dates for designers
3. Lack of consistency coming from the design team

These are concerning problems. I first set up interviews to speak with the Product Owners, Product Managers, Lead Enterprise Architects, and designers. I listened to their feedback and asked for their advice on fixing the design process so that the end product could be optimal.

Design Ops

Thanks to the feedback I received over time, I was able to improve all three of these issues. Each program retro continued to improve until we got to the point where our retros were small reminders, lots of kudos, and moving on to concerns that the industry hasn’t addressed yet. I continued to accept advice and ask for feedback from everyone on the team. The following are the main initiatives that I used to change the process and culture of the design team and the rest of the team’s perception of us.

• Design System and Pattern Library
• Designers integrated into Jira
• Each designer had their team to support instead of being feature-based
• Due dates (yes, this was a new concept to everyone)
• Spec sheets and interaction notes
• Celebrating the courage to share and fail
• Workshops with developers

All of these changes took time, trial, and error. After approximately six months the design team was running smoothly. Each designer was growing in their skills and the end product was improving with measurable results continuously.

Workshops with Developers

I love a good workshop. Conducting workshops with the developers went a long way toward everyone feeling like they were part of the same time and process. The designers learned quickly that the developers’ unique perspectives were an asset. Everyone fed off the creative energy. One idea would generate an even better idea.

Another bonus to the workshops with development was that all of the designers grew as problem-solvers. They needed less help planning, running, and analyzing their workshops.

Moving to Jira

When I first started as the Lead I was told that the designers on the team had refused to use Jiras. After using Trello for a while, they saw the advantages of being able to see what everyone was working on. They were happy to move to Jira because it also gave them a visual indication of their work while the other developers were sharing their status every morning. We gradually moved to Jira, so every designer had their own. When features overlapped each other it was easy to tag another designer. Ultimately, we ended up using Jira just like the developers did and shared all of the benefits as a design team and with the development teams.

Design System

When the North American Online Ordering platform launched there was no design system, no reusable components or patterns. They had the goal of launching, optimization and refinement was put on the back burner. One of my goals and responsibilities was to create a design system for all experiences to utilize. The test case would be my primary project. It was no small undertaking to create a system for an experience that was already a year old, not to mention the other experiences under the company’s umbrella that were even older.

Steps

1. We focused on the primary user paths
2. Within the primary user path, the most common elements were reviewed looking for opportunities to simplify, improve consistency.
3. These audits were a chance to improve the responsiveness and the accessibility of the experience.
4. We documented the Design System in a central location that was one source of truth.
5. As a team, we reviewed each other’s work twice a week looking for opportunities to be consistent and add to the Design System.
6. Working with the Product Owners and development, each sprint we optimized or reduced existing components. Development had their technical debt and welcomed the opportunity to reduce that debt.

The advantage of the project being CICD was that if something did not resonate with users we could have it updated by the end of the day. We averaged eight deployments a day. I also found that we could be leaner with the research because we had additional tools besides Google Analytics to measure customer satisfaction. The project also had the benefit of very vocal customers.

• Reduced communication overhead
• Saved time for designers and developers
• Created a more consistent experience for customers

Conclusion

Feedback in monthly retros with the Product Owners, Scrum Masters, and Lead Developers became positive and constructive. Everyone knew what the designers were working on, and when they were hoping to be finished.

The experience that was created for Canada Online Ordering was utilized for United States Online Ordering.