(upbeat music) - [Laura] Just for the record, I made such promise that they were contextual. (laughing) And some of them may in fact be quite gimmicky. I'm sorry in advance.
But I think, the topic is compelling business cases for design systems.
And business case isn't exactly an exhilarating word. So I wanted to make it as fun as possible for you guys so you weren't bored to death. Anyway, I'm really excited to be here talking to all of you, there's so many of you.
(laughing) I thought there were would be like a quarter of this but here we go.
And this is one of my favourite topics.
I love the idea, and its been a recurring theme across this entire conference, that concept of trying to put design into a business context.
And trying to get buy in for design.
So I'm just really lucky that I picked this topic. So, design systems are here to stay.
And this is me.
I'm thrilled because I have been trying to get to this place for years.
And it's always been a really hard journey, it's always made a lot of sense, but it's been hard to get people on board.
A recent study done by UXPin showed that 70% of companies working on products have a design system or they are working on a design system right now.
And this numbers actually higher for agile companies, agile companies is closer to the 75% mark.
And I saw this number and I was like wow! That's huge.
This concept has kind of exploded.
And it only really came up like, 6, 7 years ago? Eight years ago maybe? As start guides, patent libraries, component libraries. So it's really amazing how much of a broom there's been around this.
So, I'd like to do a little survey of my own. Can we throw the horns up, everyone who has a design system where they work today? Come on, come on.
We need to get to 70% people! Come on, come on.
Alright, alright! I'm gonna say that's like 50, 50%, alright. Who doesn't have one? Who's not working on one? Okay, that's not 50% so some of you are lying. (laughs) But yeah, maybe the rest of you are here to figure out how to get the buy in to do it. And if so, you're in the right room.
The amazing thing is that, I think we're finally to a place where we're convinced.
As designers and developers, we're convinced that this is a good idea now. And that's taken a long time.
And there's been, like Josh said, there's been a lot of arguments.
What is it and is it a good thing or a bad thing? Is it good for designers, is it good for developers? But we're past that.
We're convinced.
But sadly, this guy isn't.
(laughs) The guy who's signing the checks isn't necessarily convinced because what we think are great benefits, he doesn't see any business value in.
So essentially, we're trying to shift that conversation from us and our peers, up the chain.
So we can get better buy in.
So why do we want design systems? I felt this might be a good place to start. A big reason is that design teams are bigger than ever. It's like organisations have flicked a switch and they've realised how much better their companies run and how much more competitive advantage they have when they're investing in design. And I think, in Maria's talk yesterday, she said that consistently over the past 5-10 years, design driven companies have out performed in the stock market.
And that's amazing.
We've also got infinitely more complex design challenges. Has anyone noticed that our users are getting so sophisticated and our jobs are getting harder and harder every day. Because people want more and more out of their software. And the third big one is we've suddenly got distributed teams.
Like back in the day we all worked together, in one team, maybe in a little office, all the designers sat next to each other.
But that's over.
And now agile delivery models have sort of taken over. And our design teams that are bigger than ever are just scattered amongst other teams.
It's harder and harder for people to communicate and collaborate on these things.
And another one to add to distributed team, remote teams, global teams, it's huge.
So, most of all, it's just starting to feel like this. Like the more you work on a product and someone else works on a product, the more we all contribute, the worst it's getting.
It's like herding cats.
So this was me, like four years ago, I was reading about this concept, and I was like, this makes so much sense.
This is an absolute no brainer.
This solves all my qualms with working with all of the developers I worked with.
And it's going to make everyone's lives so much better. Right? It's a no brainer, this is an easy sell.
So this, in my mind, this is gonna be me, when I was pitching this idea, to my boss and his boss. I was thinking, yeah! I'm gonna start this and it's gonna be so great. And sadly, it wasn't like that at all.
It wasn't a fairytale.
And it just fell on it's face.
To be honest.
Because all of the benefits that I listed were benefits to me and benefits to the developers, but I almost got laughed out of the room.
They were like "we don't care if you're happy." (laughs) It wasn't a very good boss.
(laughing) So, lesson learned.
And how can we start to design our business case, in order to best communicate, the clear and tangible benefits of having a design system? Because they do exist, these business benefits. So, the people that we're pitching this to, are people, which is great! Because we know how to design things for people. So, there's an importance to Uxing your business case that I want to go through now. So the first thing is, know your enemy.
And by enemy, I mean audience.
It's not you, you're not the audience, so you got to sort of have a mental shift and stop thinking of things that way.
The main thing here is to start to emphasise the benefits that don't necessarily appeal to you, but they're going to appeal to someone who's looking at the numbers, someone who's looking at the figures.
So focus on those measurable, tangible business benefits. And that's the best place to start.
(laughs) And the second part is, make sure you're write in their language, not in yours. So once you get everyone involved in this and you've got design jargon and deb jargon, just leave all that out of it and try to communicate as clear as you possibly can. Don't go to war alone.
(laughs) This is my problem, when I first tried to pitch this by myself.
And it was ill advised.
There's absolutely no point in running this up the flag pole and trying to get external buy in when you haven't convinced the people sitting next to you. I wish someone told me that back then.
So, make sure you convince everyone around you that this is a great idea first.
And get everyone singing the same song.
People are going to want it for different reasons, and that's a great thing.
So make sure you understand those reasons.
And start to bring them together and form one united front together.
That way when the big dude comes down stairs and says "I've heard about this thing.
"why do we want it?" Everyone's got a good answer.
Timing is absolutely everything.
If you take away nothing else form this, this should be it.
So, you have to recognise whether your business is looking to invest money in your department or not at the moment.
They might be scaling everything back right now. And if you present your business case at that point, it's gonna get crushed because they need things that will make them money quickly.
Not long term investments.
So understanding your position in the funding cycle is very important.
This is actually easier in kind of a start up environment, where you have a literal funding rounds.
Because you know that you just got a huge injection of cash. And then you hold this up as something to spend it on. But in a lot of organisations, sometimes it's just based around financial year budgets. So make sure this falls after the budget.
Not before it refreshes.
And then you get a lot of extra impact if you're presenting this cure.
When everyone's hurting the most, when everyone's complaining the most.
And the business is struggling with inconsistency or poor usability test results. This is a great time to hold this up and say, lets do it. Getting the timing wrong can absolutely make the rest of your case fall on it's face.
(laughs) It is very, very important to time this correctly. So I'm just gonna let this play again.
(laughs) I just love the face he pulls right at the end. So, knowing your audience is half the battle. Don't go to war alone.
Like Maria said yesterday, rally the troops and form like a volunteer army.
And then go into battle together.
And time your business case for the highest possible point of impact.
Alright, so.
There's lots of benefits to a design system to us. But how do we translate those.
This is what we love about design systems.
Consistency, right? Suddenly, we've got a consistent experience across products and devices for all of our users.
It's a great thing.
Efficiency, we're gonna be able to deliver stuff faster. There's going to be a nicer workflow across the teams. Maintainability, it's easier to test and maintain the code if it is written in this nice way and we're reusing it all the time.
Accessibility, having it baked in means you don't have to keep fighting that fight over, and over, and over again.
Which is awesome.
Because it gets really tiring sometimes.
And the last one is scalability.
So it's less of a headache to build on this in the future. So what does it look like if we try to reinterpret these benefits into a format that provides business outcomes? Not design benefits or deaf benefits.
So, a team benefit, efficiency.
What does that look like when we translate that to a business outcome.
28% faster to market.
Does that sound better? Anyone? Come one! Yes? (laughs) Is that an easier sell than just efficiency? (laughs) Vague, ambiguous, efficiency? More maintainable.
34% less maintenance cost.
These numbers are totally dependent on where you work. By the way.
Don't take these back to your boss.
(laughs) That would be really awkward.
A consistent user experience.
18% less support requests.
Accessibility, bakes in from the very start of the project. At 12% potential userbase increase on every project. And scalability, a stable foundation that will support the next five years of your future growth. So suddenly these are starting to sound better to a business.
Which is great.
Now that we know this and we've sort of translated all of these terms, how do we bring it all together into a great business case? Buckle up.
It's about to get boring.
(laughs) Business cases are very boring.
I did a lot of reading on the best way to structure them, and all the best ways to bring them together, and yeah man, it was dry. So, I'm gonna try and make it a little bit more fun. #1 a problem statement.
What are you solving with this thing that you're proposing? A really good problem statement, identifies a core problem, outlines who is impacted, and then the big one is describing how this negatively impacts the business goals or the current objectives at the time.
And that's coming back to tying all these things we want, to business objectives.
Man this remote is jumpy.
Okay, problem selection.
You're probably experiencing a lot of problems. If you're looking at having a design system. And you're probably looking to address lots of things on multiple fronts.
But the key here is, don't choose your problems. So make sure you ask your business case and choose one of your bosses problems or choose a really key business problem that you know everyone's struggling with.
The second thing you want to talk about is benefits and return on investment.
Again, very boring, very dry.
But what are we getting out of this proposed initiative? I love this quote form Brad Frost.
It's probably my favourite that I found on this topic. "a design system increases ROI largely "because it reduces cost rather than "directly increasing revenue." and I think that s probably where a lot of us fall flat the first time.
Because we're not clearly communicating that no it's not going to being in more money.
But it is going to make us more money over the long term because we're spending less. So the key thing when you're communicating the benefits is start with financials first.
(laughs) Upper management always wants to look at possible revenue before they're going to look at other preferable benefits like staff retention or employee satisfaction.
It's just where they come from.
(laughs) And then you want to emphasise business outcomes over team benefits again. Speak in their language, and emphasise, like don't even mention a vague term like efficiency. Just try and stick to the really tangible things. The third part.
Cost and resourcing.
How are we going to pay for this? (laughs) How much is it going to cost? You've got to demonstrate really clearly, that you do understand that this will cost money. Otherwise, you'll get laughed out of the room. People will think that it's not worth investing in because you haven't done your homework. Make sure you can demonstrate how much you think it's going to cost buy estimating the manpower. And then from there try and present multiple cost scenarios. And it really gives your project a better leg to stand on if you can say, there's different ways of structuring this cost over time.
I'll go through some of those strategies in a minuet. Risks.
A risk assessment.
Every business case has one.
So what are the risks of going ahead? If we do this and you invest this money, what could potentially fail? You want to outline that really clearly and you want to be realistic.
Because if you're not realistic, it really effects your credibility.
You'll come across as way too biassed, and people will think, no we can't I'm too uncomfortable. Because it seems too good.
There's got to be a catch.
And there's the risk of not doing it.
And the risk of doing nothing is also a risk. That's definitely worth communicating.
I guess, especially if you're growing your product teams, bigger and bigger all the time.
The bigger your team gets the more you're going to need this thing.
And if you leave it till later, you're going to have all this chaos in the mean time. So its better done sooner rather than later. Make sure when you are writing this that even though you're being realistic about your risks, you're still gonna make sure that the rewards outweigh the potential risks that you put down. The last part of the business case is an implementation plan.
If I out all this money in here, how is it going to be delivered? How is it going to come to life? So make sure you present a really solid road map, ensure a clear deliverable scope.
Don't be utopian, again, be realistic.
And then along with that, try to pin point the exact time or the month or the quarter, where you're going to start to see a return on that investment.
So when it is going to start impacting projects and impacting people.
When I'm going to start saving money on maintenance. So, we've got the problem statement, we've got benefits, cost, risk, and delivery. So it has a much better change of holding water if you can manage the cost and the risk.
For a lot of businesses, they are happy to go with what employees are wanting.
But the big ones that they are conscious of, is the cost and the risk of doing so.
So, I've got three different strategies for you that you can take home.
#1 I call the chip away.
and the chip away is essentially where people just work on it in their free time.
Costs you nothing.
It's free.
Like people aren't doing anything anyway.
They may as well be working on the design system. And the great part is that it's free and risk free. Because you're not doing it at the opportunity cost of doing something else.
The down side is, people picking this thing up, doing a little bit of work on it, and putting it back down.
So it's going to be really slow.
And the quality is going to be pretty bad.
Because no one has a more wholistic view of it. No one gets time dedicated to work on it.
So it's going to be a little sketchy.
Still worth doing though.
The second strategy is what I like to call hibernation. And, this only works if the business is really convinced. They're like, yep, we are all in, we are ready to do this. We're ready to invest big.
And that's when you get a whole team of designers and developers and they're working on the design system full time.
And the great thing is, is that it's their job now. So they're going to do it really well.
And they're going to do it pretty quickly.
You're going to see returns a lot faster.
And the quality is going to be great because they are working on it day in and day out. The down side is, it is going to be costly. Because all those people could be working on things that directly increase revenue.
But suddenly they're pulled off of all these things. And because it costs a lot, there's a high amount of risk.
What if it falls on it's face? Then we couldn't spent all this money doing something else. And my personal favourite.
Is called piggyback.
And piggybacking is when you're already doing parts of design systems all over the company. So, you try and do it on the side, along with your other projects.
And you pull everything in together, so you can balance out the cost.
Because it's all paid for by the other projects. And because you're building it for these other projects, you're still doing everything of a high quality. So it's great.
The down side here is, because you're piggybacking on another project, you don't want to put that at risk. You don't want to artificially blow out it's time lines or make it cost a lot of money.
Because if you do, it's probably not a good future for you're design system.
So, we've got chipping away, we've got hibernation, and we've got piggybacking.
And the last thing I want to go through is, basically just an idea on how we can collect a lot of this information that we need to communicate. And almost everyone here will be familiar with the business model canvas.
Yes? Yes.
No? Really? They look exactly like this but it says business model canvas.
(laughs) At the top.
And all the boxes are filled with different content. But I've flogged the idea and I've made a design system canvas.
Which basically just helps everyone in the team come together around these questions and answer them in their own way.
So that you can pull all these things together and then start to write the business case out of that. It's a very designer way of collecting all these thoughts from people.
To have a canvas.
So all these different sections, do relate to the best practise of a business case. We've got problem statement, we've got benefits, we've got a cost estimation, a risk assessment, and an implementation plan.
Thank you.
(applause) (upbeat music)
