Introduction
I set out on a journey to better understand how the design team I lead was performing. To do this I spoke with over a dozen design leaders from all over the world, from India to America, Australia and beyond. I learned that design teams come in all shapes and sizes but that similar issues affected product design teams the world over. I listened to how each design leader worked with their teams and what they had done to help their teams grow and thrive.
This article attempts to pool the knowledge of those design leaders and provide a guide for others. Its aim is to help you understand where your design team sits in terms of maturity and give you some ideas on how to advance and grow its maturity.
How do you measure maturity?
Modern design teams do much more than pump out designs so working out a scale for design team maturity was my first challenge. Listening to each design leader, I began to see patterns in the issues they were tackling and the strategies they had devised. From those conversations and considering my own experience leading design teams, I formulated a scale broken down into four pillars:
Design production
- The act of producing design assets
- The process a designer follows to complete a piece of design work
Design ops
- How do you support your designers
- Design systems
- Tooling
- Team topology
Discovery
- How you connect with your customers
- Competitor analysis
- Technical discovery
Design strategy
- Solving the right problems
- Product Visioning
- Demonstrating the value and impact of designers
- Collaborating in org-level strategy discussions
These pillars are not mutually exclusive, they blur into one another
It’s highly likely that a team will have differing levels of maturity across these pillars.
The ordering of these pillars reflects how a design team is most likely to mature, by this I mean that:
- When a team is founded, its job is to produce designs
- Its next step is likely to be improving how it produces designs by working on Design Ops improvements such as creating a design system
- Once the team is able to solve problems well, it’s normally then begin to question which problems should be solved hence it will look to improve its ability to discover insights that allow designers to spot higher value opportunities
- Once a team is able to able to do end-to-end high quality discovery and design it’s natural to “zoom out” and start to consider things like what does the future look like, are designers doing valuable, high quality work and how can we help lead the org
- When a team is mature enough to have solid design strategy work happening regularly, its leaders should be able to articulate the value the team brings which should hopefully answer the age old question of, “What is the ROI of design?”
- If Design leaders are collaborating in org-level strategy discussions then it could be said that, “Design has a seat at the table”
Signs of Design Practice Maturity
OK, we have four pillars but how do we rank maturity within each pillar, what are the practical signs and signals that help a design leader understand where their team sits in terms of its Design Practice Maturity?
I wanted a scale that wasn’t too complex and one not based on a numerical score as I thought this was too precise a measure. I was immediately reminded of the scale Ron Kohavi used in his excellent book Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. This breaks up maturity in running experiments into four phases, crawling, walking, running and flying. I think this is a great way of thinking about a growing maturity so I totally stole it for this article, thanks Ron.
Applying Ron’s scale to our four pillars we get:
Design Production
Crawling
- Design work done in isolation
- Each design project starts out as a blank page
- Little thought given to context of problem being solved
- No quality assurance or design governance processes in place
Walking
- Design work is done within a functional or cross-functional team where the designer is able to work with engineers and / or other designers
- The designer understands the context of their work as it relates to user value
- There are some known standards or known good patterns that can be referenced and reused
- Design work is reviewed before engineering work commences
Running
- Designer is a permanent part of a cross-functional team and has deep domain knowledge
- There is a design system that designers use regularly
- Designers follow a design process that is itself designed and the subject of a continual review & improvement cycle
- Design work is integrated in the Quality Assurance and review processes of the team and org to ensure inter-team consistency
Flying
- Designer is permanent part of a cross-functional team and within the team’s leadership group (trio)
- Designers not only have deep domain knowledge but are also familiar with relevant analytics and use these regularly in their work
- Design system being used has component parity with engineering, ensuring designers and engineers are on the same page when it comes to presentation layer discussions
- The designs produced across all teams are aligned with a higher-level product or corporate vision and actively help progress towards it
Design Ops
Crawling
- Designers operate as individuals
- Tooling left to choice of individual designers
- No reusable patterns or standards
- All designers play same role
Walking
- Designers organised as a team and practise regular team-level activities
- Tooling decisions happen at team level
- Some elements of designs such as patterns are being reused across most design team members
- Varying seniority of designers recognised in some way
- Some level of mentorship and / or coaching is happening within design team to help lesser-experienced members grow and progress
- Basic design critiques are happening semi-regularly
- Designers attend regular one-to-ones with their person leader
Running
- Design team topology considered as a way to provide sustainability and scale for design org
- Specialisation happening within designer roles
- Design system specialist, Growth designer, Accessibility experts recognised, etc…
- Some leaders within the design team are primarily focused on practice management and design team maturity
- A management layer is formed
- Design system production and management has a dedicated team (even if it is a team of 1 person)
- Design system is in place and in regular use by most designers
- Secondary missions such as improving accessibility are adopted with support of org leadership
- Design leadership always have one eye on the future and consistently look for new tools and practices that can be adopted
- Design tooling and processes are subject to regular reviews
- Organised repository of all previous designs produced by team is available to all team members as a reference library
Flying
- Devolved and delegated ownership of design practice to senior designers and design leaders
- As designers grow in maturity, they’re encouraged to take ownership of aspects of the design team’s practice
- Design team competencies mapped for each level of designer and are used for performance management
- Designers can see their individual progression paths
- Goal setting is a regular activity and is part of short-term and long-term performance management
- Design system(s) are actively managed with a backcatalogue of work planned
Use design tokens, variables and themes to support a broad range of contexts- This tokenisation is repeated in the coding of components
- Design system analytics are used to measure how the design system(s) in place are being used
- Secondary missions such as improving accessibility are championed at each stage of the design and engineering process
- Members of design team experiment with cutting edge tools then coach other members of design team to improve their individual design process
- Design ops maturity is tracked and considered alongside product ops and dev ops
Discovery
Crawling
- No user research is the normal way of operating
- User research is only done sporadically
- Utilising one off short-form research techniques such as interviews or surveys
- Designers are mostly focused on interaction design and visual design
- No measurement of design effectiveness post-release
- Basic user research tooling is in place such as a survey tool
- Recruiting for user research is a manual task
Walking
- Discovery is done regularly but still on a ‘as needs’ basis
- A broader range of discovery techniques is in use
- For example, usability tests, short-form / single question surveys, long-form surveys, user-centred codesign workshops / interviews, 5 second tests, first click tests, card sorts and tree jacking
- The design team has a basic understanding when to use each discovery technique
- User research incentives are used to attract participants
- Though budget is often only granted on a “as needed” ad hoc basis
- A basic form of discovery insights repository is in place such as a confluence space or wiki site
A set of basic personas and / or user segmentation data exists and is used as a baseline for user behaviour
Research ops is managed by the teams conducting the research
More advanced recruitment tooling is in place such as the ability to create user segments for research
It’s also possible to recruit non-customers
Panel-based testing is also utilised for quick turnaround of simple tests
Tooling is in place to help facilitate a broad range of discovery techniques both moderated and unmoderated
Customer journeys across product space are mapped and catalogued
Designers have regular updates from the customer service team (if they exist) on current common issues customers struggle with
Running
- An always-on discovery cadence is in place ensuring that all teams have access to users on a regular and predictable basis
- Teams can organise their own discovery on top of this
- Teams’ frequency of conducting discovery activities is tracked with a goal of one form of user-facing discovery per week or more
- A permanent research ops capability is in place
- Utilising annually assigned budgets
- Centralised where possible to reduce cost of research to individual teams
- Tooling choice is also centralised
- Designers are trained on a broad range of user research activities and are also trained on a comprehensive process for research design
- Across both qual & quant techniques
- Utilising both single activities and multiple activities for triangulation
- Covering both cross-sectional and longitudinal techniques
- Instrumentation for all released code is the norm
- Allowing the changes caused by new designs to be measured
- Analysis of the data from discovery activities utilises AI as a copilot for deeper analysis and validation of observations
- Discovery insights are housed in a way that makes interacting with them as simple as possible
- AI is utilised to provide the ability for any members of the org to have ‘a dialog’ with the discovery insights, helping them explore and get value from the dat
- Recruitment for discovery activities is automated where possible allowing potential participants to show interest in research and book themselves into activities
- All customer journeys are mapped and instrumented
Flying
- Teams are able to plan and facilitate multiple rounds of discovery at the same time utilising the complete range of discovery techniques
- From quick qual techniques where prior knowledge and confidence is low through to robust quant tests for final validation before productionising
- All teams routinely conduct customer-facing research at a minimum of one cycle per week
- Customer journey maps are overlaid with problems, opportunities and analytics data
- Multiple forms of research are regularly aggregated to pull together a comprehensive view of all major issues users are currently facing
- For example NPS, customer service logs and CSAT
- Research insights are distributed utilising a push medium such as podcasts or RSS allowing org members to subscribe to updates
- Discovery / Research specialists exist within the design team…
- To undertake larger or more generative research programs
- To undertake research that helps inform long-term visions
- To coach and build capability
- Discovery insights are shared with the org’s senior leadership team to help inform their perspective of how well the org is meeting the needs of its customers
Design Strategy
Crawling
- No consideration is given to measuring the value the org delivers for its customers
- Designers have little to no domain knowledge
- Designers are assigned to projects then returned to the pool when the project finishes
- Strong focus on quick execution of design tasks rather than questioning the validity of the mission
- No appetite or ability to measure the change caused by any design work
Walking
- Designer have good domain knowledge and are aware of the main issues facing the customers
- There is a shared awareness of what the more common or higher impact issues facing the customers are
- Designs are validated through user research before being productionised
- Designers lead the visioning capability for the org
- This may be helping develop a corporate vision
- Or developing a product vision
- Instrumentation is a normal consideration for any shipped feature
- Allowing tracking of user behaviour through newly designed and shipped features
Running
- An agreed product vision exists and is used to communicate future direction of product / org
- Product vision informs the product strategy which details how aspects of the vision will be delivered
- Teams are focused on the most impactful opportunities for their customers
- Known baselines exist for user behaviour and conversion rates regarding the highest value customer goals
- Allowing teams to track improvements when new features or optimisations are shipped
- This can then be translated into leading product metrics such as engagement, activation or retention
- Design leaders are a recognised part of the senior leadership team
Flying
- Product health metrics exist
- Informed by research
- Derived from measurable performance
- Aligned to main value customers get from using product(s)
- Connected to lagging business metrics
- Product health metrics form baseline for any changes made
- Effectiveness of any design introduced is measured in terms of changes to product health metrics
- Ability to craft impact statements for any given team or individual designer
- Impact statements used in performance management of designers
- Insights discovered through discovery are valued and influence product strategy and mission of teams
- The org strives to deliver well designed features and there is a recognised standard (not just within the design team) for what level of design quality is acceptable
- Ability to speak to ROI of design
- Expressed in terms of improvements to product health metrics
Measuring design team maturity
Every designer is different, they have their inherent strengths and weaknesses with each at a unique point in their career. Within a team of designers you will always find those whose practice and process is a little more polished and those who are still finding their feet. So how do you measure the collective maturity of a team?
My recommendation is to focus on the doing, what activities are being conducted regularly by most of the team? Maturity isn’t about what books you’ve read or what training courses a designer has been on, for me it’s the measure of the day-to-day activities.
For example, take a week, any week and review the activities of all the designers; what discovery activities are being performed, what analysis is being conducted, how are designs being created, are designers involved in the discussions for where to focus, what tooling is being used, what effort is being spent on supporting systems like design systems? Once you’ve got a feel for the activity, consider whether this is a typical week, consider other weeks, is the activity roughly similar?
It can be difficult to be objective as you naturally want to celebrate the achievements your team has achieved but it’s important to carefully consider what activities are being undertaken by whom. This will also help identify not just where you are on the maturity scale but what are the areas that need most attention.
Improving design team maturity
Using the above signs and symptoms across the four pillars, you should be able to get a feel for where the team you’re a member / leader of sits. It’s important to state that there should be no shame or pride for where your team sits in terms of maturity. Every team is unique. Each team has its unique strengths and challenges and works within an org that is similarly unique.
But, as unique as each team is, there are common strategies that can be employed to help increase design maturity. Whilst I was researching this article I spoke to over a dozen design leaders from all over the world and I heard the same things again and again. I’ve pulled their thoughts and comments together in this section…
Building the foundations
Before farmers plant their crops, they first make sure the soil is ready to support the crops they’re about to sow. Similarly, before we embark on the mission to improve our team’s design maturity, first let’s get the foundations sorted.
Focus on team culture
One of my favourite quotes from the chats I had preparing for this article came from an old mate of mine Dave Crawford, “Designers the world over are trauma bonded.” Being a great designer is hard! You’ll often feel like the only person pushing for quality or the lone voice arguing against yet another compromise. But being within a design team gives a designer the fellowship and support they need to keep doing what is often a very challenging role. As a leader it’s crucial to spend some of your energies focusing on your team’s culture. What are those moments that matter for your team members? How do you make them better for your designers? What are the behaviours you need to model? I probably don’t need to state this as you’re here, reading this article but you have to care! Get to know your design team members, encourage them to share their hopes and ambitions, use this as the fuel to drive your efforts to improve your team’s maturity.
Grow your network
Leadership can be lonely! Find others in similar roles to chat with and share ideas. If this is outside of your comfort zone (like it is for me) then you’ll need to push yourself. You’ll be able to talk through issues and challenges you're facing, help others with similar challenges and validate (and invalidate) your perspective.
Be an open minded life-long learner
If reading is your thing, then read, if podcasts are your bag then listen but get amongst it. The design industry is constantly changing and it can change quickly sometimes so keeping up to date on what good looks like is on you.
Moving from crawling to walking
Moving from crawling to walking is an exciting time for any design team. But it won’t happen by chance. It’s important that someone or a small team is given the ownership of the improvement process and they then have the capacity to think and plan. This phase of growth is where the team’s structure and practice really begin to solidify. Suggested areas to focus on are:
- Start acting like a team by introducing regular team activities such as design critiques and team meetings
- Focus on consistency
- Centralise tooling choices
- Review the design process of each designer and try to introduce common ways of working
- Build context
- Help designers learn about the space they’re designing within
- Conduct foundational user research
- This does not have to a regular occurrence yet, we’re just focusing on building the designers’ domain knowledge
- Interviews are great for hearing users’ stories
- Even better are JTBD style interviews where you really get into the nitty-gritty of the users’ world
- Map the common / high-traffic user journeys
- This is can be quick and basic to start with
- Get alignment on the happy flows, the error states and the variant flows
- Align on the major user challenges
- Design patterns
- Build a library of commonly used design patterns
- This can just be copied from existing designs
- Ensure all the designers have access to this library
- If you’re genuinely starting from nothing, consider purchasing a design system off the shelf.
- This can be a great way to accelerate your UI maturity
- Coach on hard discovery and design skills
- Identify experienced practitioners within the team for aspects of design practice such as discovery, UI design, documentation and analysis of data & analytics
- Work with the experienced practitioners to plan how they might be able to coach and build up the lesser-experienced team members
- Don’t assume this is all on your shoulders, delegate where you can
- Plan for future scalability
- Educate senior leaders within the org on the benefits of introducing a design system
- For now it doesn’t matter whether this is bought or built
- Build up an understanding of who within the org is conducting user research, what are they doing, what budgets are they using
- Work with senior leaders to try and procure budget for regular user research & discovery
- Reduce the risk of flawed designs being shipped
- Try to build the habit of testing designs before they ship
- This can range from super quick hallway testing to formal usability testing
- Work with designers to try and ensure that all designs are reviewed before they are shipped
- Aim to have all designs reviewed by at least one designer other than the author, a design leader ideally
- Introduce engineering walkthroughs where engineers are walked along the designed journey and are encouraged to ask questions and raise potential issues
- Try to build the habit of predicting what will happen when a design is shipped
- How will users behave?
- Are there any expected bottlenecks?
- These predictions help you refine your understanding of what the users’ want and your domain knowledge for what works with your users
- They also help make sure instrumentation is set up correctly
Moving from walking to running
If you’re looking to move from walking to running then it means you already have a pretty good design team who is already producing good quality design work. Getting a design team to consistently perform at the running level is hard and can take multiple years but achieving this means you will have a demonstrably high-performing team. By this stage you probably know the areas your team needs to focus on but here are a few suggestions:
- Build deeper domain knowledge
- Help all designers to conduct regular discovery work in their area
- Ensure all designers are trained on a wide range of quant and qual research techniques
- And they know what techniques should be used when
- Try to utilise a variety of discovery techniques rather than over-indexing on one or two
- If you’ve managed to procure regular user research budget, use this to incentivise participants to take part
- Hopefully your product strategy and team topology are fairly stable meaning designers can focus on a consistent part(s) of your product landscape for at least a couple of quarters so they have time to build up their ‘product sense’
- Product sense is a mix of domain knowledge and creativity, ie. Designers know the area and they have a good idea on how to improve it
- Shifting from an on-demand to an always-on schedule for discovery process will help all designers get to know their areas at a deeper level
- Centralise the Research Ops function to reduce the burden on individual designers
- This means having someone responsible for Research Ops.
- In the short to medium-term this can be you but if your team scales then this should be a dedicated person
- Now the excuse of not having capacity in individual teams for discovery has been removed, you can set targets and start measuring teams on the quantity and quality of their discovery work
- Encourage and facilitate teams routinely sharing their discovery insights with the wider org
- Create a central insight repository and aggregate all research conducted across the teams ensuring they routinely submit their discovery insights into the repository
- Create regular ceremonies and updates for sharing insights with the org
- You could partner with other research producing functions in the org to create a research guild
- Your design system needs an owner, if that’s you then that’s ok but it will need a lot of time and energy applied to it (assuming you’re building one not buying one). If you can give sufficient time then great, if not, you’ll need to find someone who can
- Your design system component library will need to be actively managed and maintained to ensure it’s fit for use and relevant for your designers
- Your design system will need to be documented properly so designers and engineers know how to use it
- Your design systems lead will need to work with engineering leadership to help organise how the design system components are built out in code, ensuring the developed components match the design components’ functionality
- If possible, design system analytics should be utilised to help understand and grow adoption both by designers and engineers
- Work with engineering leadership to ensure that instrumentation for all customer journeys is set up
- All teams should follow a consistent approach for this and use a common technology
- Once event data is centralised, visualisations such as dashboards and funnel diagrams can be consistently used for decision making and prioritisation
- This is large piece of work and can it can take years just to achieve this
- Try to ensure all designers follow a consistent process
- There may be individual designers who have specialised ways of working, this is fine, we’re not trying to force standardisation
- Consistency is a key ingredient to scale
- If a designer wins lotto and disappears then their team shouldn’t have to relearn the design process of their replacement
- Have process champions for different parts of your overall discovery & design process
- Delegate ownership of these areas to your champions
- Make them accountable for uplifting the rest of the team for these areas
- Encourage them to spend time away from the BAU of design to focus on practice improvements
- Your team structure & processes should be optimised for helping designers grow and consistently delivering good quality design work
- How big your design team is and how senior its members are is normally dictated by the needs and budgets of the organisation but each designer’s role within the team is something more in your control
- It really helps to define the expected competencies for each level of designer (junior, mid-level, senior, lead, principal, team lead, etc…)
- This way, when you’re hiring for a role, you can build into the new role the level of team responsibilities you need, meaning you’re more likely to hire people who fit your team’s model
- Hiring is the single most important task of a design leader
- Try to ensure you know the career goals of every member of your design team
- This way you can better coach them or partner them with other team members with similar interests
- As designers grow, encourage them to coach the less experienced team members
- Try to spread out the task of person leadership
- It’s normal at the start to have a flat team structure but no one team member should have more than 6 or 7 direct reports, including you
- As your team scales, encourage senior individual contributors to consider person leadership
- This helps ensure all team members get more focused coaching and mentoring
- Does a product vision exist? If so, encourage your Design leaders to get involved with the next iteration. If one does not exist then you should propose creating one.
- Work with Product leaders and the org’s senior leadership team to produce a product vision
- This acts as a guiding light helping to drive alignment on strategic elements such as product strategy and technical direction
- This vision can take the form of a video, a presentation or simply a story
- It should illustrate how users will get value from the product and how they interact with it
- It should be future facing, 5-10 years into the future is the normal but some businesses go further into the future or limit their vision to 3 - 5 years, it’s really dependant on the org’s culture
- It should be descriptive enough for the story to really strong but abstract enough so that the detail is still to be defined
- Having a strong product vision helps design maturity for many reasons
- It boosts the profile of design within the org
- It amplifies the influence design has at the most senior level of the org
- It inspires the design team members and gives them something to work towards
Moving from running to flying
Creating a design team where most members are operating at the running level is a massive achievement and one some teams never achieve. If you’re at this level then your team is already a high-performing team. Remember that with any period of growth or transitional, the more progress that is made, the harder it becomes to make further progress and the more energy it will take just to maintain the standard your at. By this point you’re almost certainly a full time leader and hopefully you also have a number of senior individual contributors and person leaders who help lead and guide the Design team. I know that I can only focus on a few areas at a time, so to consistently uplift my team and a whole practice I needed to divide and conquer.
It’s really important to delegate and relinquish control to up-and-coming design leaders. This encourages them to take ownership of the team’s practice and processes. Help them to carve time away from the daily BAU design tasks to focus on both their own and the team’s growth. This helps build them as leaders and helps your team’s practice grow.
As with the previous stages, each design team is different and has its unique strengths and weaknesses. You probably know these off by heart and are actively working on them but here are a few common issues that teams at this level could focus on:
- By now the design process for all designers is known and understood and there is a common model for what good looks like
- Designers should be empowered to customise this model to fit the context of their work and their team
- Encourage designers to experiment with new tools and techniques and try new things out and learn, then share these learnings are shared with the team
- Especially encourage them to play with AI tools to find ways of driving more efficient design practices
- Hopefully, designers are routinely sharing their discovery insights and influencing roadmaps and prioritisation
- If any designers are struggling with this then offer them coaching to help them grow their ability to influence the work they conduct
- Encourage designers to work with their product managers / owners to visualise their team’s opportunity space by mapping all the customer journeys and overlaying these maps with their discovery insights and user behaviour / analytics data
- This helps contextualise the generated insights and build a shared ‘bigger picture’ of the opportunity space allowing for a more relative form of decision making, comparing the potential value of multiple opportunities rather than focusing on just one.
- Hopefully by now designers are able to work with engineers to progress developments quickly partly due to the maturity of the design system and the parity achieved with engineering components
- This means there should hopefully be fewer issues and more time for refinement and polishes to be applied to the user experience
- Encourage designers to ‘be fussy’ about the experiences they’re delivering
- It should hopefully mean there is capacity for moments of richness such as a nice micro-interaction or greater focus on accessibility
- By this stage your design system(s) should be fairly mature and in regular use
If you have not already, you should investigate using design tokens to control various aspects of your design system(s)- And then use these to create themes
- Themes can then be used to produce variant experiences such as dark-mode
- Your design systems lead and their engineering counterpart should be working on optimising the engineering components to have accessibility baked in
- This helps make their code more readable by adaptive technologies such as screen readers
- If you’re working on mobile apps, this will also lessen the work required to integrate into OS level accessibility features
- With the basics covered, you should now have time to focus on enriching the design team’s work and practices
- Make accessible design the normal
- Provide accessibility training to make sure everyone knows how to design and annotate accessible experiences
- Work with engineering leadership to ensure design system components are semantically correct with accessibility baked in
- Build out an experimentation practice to help designers learn how to think about and design experiments
- Your experimentation practice is a sub-section of your discovery practice
Encourage designers to become confident playing with data and analytics - Growth design is a valuable specialism, if any designers have a passion for experimentation encourage them to learn and grow in this area
- Work with Marketing and Brand to ensure alignment between their visual design language and your design system
- Work with Product leadership to develop a set of product health metrics
- These can be quant in nature and based on usage analytics
- Or they can be qual in nature and be based on user research
- Or a combination of the two
- Product health metrics can be used to illustrate a number of queries
- Is our product strategy working?
- Do we have enough engagement to drive the product outcomes we’re looking to achieve?
- How quickly is the product maturing
- But, importantly for a design team they can be used to better understand the impact of the design work being produced
- For example if product health metrics are routinely measured then it will be possible to do a before and after analysis for any work that is shipped
- Meaning the delta is the measure of the impact generated
- Ideally this could then be translated into product or business metrics
- And give a real value for the ROI of design
- One of the key aspects of building a design team capable of scaling is to ensure a growth mindset is within the culture of the team
- By now, you’ve probably seen designs grow from juniors into seniors and even into principals and team leads
- All of your senior designers need to be capable of coaching and growing lesser-experienced designers
- Encourage them to have mentors outside of the org
- Buy them books on coaching
- Train them on how to be a great coach
- Consistent, ongoing coaching and the ability to grow designers are key health indicators for the design team
- You should be measuring and tracking design team members against competency matrices to ensure everyone is measured against the same standard
- This does also mean learning to deal with under-performing designers
- Good managers act. You need to ensure you have sufficient capacity to actively manage the collective capability of the design team
- Work with the org’s senior leadership team to better understand their expectations for the Design team
- Get them to define what good looks like for a designer and a design team
- As your design team’s maturity has grown and the quantity and quality of the design work undertaken has grown, hopefully your Org’s expectations for design quality have similarly grown.
- It really helps to share designs for new features in activities such as team or function showcases
- Work with senior leaders closely to understand how they view your products
- Encourage them to be fussy about good design
- Are there areas in need of refinement?
- How can you work with teams to deliver these refinements?
- You must know your product and its auxiliary pieces intimately
- This is how you grow appreciation for the design function and ensure good design is a key part of your org’s culture
- This is a slow process and can take years to establish
- It’s worth it though as when everyone has high standards then the frequency of designers being asked to cut corners by roles such as product managers and engineers will hopefully reduce
- Don’t worry, your product(s) will never be perfect, there will always be old, crusty and broken bits as it's unlikely you have the design and engineering capacity to consistently maintain everything, all the time.
Maintenance
Unfortunately, achieving a level of design team maturity against one or all of the four pillars is not as simple as just implementing the recommended steps in this article. Our world and the world of designers is constantly changing and the pace of change can sometimes feel like it’s accelerating. As I mentioned earlier, it’s on you as a design leader to stay up to date; go to meet ups, listen to podcasts, read books, talk to your team and your peers. Part of your role as a leader is to stay up to date on new developments, practices and technologies that could help your team. As technologies like AI become prevalent there is a continual shift in expectations to be able to do more and better work meaning what was once seen as mature is no longer and a new bar is set.
This article was written (very slowly) between September and November 2025 so the maturity scale described here is current only for this time period. As new technologies arrive, it will begin to age and become outdated so I challenge you to maintain your own scale, keep it up to date and share it with your peers and network to help us all stay up to date.
Wrap up
This article all started from a simple LinkedIn post. That post resulted in me talking to design leaders from all over the world. I’ve had so many great chats over zoom or coffee and even some great Japanese food (thanks Jacalin). Thank you to everyone I spoke to, genuinely I learned from every conversation. I was blown away by how generous people were with their time and how willing they were to share their expertise. From these conversations I’ve been able to get a much deeper understanding of where the team I lead sits in terms of design team maturity and how we can improve.
I hope you found this article useful and inspiring. Whether you agree with the scales and the suggested actions or not, I’d love to hear from you and have more inspiring conversations. Please feel free to reach out, I love to chat.