DESIGN TEAM STANDARDS
My role
Design Manager
Design lead
Activities
Workshops, surveys, working sessions, Agile project plans, Confluence documentation, communication planning
TL;DR
Process flows for design files
Workshops on pattern best practices
Context
Scaling a design team involves aligning the team on core processes and ways of working. It also means addressing moments of design debt that might already exist and establishing team standards.
This case study is a model for future teams and a reflection of tactics I have employed in previous teams to improve design team standards.
Key obstacles
Growth and onboarding
The more hands the greater chance of a mess. That principle applies to several moments in life, and it's no different when it comes to design and digital teams. Growth is an inevitable part of any group but it also means maintaining brand and digital standards becomes more difficult. If two designers aren't following the same processes or communicating then you sometimes end up with two different solutions to the same problem. This multiplies in effect with each additional member of the team. As new designers join, the goal is always to onboard them as quickly as possible. When the back of the house is in disarray it adds to the time needed to get everyone working properly.
Design debt
Not many teams have the benefit of beginning fresh when it comes to establishing team standards. Often there is work that exists, design solutions already in live web apps, and most importantly, files and documentation that are out of sync with each other and with production code.
Leadership buy-in
Business priorities will forever be an obstacle to building clean team standards. Technology leaders often fight for the chances to work through tech debt in amongst new feature releases. This is an understood part of the long-term maintenance of code and architecture. It is less understood that designers will be incurring the same kinds of debt in their work.
Surveys, workshops and process transparency
Short term impact
Version control
Some improvements see more immediate impact than others. Implementing a system for branching and version control for the designers has been a big step in the right direction. Everyone in the circles around the designs benefits from this very quickly too, since the risk of lost work drops significantly. Designers have been able to troubleshoot through version history markers and team notes when changes were made, who added what to each files, and what areas of the screens were impacted. This transparency in process has allowed design to then push this same information out to product partners, developers, and leadership to align everyone.
Audits and pattern workshops
It pays to know all the current components and patterns in production that the design team has to work with. Collecting this information is not always simple since it should be gathered from all the digital properties the organization maintains. Some places will have dozens of micro-sites for partners or events, and others may only have a single mobile app.
Using the examples drawn together from the audit we've been able to align the team on some more singular options for the same solutions. Are there three different styles for buttons that could be consolidated into one? Should modal windows all look the same for every instance, or did we truly need these other variations? These democratic workshop decisions have net some positive short term direction for the team. Design debit gets reduced moving forward as everyone begins to depreciate older styles and it gives clarity to those more immediately stalled in their work.
Workshop on modal use patterns
Long term impact
UX Playbook
One layer of improving team standards has been gathering everyone's input to define some of our key deliverables and functions in a UX playbook. Not only has this aligned us on the language we use to describe ourselves and our activities, but it's been especially valuable setting expectations with leaders outside of our team. Wireframes can mean a lot of different things when everyone expects different levels of fidelity! Creating a UX Playbook has helped everyone begin to use the same definitions and played an important part in managing design onboarding and stakeholder onboarding.
UX estimation and work points
Using the definitions and activities from the playbook, I've also seen benefit in creating more detailed estimating models for UX work. Once you account for the different phases of work involved in each play you can create a system of assigning points of effort to each. This model won't be suitable for all teams but it has helped us even in the discovery of the stages for creating a user flow, or the effort needed in UI mockups versus wireframes. Each play includes a tally of points for the initial reference research, hands-on design, and report and presentation - as the baseline. The number assigned here can then be directly translated into estimations for Agile groups, leadership metrics for UX, and resource planning for the team.
Playbook pages help outline how UX teams operate
Overhead view of estimation and point system
