Role: 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 a large online ordering platform a year into the project. I had been on agile projects before, but this was my first continuous improvement continuous deployment project. It brought its own 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:
- Resolve any blockers
- Review and approve all work
- Troubleshoot any issues related to UX or UI
- Provide coverage during vacations and staff changes
- Mentoring six designers
The First Retro
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.
- Lack of awareness and collaboration
- Lack of due dates
- Lack of consistency and/or patterns
Design Ops
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. 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 own 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.
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.
Workshops with Developers
Planning workshops with the developers went a long way toward everyone feeling like they were part of the same time and process.
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.
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. This smoothly running system allows us to move on to the next step, creating a design system when there had been none.