Design Maturity is Data Maturity

What exactly is it that you do?

Now that’s a question most of us get used to answering, often when arriving in a new role and it is a great indicator of just much Design Maturity your new org has.

When it comes down my role at Shell it gets a little more complicated because when a company has a similar amount of people and resources as a small country then Design Maturity appears in pockets, across regions, across projects, across disciplines. It can go from 'Just because you have a Figma design doesn't mean your design is valid' to 'oh my god, why aren't you on the Board?' from one online meeting to the next.

So, for the record, I’m part of the Leadership Team, within Shell’s Experience Design department (the biggest design resource in Shell), responsible for Design Analytics and a big part of that is ensuring that Design Maturity is increased, not just in name but in practice.

Now, I know some of you are already muttering, "Design Analytics, not another bloody title!" and honestly, I'm right there with you. Thing is, it’s not that new and for once the title is useful. It’s something that most of us at the tactical end of this weird and wonderful industry attempt to do everyday and have done since it started out. What is new is that it has had a 'shift left' and is now strategic not just tactical and has a formal structure. Also, being totally honest, giving it a name makes adopting it as a business process far easier.

Whatever works, right?

What it comes down to is ensuring that the solution design process is driven by data, not by opinion, not by the loudest voice but by a mix of qualitative and quantitative data that can't be argued with. It ensure that everybody understands and agrees the human-shaped ‘why’ of a problem and then provides the rationale for the ‘because’ for the solution. Simple, yes? Hold on, as with most of what we do it isn’t a straightforward Yes or No, but a depends.

Mainly it depends on two things, again Design Maturity in an organisation but also the biases of decision makers.

Design Maturity Levels

Typically, I come across three levels of design maturity in business models and all of them can be defined in the way they use data.

Data Inspired Design Maturity

I’d suggest that most companies operate at this level. Customer or User data is a source of information but ultimately most business requirements and solution design come down to stakeholder choice and short-term profits. These companies recognise the data but feel free to ignore it.

These are typified by places that see little or no benefit in user research or at best see it as ‘common sense’ that can be gathered by copying what better performing competitors are doing and by dismissing any product or market analytics they don't agree with. Beware the HiPPos.

Data Informed Design Maturity

This is where I suspect most of us work. Customer or User data isn’t just a source of information it is the benchmark by which we measure and evaluate design decisions and solutions. That data, mind you, is often disconnected, user research data informing design and systems data informing development which often results in unnecessarily conflict between the disciplines, with business going with whoever has the loudest voice or what is the most 'viable' to produce.

Siloed teams and a drive for MVP is usually the core of solution design here, but viable is defined by what is the smallest step to make something usable rather than by what end users will actually find useful.

Data Driven Design Maturity

Now this is this is where most of us want to be. Customer or User data drives problem insight and solution design from a single source, correlating business needs with user needs and with technical needs. It’s where clear, validated, universally understood and accepted data informs service, product, comms, marketing, sales, operations and just about everything else that demands the why and the because for decisions come before a single design has even been thought about.

These are places where design is seen as a valuable process, not a deliverable, where understanding a problem comes long before offering a solution, where expertise is valued over personal opinion and where all decisions are backed by real data. It is the job of Design Analytics to ensure that this approach and the data to support it is in place.

Why does that matter to end users?

Because ultimately end users are the only deciding factor on whether your business survives or not. This isn’t Hollywood and Kevin Costner was wrong, just because you build it doesn’t mean they will come. Data Driven Design Maturity ensures desirable, technically sound, business effective, solution design.

The Biases Of Decision Makers

We all have biases, all of us, if we’re sensible we recognise them and try to mitigate them, but when it comes to business if those biases have had benefits, helped decision makers reach milestones, helped them get promoted, helped them get bonuses based on deliverables that require those biases, then anything that disagrees with those biases is a threat not a reality check. This is complicated further when Decision Makers have their own priorities based on specialist knowledge and see input from other areas as somehow less or misinformed or of less value. Again, there tends to be a three-way split in biased priorities.

Technical priority

We all know places where design is there to just feed the machine, to change as little as possible. If the decision maker usually just wants to hit the next arbitrary release date with something that is usable, their focus is on system data over user data (and often business data) and no one wins, because functional doesn't always equate to useful and desirable.

Design priority

We also know places where tech is stymied by design (sorry designers, you know it's true) where the demand to change established patterns for a single use case, without knowing the technical implication is a source of real conflict. If the decision maker is constantly looking to make perfect aesthetically beautiful designs regardless of cost or technical feasibility, with their focus on user data over system data and business data, no one wins, because desirable doesn't always equate to useful and functional.

Business priority

This is probably familiar too, design is treated as a noun not a verb, it isn't a process it is a deliverable whether it is a new UI, a new service design blueprint, a new flow diagram, whatever is required to illustrate decisions already made. Decisions made based on shareholder demands for profits, or client demands on time schedules, or based on budgetary constraints or worse HiPPo ego trips. Their focus is on business data over system data and user data, and no one wins, because useful doesn't always equate to usable and desirable.

Why does that matter to end users?

Because end users with a desirable, usable, and useful solution are key to success. It is only when all the three priorities listed above are mature enough to act as one, based on real data, that everyone wins.

Enter Design Analytics

Design Analytics is the bridge between all those specialisms, all those priorities, it provides the mechanisms to gather data from every aspect of business, then inform all parts of the business to identify problems and drive design solutions.

The idea is that:

• All problems are identified from the same data, so all solutions are driven by the same data.
• No problem should be informed by just business or just user research or just technical restraints, it should be informed by all of them.
• No solution designer should be blindly approached with a solution looking for a problem. Problem identification and definition always comes first and everyone is part of that discovery.
• Opinion led or siloed-priority decisions are eliminated at the strategic level, everything becomes data driven and a matter of consensus.

Design Analytics is a discovery framework leading to and informing solution design, it is agnostic to the design itself. It exists to empower design by bridging myriad sources of information and providing valid, informed, joined-up rationales for design decision making. That design may or may not be digital. It may or may not be product. It may or not be service. It may or not be operations. It does ensure that every part of the solution design process has the same why as in "Why are we doing this?" and the same because as in "Because that’s what all the data shows to be correct.”

Like I said, this isn’t new, a quick Google search will produce hundreds of Venn diagrams showing the interlocking tech, business, and design circles with UX as a sweet spot between them. Indeed, ask any UX/CX who has being doing this longer than 15 years or so and they’ll answer:

“What, joining qualitative and quantitative data to drive solutions? Been doing that forever!”

And they would be right, but what has changed is the sheer scale of the data available, and the fact that it now goes thorough business operating models not just solution design models.

As Debbie Levitt ???? is known to remark, "UCD shouldn't have a seat at the table, it should be the table." If I can mix my metaphors for a moment, that table should be made of valid data, not biased agendas or opinions, valid data that ensures decisions made benefit business and end users alike.

Design Maturity is Data Maturity

• We now live in an age of Big Data and no single person has the time or capability to deal with it all. Design Analytics empowers decision making by filtering out data that is irrelevant to the problem identification to provide data that is essential to the potential solution design.
• The isn't some esoteric process for informing creative design it is something that is operationally key to data-lead business success.
• There is a recognisable mechanism in place that ensures compliance by everybody involved. No research? No verified and valid data? No way forward.
• The idea of someone saying "I think this is a great idea, let's do it," is replaced by "I think this is a great idea, how do we check if it is?" and the answer is data.
• While specialist knowledge is still owned by Business Analysts, or System Analysts, or Market Analyst (or whatever the specialist does) the data is shared with and owned by everyone and therefore empowers everyone. No egos allowed.
• It impacts at the strategic level to provide data that defines both problems and opportunities long before any solution is even thought about.
• Data identifies areas for improvement not just for end users but for solution design itself.

That last bullet point is interesting, what happens when you start to look at that mass of unbiased data when it comes to how your team, department, or organisation is running? What happens when the problem you need a solution for is a better way of operating?

• What worked and why?
• What didn't work and why?
• Are the priorities correct?
• Which team is struggling and why?
• Which team is delivering and why?
• Where are resources being underutilised?
• Who is quietly making a difference and not being seen?
• Who is not making a difference but has great visibility?
• Which resource is producing the best ROI?
• Which resource is producing the worst?

You don’t need a KPI for everything (there is a reason why the word Key is in KPI) but by identifying and collecting key data on your own ways of working and mitigating your biases can be very illuminating as to how your operational model can be improved. Can you really claim to have Design Maturity if you're not challenging and looking to improve your own design process?

Why does that matter to end users?

Because the effectiveness of the solution they are presented with is only as good as the effectiveness of the process that produced it.

So, what exactly is it that you do?

I [try] to provide a single source of information that informs and empowers every aspect of solution design, so that creatives, tech, and business are all working without bias towards the same goal.

My personal goal, through Design Analytics, is to ensure that the Experience Design Department (if not Shell as a whole) epitomises Data Driven Design Maturity.

It's my job to ensure that data is sourced and provided to everyone, not just designers. Design Maturity is to essential to be owned by just one element of an organisation, it has to be owned everyone.

Conclusion

This has really been an article about recognising Design Maturity in an organisation and how that maturity can be defined by how it consumes and uses data and removes egos, framed in my own area of concern, Design Analytics.

The mechanisms of how Design Analytics works I'll cover in another article, when time allows.