The tools are changing, customer expectations are moving and the responsibilities of designers are developing almost weekly. But while artificial intelligence is transforming how creative work gets done, I believe the difference between an average design team and an exceptional one still comes down to something rather more human: the quality of its leadership, the environment it creates and the way its people are encouraged to think.
I can remember a time when the responsibilities of a design leader were relatively straightforward to explain. You brought together talented people, established a creative direction, maintained standards and made sure the work was delivered properly. There were disagreements about priorities, the occasional difficult stakeholder and the familiar challenge of finding enough time to do everything well, but the tools and processes were generally predictable. Software improved, new methods emerged and expectations developed, usually at a pace that gave teams an opportunity to learn and adjust. Looking at the profession in 2026, that feels like a rather distant arrangement. A design team can begin the week working in a particular way and discover something by Friday that fundamentally changes how a task might be approached. Product managers are building sophisticated prototypes, developers are becoming more involved in design decisions and designers are finding themselves able to work much closer to implementation than ever before. Meanwhile, customers are becoming accustomed to increasingly capable digital experiences, and businesses are understandably asking what all these new possibilities should mean for delivery times, budgets and the quality of the work being produced.
It's an exciting period to be involved in design, particularly if you enjoy learning. It's also a demanding time to be responsible for other people's performance, confidence and professional development. I've spent a considerable part of my career working across digital product design, creative direction and leadership, and one thing I've become increasingly convinced of is that the quality of a design team cannot be judged simply by the talent of the individuals within it. You can employ some excellent designers, provide them with sophisticated software and establish an impressive collection of processes, yet still end up with a team that rarely produces anything particularly ambitious. The work gets completed, the delivery meetings are reassuringly busy and the project boards show a healthy number of finished tasks, but there's very little evidence that the organisation is becoming better at understanding its customers or solving meaningful problems.
What interests me is why some teams manage to achieve so much more with similar resources. They seem better at recognising opportunities, more comfortable challenging assumptions and more capable of producing work that feels intelligent rather than simply well executed. Their people understand what they're trying to achieve, have confidence in their own judgement and know when they should involve somebody with a different perspective. There's usually a sense that the team is learning as it works, and that individual designers are becoming better at their profession rather than merely more efficient at completing assignments.
I don't think artificial intelligence changes the importance of those qualities. If anything, it makes them considerably more valuable. When producing an attractive interface, a functioning prototype or a convincing presentation becomes easier, the ability to recognise whether it's appropriate becomes a more important distinction. That's a challenge for designers, certainly, but I think it's an even bigger challenge for the people responsible for leading them.
Creating the conditions for better work
One of the most useful things a head of design can do is examine the environment in which their team is expected to operate. It sounds obvious, but it's remarkably easy to become absorbed in the quality of individual projects while overlooking the circumstances producing them. A team might have excellent designers who rarely have enough uninterrupted time to develop an idea. Another might be full of enthusiastic people whose suggestions are regularly overridden by more senior stakeholders. Some become so efficient at responding to requests that they gradually stop questioning whether those requests address the right problems in the first place. From the outside, all three might appear perfectly productive, and the difficulties may not become apparent until a product underperforms, the same design problems keep returning or the strongest members of the team begin looking for opportunities elsewhere.
I've always thought that managing creative people requires an appreciation of how differently they work and what they need from the person leading them. Some designers are extraordinarily good at developing ideas through conversation, while others do their best thinking when they've had time to explore a problem independently. There are people who thrive on the energy of a collaborative workshop and others who find themselves exhausted by a day of meetings that leaves them with very little opportunity to actually design anything. Neither approach is inherently better, and one of the responsibilities of a manager is to create an environment that recognises those differences without losing the benefits of working together.
Attention is an important resource, and we don't always manage it particularly well. A calendar filled with status meetings, project updates and requests for immediate feedback can leave designers attempting to complete their most demanding work in whatever gaps remain. I've never been convinced that the amount of time somebody spends in meetings is a reliable indication of their contribution to a project, and I would much rather establish clear communication, give people appropriate responsibility and protect meaningful periods of working time. That doesn't mean encouraging designers to disappear for days without speaking to anybody. Collaboration is fundamental to good product development, but it should serve a purpose rather than become something people participate in simply because the meeting exists.
There is also a difficult question about what organisations choose to reward. Are we recognising the quality of somebody's thinking, or are we rewarding them for appearing permanently busy? The distinction becomes particularly interesting when we introduce AI into the working day. If an approved tool allows a designer to review a substantial amount of research material in an hour rather than spending an entire afternoon on it, the immediate temptation is to fill the remaining time with more tasks. That may be commercially sensible in certain circumstances, but if every efficiency improvement results in a greater volume of work, we're missing an opportunity to improve the quality of what the team produces. We may simply end up with people working at a higher speed while experiencing exactly the same pressure.
I'd like to see managers become much more deliberate about how that recovered time is used. Some of it should improve delivery, reduce unnecessary costs and help the business respond more efficiently. But some could be reinvested in the things that are so often neglected because everybody is too busy: understanding customers in greater depth, exploring alternative approaches, improving existing products, developing junior designers and addressing problems that have been allowed to accumulate over several years. The opportunity isn't simply to produce more work with fewer hours. It's to give talented people a better opportunity to do the kind of thinking that genuinely improves the business.
This also raises the question of how much control a manager should exercise. Too much creates a team that becomes dependent on approval, where every significant decision moves upwards and designers begin anticipating what their manager would prefer rather than developing their own judgement. Too little can be equally frustrating, particularly when people spend weeks exploring ideas without understanding the commercial constraints or the expectations of other stakeholders. I think the strongest approach is to provide clarity about the problem, the outcome and the responsibilities involved, while allowing designers meaningful ownership of how they arrive at a solution.
A good design leader should be comfortable with the possibility that somebody in their team might produce a better idea than the one they had in mind. In fact, I'd hope that happens regularly. Otherwise, I'm not entirely sure what the point of bringing talented people together would be.
Using AI to become more intelligent about customers
Of all the opportunities artificial intelligence presents for design teams, I'm increasingly interested in the ones that have relatively little to do with generating designs. The ability to produce interfaces, imagery and working prototypes is impressive, but I suspect some of the most valuable applications will involve helping teams understand information that has previously been too difficult or time-consuming to examine properly.
Most established digital products generate an extraordinary amount of data. There are analytics, customer support conversations, usability studies, interviews, survey responses, operational reports and observations from the people dealing directly with customers. Each source provides a different perspective, but bringing them together in a meaningful way can be complicated, particularly when the information is spread across departments and systems. Research teams may have valuable observations that product managers haven't seen, while customer support colleagues are dealing with recurring frustrations that designers only hear about when something becomes a significant problem. Meanwhile, the analytics can tell an entirely different story, or at least one that appears different until somebody spends enough time understanding the circumstances behind it.
Reviewing that material properly takes considerable effort. Somebody has to work through transcripts, identify recurring themes, compare findings, investigate unusual patterns and prepare something the wider team can use. By the time the information has been organised into a useful report, the business may already have moved on to another priority. Because the process is so demanding, customer understanding can become an occasional research activity rather than something that informs everyday decisions.
This is where I think AI has the potential to make an enormous contribution, provided we're sensible about how we use it. With appropriate permissions and safeguards, it can assist with organising research material, identifying possible themes, comparing feedback across different sources and helping designers investigate information that would otherwise take days to review. It might identify a recurring complaint in customer support conversations, highlight unusual behaviour within a particular group of users or reveal a question that deserves closer examination. The designer can then return to the original evidence, investigate the context and determine whether the apparent pattern is meaningful.
The important distinction is that the technology should help us discover things worth understanding, rather than become an authority that tells us what customers think.
Imagine a product team investigating why customers are struggling to complete a particular journey. The analytics suggest that a significant number of people are leaving at one stage, support conversations contain complaints about the process and recent interviews reveal frustration with certain aspects of the experience. An AI-assisted review might help organise these signals and identify common themes, but those similarities could be misleading if nobody examines the detail. Perhaps the analytics problem is concentrated among new users, while most of the support complaints come from people who have used the product for years. Perhaps an apparent increase in frustration reflects a change in the way complaints are categorised. The team still needs to understand where the information originated, whether it represents the wider customer base and what alternative explanations might account for the findings.
I would love to see more design teams make customer intelligence a regular part of their working week. Rather than waiting for a substantial research project to produce a formal presentation, the team could spend a short period examining what has changed in customer behaviour, support feedback or product performance since its previous review. The conversation would be about what the new information might mean for the work already underway, rather than simply reporting another collection of statistics. AI could assist with preparing the material, but the discussion would belong to the people responsible for interpreting it and deciding what, if anything, should happen next.
One practical discipline I'd encourage is making a clear distinction between what the evidence actually shows, what the team believes it means and what remains unknown. Those three things have an unfortunate habit of becoming mixed together, particularly when a persuasive presentation makes an assumption sound like an established fact. A dashboard might show that a feature is being used less frequently than expected, but that doesn't automatically establish that customers dislike it. A small group of interview participants might respond enthusiastically to an idea, but that doesn't mean the wider audience will behave in the same way. When the distinction is made explicit, teams are more likely to ask useful questions and less likely to design around assumptions that have gradually acquired the appearance of certainty.
I'd also encourage designers to actively look for evidence that challenges their preferred interpretation. It's a surprisingly difficult habit to develop, especially when a team has already invested considerable effort in an idea. Asking what might prove us wrong can feel uncomfortable, but it often reveals the gaps that deserve attention before decisions become expensive. AI can be useful here too, helping suggest alternative explanations or identify questions the team hasn't explored, although its suggestions must always be checked against reliable material. The aim is to develop better judgement, not to create the impression that a confident automated summary is equivalent to a properly understood body of research.
For a design leader, the opportunity is compelling. Less time spent assembling information could mean more time understanding customers, recognising opportunities and making decisions based on a clearer picture of what's happening. It also gives designers the chance to contribute more meaningfully to conversations with product managers, engineers and commercial stakeholders, because they arrive with evidence and informed questions rather than relying primarily on personal preferences.
I find that a considerably more interesting prospect than simply asking AI to produce another collection of homepage concepts.
Nurturing creativity and developing the next generation
One of the responsibilities of creative leadership that rarely receives enough attention is helping people develop the confidence to have an opinion. Design is full of decisions that don't have an immediately obvious right answer, and people need to become comfortable exploring possibilities, explaining their reasoning and changing direction when better information becomes available. That confidence is difficult to develop in an environment where every review becomes a judgement on whether somebody has managed to satisfy the preferences of the most senior designer in the room.
I've never been particularly interested in the idea that a head of design should have the strongest opinion on every subject. Sometimes the most useful thing a manager can do is ask a question that helps somebody else recognise a problem or develop an idea further. If I immediately announce which concept I prefer, there's a danger that the rest of the discussion becomes an exercise in agreeing, disagreeing politely or producing evidence to justify a direction I've already chosen. I'd much rather give people an opportunity to form their own view first, particularly when reviewing work that involves several disciplines. Asking everyone to note their initial observations before the discussion begins can be a surprisingly effective way of making sure less confident voices have an opportunity to contribute.
There is a difference between maintaining high creative standards and making people afraid of criticism. I want designers to feel comfortable presenting work that isn't fully resolved, because some of the most useful conversations happen before an idea becomes too developed to change. I also want them to understand that feedback should be specific, constructive and connected to the objectives of the work. If something isn't good enough, we should be able to explain why and help identify what would improve it. Avoiding difficult conversations doesn't create a healthy team, but neither does delivering criticism in a way that makes people reluctant to share their thinking.
The distinction becomes particularly important when a team includes designers at different stages of their careers. Experienced people have the benefit of having seen similar problems develop over time, including the consequences of decisions that initially appeared perfectly sensible. Less experienced designers can bring fresh perspectives, different influences and a willingness to experiment with approaches that more established colleagues might overlook. There is considerable value in bringing those perspectives together, provided the relationship is one of mutual respect rather than a simple transfer of instructions from senior to junior.
AI introduces another complication into that relationship. A relatively inexperienced designer can now generate sophisticated layouts, working prototypes or research summaries without necessarily understanding all the decisions behind them. That can be an excellent way to experiment, but it also raises questions about how people develop the underlying skills they need to become genuinely accomplished designers. Much of what we learn comes from doing something ourselves, getting it wrong, examining the result and gradually recognising why one approach works better than another. If software removes every difficult or repetitive stage of the process, we need to think carefully about which learning opportunities might disappear with it.
I wouldn't respond by preventing junior designers from using modern tools. That would leave them poorly prepared for the profession they're entering, and there's little sense in insisting somebody spend hours on a task simply because that's how their manager learned to do it. Instead, I'd become more deliberate about what we expect people to understand. If a designer produces an excellent interface using AI assistance, I want them to explain why the information hierarchy works, what alternatives they rejected and how they know the proposed experience is appropriate for the customer. If they've used generated code to create a prototype, they should understand what it does, where its limitations lie and when a developer needs to become involved.
I think there's a useful opportunity to change the nature of design reviews and one-to-one conversations. Rather than concentrating entirely on the finished result, spend time exploring the decisions behind it. What changed your mind during the project? Which part of the problem did you find most difficult? What evidence made you confident about your recommendation? If you had another day to investigate something, where would you spend it? These questions reveal a great deal about how somebody thinks and provide a more meaningful basis for professional development than simply judging how polished their final presentation looks.
I'd also like to see more opportunities for designers to work together on unfamiliar problems, rather than always assigning tasks according to seniority or existing expertise. A senior designer might recognise weaknesses in a customer journey that a younger colleague hasn't encountered before, while that colleague may introduce a faster or more interesting way to explore possible solutions. Both learn something, and the organisation benefits from knowledge being shared across the team rather than remaining with a handful of experienced individuals.
There is an important lesson for recruitment here as well. A convincing portfolio still matters, but I would increasingly want to understand how somebody arrived at the work they're showing. Can they explain the problem? Do they understand the compromises involved? Are they comfortable acknowledging what didn't work? How do they respond when somebody challenges their thinking? With sophisticated production tools becoming more accessible, the quality of the finished presentation tells us less about the depth of understanding behind it than it once might have done.
Ultimately, I think great design leaders should be judged partly by the people they help develop. If members of the team are becoming more capable, more confident and better able to exercise their own judgement, that's an indication that the environment is working. A manager who needs to remain personally involved in every significant decision may feel indispensable, but I can't help thinking that the more impressive achievement is building a team that becomes increasingly capable without depending on constant intervention.
Maintaining standards while everything changes
One of the more exhausting aspects of working with AI in 2026 is the feeling that there's always another development worth investigating. A new model appears, an established product introduces another capability or somebody demonstrates a workflow that promises to transform how a particular task is completed. Some of these developments are genuinely useful, while others are interesting demonstrations with relatively little relevance to the work a team needs to deliver. The difficulty for a design leader is deciding how much attention each deserves, particularly when enthusiasm for a new tool can spread through an organisation much faster than anybody has had an opportunity to evaluate its implications.
If every new capability becomes an immediate priority, a team can spend an extraordinary amount of time experimenting without developing reliable ways of working. The opposite approach, where unfamiliar software is discouraged until every possible question has been answered, risks missing improvements that could make a meaningful difference. I think the answer is to separate the freedom to investigate from the decision to adopt something formally. Designers should have an appropriate opportunity to explore new capabilities, share useful discoveries and discuss the things that didn't work, but a convincing demonstration isn't enough reason to reorganise the working practices of an entire department.
I'd establish a regular opportunity for people to bring forward one development they believe deserves attention, with the emphasis on the problem it solves rather than the excitement of the technology itself. Does it reduce an unnecessarily laborious task? Improve access to useful information? Make it easier to test a design idea? How reliable is the output, and what responsibility does the team retain for checking it? If the answer is sufficiently promising, the next step would be a controlled evaluation using appropriate material and a clear understanding of the expected benefit. Some tools might become part of the team's standard workflow, others may remain useful for occasional exploration, and many will simply be interesting experiments that don't justify further investment.
There are practical responsibilities involved, of course. Confidential information, customer data, intellectual property, security, accessibility and the reliability of generated material all require appropriate consideration. These questions cannot be left entirely to individual enthusiasm, particularly when a design team works with sensitive commercial information or products used by large numbers of customers. The organisation needs to provide guidance that is sufficiently clear to be useful without becoming so restrictive that it prevents sensible experimentation.
I also think we need to be more attentive to the fatigue that can accompany constant technological change. People are being told repeatedly that their profession is evolving, their skills need to develop and the next major breakthrough may arrive tomorrow. Even designers who are naturally curious can begin to feel as though they're permanently behind. A good manager should help the team distinguish between developments that genuinely matter and the surrounding noise. Sometimes the most useful response to a new release is to acknowledge that it looks interesting, but that there's no immediate reason to change what everybody is doing.
There's a degree of reassurance in having somebody responsible for making those judgements. It allows designers to concentrate on developing expertise rather than feeling personally responsible for monitoring every new product announcement. I'd much rather create an environment where people are encouraged to become adaptable, curious and capable of evaluating unfamiliar tools than one where professional confidence depends on knowing the latest version of a particular piece of software.
The other complication is that the boundaries between design, development and product management are becoming less distinct. Figma's 2026 AI research suggests that participation across these disciplines is increasing, with more designers becoming involved in development and more developers contributing to design. I think that creates exciting possibilities for collaboration, but it also requires a clearer understanding of accountability. Being able to create a functioning prototype doesn't automatically mean somebody has the responsibility or expertise to approve it for production. A developer may be perfectly capable of producing an attractive interface, but the team still needs to ensure that the experience meets the appropriate standards for usability, accessibility, customer understanding and brand consistency.
The objective shouldn't be to defend professional territory or insist that certain tasks belong exclusively to particular job titles. It's to make sure the right expertise informs the decisions that matter, while giving people the freedom to contribute beyond the traditional boundaries of their discipline. That requires conversations about responsibility that are far more interesting than simply deciding who has access to which software.
Understanding whether the team is actually improving
Measuring the effectiveness of a design team has never been particularly straightforward, and I suspect AI will make some of our familiar approaches even less useful. Delivery dates, completed projects, operating costs and the speed of certain processes all provide information that a business needs to understand, but they don't tell us enough about the quality of the decisions being made. A team could produce twice as many concepts, more prototypes and an impressive quantity of documentation while achieving very little improvement in the experience of its customers.
I'd want to know whether the team is becoming better at identifying meaningful problems, understanding the evidence available and choosing approaches that produce worthwhile outcomes. That might involve customer behaviour, usability findings, service performance or commercial results, depending on the nature of the product. I'd also be interested in how effectively people collaborate, whether designers feel able to make decisions within their responsibilities and how much unnecessary rework is being created by unclear briefs or late changes in direction. These are areas where the quality of management can have a substantial influence, and they can reveal problems that aren't immediately obvious from a conventional delivery report.
One practice I think more teams could benefit from is returning to significant design decisions once they've had an opportunity to produce a result. Not as a formal exercise in establishing who was right, but as a way of comparing what the team expected to happen with what the evidence subsequently revealed. Did customers behave as anticipated? Were the important constraints understood? Did the team overlook something that now seems obvious? Would it approach a similar problem differently next time?
These discussions could produce a valuable record of collective experience, particularly if they're conducted with enough openness for people to acknowledge mistakes without feeling that their competence is being questioned. AI could help organise the information, identify recurring patterns across projects or make previous decisions easier to retrieve, but the learning still depends on people being willing to examine the results and change how they work.
I would also resist the temptation to measure AI adoption as though the number of prompts written or tools used were an indication of professional development. Usage might be useful when evaluating a particular software investment, but it says remarkably little about whether the work has improved. I'd much rather discover that a designer used an appropriate tool to reduce a repetitive task and spent the recovered time investigating a difficult customer problem than learn that everybody had achieved an arbitrary target for AI activity.
The same applies to creative productivity more generally. The most productive person in a design team isn't necessarily the one who completes the greatest number of tasks. It might be the person who identifies a problem early enough to prevent weeks of unnecessary work, who helps colleagues arrive at a better solution or who recognises that something complicated can be achieved much more simply. Those contributions can be difficult to express through conventional performance measures, but they're often enormously valuable to the organisation.
I think this is where design leaders need to become better at explaining the contribution their teams make to the wider business. Rather than presenting design primarily as a function that produces interfaces, materials or completed projects, we should be able to demonstrate how it improves decisions, supports customers and helps the organisation pursue its ambitions. Good design management connects those outcomes with the development of the people responsible for achieving them.
The responsibility of the person in charge
When I think about the design leaders I've most respected, the qualities that come to mind aren't necessarily the ones that would be most impressive on a list of technical skills. I think about people who could recognise good work, explain why it was good and help somebody make it better. People who understood the commercial realities of the business without losing their appreciation for creativity, who could work confidently with other disciplines and who were prepared to defend the importance of the customer experience when priorities became difficult.
I also think about the leaders who genuinely wanted the people around them to succeed. There is something particularly rewarding about seeing somebody develop from a designer who needs regular reassurance into a confident professional capable of making difficult decisions and helping others do the same. That development doesn't happen simply because somebody has been given increasingly complicated work. It depends on having opportunities to learn, receiving useful feedback, being trusted with responsibility and knowing that support is available when it's needed.
As design leaders, I think we sometimes underestimate how much our own behaviour influences the atmosphere of a team. People notice whether we welcome questions, whether we become defensive when challenged and how we respond when something goes wrong. They notice whether we give credit generously, whether we make time for people who need support and whether we're prepared to admit when we've changed our minds. Those behaviours establish expectations far more effectively than an elaborate set of values written into a presentation.
There will always be occasions when a team needs a clear decision and somebody prepared to take responsibility for it. At other times, the more valuable contribution is to listen, ask a better question or give somebody else the opportunity to work through an idea. Knowing which approach the situation requires is part of the judgement that comes with experience. It's also something that needs to develop as the people within the team become more capable.
In 2026, I think the responsibilities of a creative leader require an unusual combination of confidence and humility. You need enough technical curiosity to understand what new tools might make possible, enough experience to recognise their limitations and enough confidence to avoid being carried along by every development. You need to protect the time and attention required for creative thinking while accepting the commercial realities of delivering work. And perhaps most importantly, you need to be comfortable with the possibility that your team will increasingly contain people who know more than you do about particular tools, techniques and emerging disciplines.
That shouldn't be threatening. It should be one of the ambitions of good leadership.
If I were assessing the quality of a design team today, I wouldn't begin by asking how quickly it produces screens, how many AI tools its members have adopted or how full its delivery schedule appears. I'd want to understand how it thinks, how it learns and what happens when the people within it disagree. I'd be interested in how junior designers develop confidence, how experienced people share their knowledge and whether customer evidence genuinely influences decisions. I'd want to know how much opportunity there is to explore an idea that wasn't in the original plan, and how often the team discovers something that causes it to reconsider an established assumption.
I'd be particularly interested in what the team has changed its mind about recently, and why. I think the answer to that question could reveal a great deal about the quality of its leadership.
The tools will continue to change, and I suspect there will be plenty of occasions over the coming years when we find ourselves reconsidering how design work should be approached. Some aspects of the profession will become considerably easier, while others will introduce responsibilities we haven't yet fully anticipated. Customer expectations will develop alongside the technology, and businesses will understandably expect their teams to take advantage of the opportunities available.
But I don't believe the ambition for a great design team should simply be to keep up with those changes. It should be to develop a group of people who are curious enough to question familiar answers, experienced enough to recognise exceptional work and confident enough to take responsibility for their decisions. People who can use technology intelligently without losing their understanding of the customers they're designing for, and who continue to develop expertise that remains valuable as the tools evolve.
For me, the prospect of using AI to reduce labour-intensive analysis, make customer intelligence more accessible and remove unnecessary administration is genuinely exciting. If we use those capabilities well, we have an opportunity to give designers more time for the aspects of their work that require imagination, curiosity and judgement. We could also make more room for the conversations, mentoring and collaboration that allow talented people to become exceptional professionals.
And that, ultimately, is what I think separates a great design team from an average one. It's the quality of the environment we create, the way we encourage people to develop and the standards we establish together. Technology can provide remarkable tools, but it remains our responsibility to decide how those tools contribute to the work and the people doing it.
I'd much rather lead a team that produces fewer, genuinely excellent solutions than one that generates an endless supply of perfectly acceptable work.