From a Prehistoric Beast to a Modern Day Product Enterprise

So today I'm going to talk to you about the journey that the previous company that I worked for went through changing eye bleedingly ugly financial services software into beautiful, usable, themable, sort of web platform.

So a little bit about myself just quickly.

I'm the Chief Experience Officer at AcademyXI.

If you're from Sydney, you know we're an educational institution.

But I'm also, as just mentioned, I run our Applied AI capability.

But this talk is not about AcademyXI, it's about a company called IRESS, which you may not know, but I guarantee you have interacted with some of their software, either as white label or directly.

So IRESS is a financial services, software company, global across, five continents, over 500,000 B2B enterprise customers.

Now, My talk isn't going to be about the benefits of design system, why you should do it, otherwise you wouldn't be here.

It's actually a journey of what it took for us to go from 20 plus years of acquired software from multiple organizations into something that we could be proud of.

Okay, and hopefully you're going to take some of our learnings away about what to do, what not to do, and go and apply it in your own organization.

So I stopped working at IRESS around June of 2023 this year.

So this is a point in time talk for you.

But just to give a comparison between, REA and IRESS, so this was our design system at the time of my departure.

So we had two sponsors.

We had the Chief Technology Officer and myself as Global Head of Product Design, my principal designer was actually a product manager, we had one engineering lead managing five front end engineers dedicated to the design system, and I had half of my UI designer on that team.

So quite different to the REA team.

And we were servicing 19 designers, or UX designers, or product designers, and content writers, and over 600 product engineers.

So if you do your maths, you realize, wow, there's a little bit of a ratio that's out of whack here.

Now, I want to know who's in the room and some of your experiences.

So I'm going to do a quick poll.

If you can pull out your phones, and hopefully the internet does work.

Yes, it does.

Go to slido.com, please.

If the QR code's too small, you can put in the number 86 72 360, and tell me where you are in your design system journey within your organization.

I have a guess.

I think where we'll be, but I'm happy to be proven wrong.

I'm assuming Chris, that's you at the top, right?

No, we're humming.

Where's We're humming a dad.

Many people are humming.

How many people are in this room?

I'll give it a bit longer and the answer is pretty much correct every time I run this poll, which is, yeah, we have one where we could do better, which is.

The way I'll summarise my talk towards the end, but it's a very common place to be within the organisation.

I'll keep going.

Let me set the scene.

Global financial software in the enterprise space.

And I apologise for the designers in the room if your eyes are going to bleed.

But our software look like this.

Extremely powerful software that makes you want to vomit, but has features and functionality that nobody else in the world has.

Extremely powerful.

And again, it's a combination of years of development and acquisitions.

And our goal was to go from this to something pleasant, themable, scalable, responsive, and accessible.

As much as financial software can be sexy, this is a vision that we set ourselves.

This is what we sort of prototype as to where we want to get to.

Now, while we set this vision, we've got some hurdles to get through.

There are eight time zones globally that we have to coordinate.

As I said, we've got 20 acquisitions, so 20 different tech stacks from different organizations, an absolute mishmash of tech.

Now actually, this number is much bigger.

I've gone quite, what's the right word?

Conservative, and I think we've gone more than 60.

Products.

We're B2B and B2B2C.

We've got enterprise software, a couple of the, the biggest organizations in the world who use our software to drive superannuation, financial advice, trading, which means we can't just change things at a whim, because have knock on effects for all these big organizations.

Doing, innovation from a design system perspective and our products becomes really, difficult.

I'm just going to pause for effect there.

That's a scary number, right?

One designer to 55 developers.

Imagine.

And Chris, how many repos did you guys have?

Did you say 20, 40?

Okay, 333 repos.

So just imagine, we've gone from something shitty, we want to go to something amazing, and we're going to get through all, over these entire hurdles.

Now, if someone gave you that brief, I'm sure you would respond with something like this, right?

I'm sure Jeremy Clarkson would.

I did, and I still took the job.

So this talk today, is broken up into sort of three phases of IRESS design system journey.

What I call the humble beginnings, right between 2015 and 2019.

Then the take two, where we did a bit of a reset, and I joined halfway through that transition.

And the sort of the vision that we set ourselves, which was to go towards a single product platform organisation.

So back in 2015, what did the organisation do?

Ah, hired a bunch of UXs.

We called them UI designers, gave them a bunch of Adobe software, go.

Some people still like to use Axure and Balsamiq, so they kept doing that.

And we had a sort of a pseudo style guide, half coded, not consistent.

Now, go and build beautiful software.

So the team wasn't really set up to succeed, right?

There was inconsistencies, designers working their own way in silos within product organizations across the globe.

Nothing was kept in sync.

And it wasn't really working.

The journey for the design system really, although you can say it began in 2015, they decided to formalize things a little bit.

So they gave it a logo, so that first logo, One UI, is what they called it.

They consolidated tools just to use in Adobe XD, decided on some tech stacks, which was React, Web, and Bootstrap, and said, we're going to become AA compliant.

But really, there was still no governance.

There was a team that was half doing this work and half being within product teams.

There was push and pull requests everywhere, the design system was becoming bloated, And no real ownership or accountability.

On top of that, halfway through that journey, they said, Oh, we need those engineers now to go and work on our product.

We're just going to second them for two months, which became like four years, right?

So now you've got this asset that's sitting there, some effort that's been put into it.

Some of our software, we're using it.

But it's not being supported.

So really, the computer said no.

It was high cost to maintain, it wasn't getting much traction, CTO was starting to ask questions about ROI, and so the team were quite stressed to go, shit, how do we go about this?

We understand the value of design systems, what are we going to do?

I love this picture, right?

As the team looked back, they told themselves there's got to be a better way, for example, sunscreen, right?

They went to the first, the basic principles and they started from the bottom up, pun intended.

They went to the CTO, they put a business case, put some of the ROI's into those reports, said we want to dedicate a team, this is the value we're going to give, or this is the risk if you don't.

Lawsuits around, accessibility, because we played in Canada, and Canada had now mandated that any product, doesn't matter if it was enterprise or consumer, had to be accessible, yadda.

And the CTO goes, you know what, it's a small team, sure, go.

And we'll ring fences so nobody can touch.

Which is fantastic.

So this is really almost like the second phase of the IRESS Design System journey began.

And I want to share some guiding principles with you.

So the team decided, alright, you know what, we need to truly treat this like a product.

Chris being a product manager, we need to treat it like a product.

So they rebranded it again, called it IRESS Design System, IDS, which is probably not the most sexiest term, but it's very factually correct.

And it had the dedicated team, four, four developers, part time UI designer.

And my design principle is the product manager.

And we started getting smarter with the tools we were using.

We were, we were already using Jira, but we put on top of that Aha, which is a product management tool, where we could truly track the backlog and the request of features and functionality while coming in, like any other product that you have.

And we were sharing those roadmaps like any other product.

So we had Slack channels where product managers globally would report on a quarterly basis around their roadmap.

We were doing the same thing.

Just like any other product.

So the second principle was, let's build a community, right?

We're a small team, they're a team of five, trying to service, over 600, 700 product engineers.

We need to get them to help each other out.

So we built Slack communities, we've got people joining them, either product discipline or regional discipline.

And it was great, because there was this flywheel effect.

The engineers started to help each other out.

So there you go, four, front end dedicated engineers in the design system.

You had another 100, 150 advocates who knew about the design system, could support, could go and build features and functionality that they wanted, but doing it the right way, so that when the design system took over it, it could just plug straight back in.

And we started formalizing some of the ceremonies.

So we had our designers get together three times a week.

Not just a sharing, doing critique on the design, but talking about features and functionality of the design system.

What Chrome components don't exist.

What are you doing?

Are you using that drop down?

Can I borrow your drop down?

Oh, that's fantastic.

Can I use yours?

No, try it a different way.

But specific around the design system.

Once a month, the engineers would get together and we'd do what they call a coded.

Think of an internal mini hackathon, bit of a tech dip, reset.

Just so you'd be able to fast track and expedite some of the things that were coming through from a request perspective.

Once a month the designers and the engineers would get together and do literally hands on playing of new functionality that was coming to the design system or the changes that the engineers were making using things like Playbook.

And then once a month we would have a showcase.

We recorded, everybody could watch.

We'd get stakeholders across the globe to come and watch or actually participate.

And we truly turn it into a product.

Now, the design system has customers, right?

We have customers.

Our customers are our designers, our writers, our engineers, right?

So we thought it would be imperative for them to be onboarded properly.

So as well as existing, staff, any new staff that was put on board, we've forced a bit of an induction process on them.

So while they're doing their security checks and doing some of the other stuff that they had to do from a training perspective, we build an entire course in Udemy.

So Udemy is like a MOOC, Massive Open Online Course, like Coursera, Udacity, edX, all that sort of stuff.

Udemy has a business version, which we have got license to where people were jumping on and just doing a personal development.

So we've got the design system to actually build an entire course around IDS from t101 of what is a design system through all the components and tools, through ideas for developers, for QA engineers, for designers, for product managers.

And we mandated anybody who starts at IRESS as part of the induction process, depending on their role, would have to complete that course.

So then we can watch through analytics.

Who's done it?

Who hasn't done it?

And it made sure the foundational knowledge of our design system was in every staff's mind.

A lot of effort went into it, but I think it was worth it.

Is anybody from Adobe in this room?

See you later, Adobe.

XD was gone.

And we should have done that probably two years ago, but when I came in I said, why are we using Adobe XD?

And we jumped onto Figma.

Tool of choice.

Everybody knew how to use it.

And it was a lot more flexible from a, point of having developers providing input as well.

And then lastly, we're using this thing called Storybook.

You might have come across it.

Again, it's a documentation tool.

We already had a documentation for the engineers from a design system perspective.

But every time a designer wanted to go, oh, how do I use this button accordion?

Go, go to Storybook.

Yeah, but that's a bit jargony and technical.

I just need some screenshots of what to do and what not to do.

So we didn't have documentation to support designers.

While I was there, we started the initiative at drafting out a sort of a document specifically for designers, starting in Google Docs, and the goal was when it got to a certain point, we then merge it with Storybook, and then decide if Storybook was the right tool to have that documentation.

But at least designers now had something.

And these are some examples.

With Udemy, you've got video, audio, and we had chapters on the right hand side, And some stats to share with you.

So within the three months of, launching this, we had 152 enrollments across the globe.

The average star rating was 4.6.

We had 137 active users at any given time.

Over 10,000 minutes of, learning delivered.

It was really hard work.

These are engineers who don't feel comfortable with their voice, with their screen, they did an amazing job–scripting, rehearsing, multiple tags to produce this.

So with Figma, we've got software that sometimes sit on over six monitors, like at a trading desk, like a minority report, right through to software that sits on an app.

So we need to have three different modes, what we call a compact mode, a standard mode, and a touch mode.

And then we need to have also dark mode and light mode, because we want to really support accessibility.

So we had six different versions of every component across our 50, 60 plus products that we had to rebuild in Figma.

And in that documentation, standard stuff, examples of what to do and what not to do.

That really supported the designers to quickly get on board and decide how they use that component.

Now future proofing, this is probably the biggest bugbear that we had at IRESS and I'm sure they probably still do.

Making the right tech choices.

So we decided to ditch Bootstrap because it wasn't, I guess scalable, and we chose a quite a, call it a risky decision of going with what they call web components, which is agnostic to front end environments.

You can build React from it, you can build any piece of software from it, but at least it's agnostic and is well supported and mature.

This was probably the most powerful, impactful things that the organization did.

And it wasn't actually probably due to me, it was probably more the CTO.

We had goals set for 2025, call them OKRs, but we didn't call them OKRs.

There was 49 of them.

One of those was this one.

A strategic priority across the entire organization that the IRESS design system needs to be used across our products.

She made it really easy for me when I was having those conversations going around and if product managers and global heads of product would say, no, you know what, it's not a priority, I'd go, hang on.

It's one of the 49.

You're, you're neck's on the line just as much as mine.

We're all accountable to deliver these 49 initiatives.

Which made the conversation much easier.

I could go, okay, if you're going to say no, that's okay.

If you don't mind, I'm just going to put you on this register, in the no column, okay?

It's okay.

And then I'll report that back to the CTO and CEO.

And before, go, hang on, maybe we can work something out.

So it's really effective in terms of getting buy in.

A little bit of a carrot and a stick.

Figma plugins and, tokens, obviously it's a no brainer.

We kept a single source of truth as the code.

Okay, which meant still, until we got the plugins really working with the tokens, every time the design IDS team would have to change something in the component level, we'd still have to get one of our UI designers in the design system to go and update that in Figma.

And then manage the version control.

It was doable, but we had a very small team, right?

Ooh, sorry, before we go.

And then, double A compliant.

This was a no brainer and we actually then mandated.

Nothing left the, nothing left the design system and was published unless it met AA compliance.

Which we're really proud of, which made it easy, but to Chris's point, yes, there was still opportunity for, product engineers to go and bastardize and break it, but we could just say, look, what we've released to you is accessible.

If you go to Chapter 5 of the Udemy course, you'll learn about accessibility and how to deploy this, this, component into a piece of software, but we weren't really overseeing everything to see if it was being implemented correctly or not.

Now, I want to do another poll, because as the challenges don't go away.

So I'd love to know what are some of the challenges that you have currently, or think you will have from your design system perspective and select all that apply.

This is multi select.

Is the fact that you've got the wrong tooling for your designers or engineers, is that you don't have the people, the resources, is that you've got the wrong or outdated tech stack, it's a good old ROI and stakeholders, is that your biggest issue, engagement and adoption or process and governance?

Interesting.

Can you guys see it?

Yeah, you can.

What's the race?

Who's going to win?

Okay, 'outdated or complex stack'.

Interesting.

Where's the stakeholders?

Okay, it's not that high.

Surprising.

Thank you.

Okay, our challenges.

They're still unresolved We've got One UI, the previous incarnation of our design system we had to keep the lights on.

We've got Ideas, the IRESS design system, a new design system we had to keep the lights on.

We've got now a very complex Udemy course that we've got to keep the lights on.

We've got Playroom.

We've got a React app as a playground for people to play.

What else?

We've got heaps more.

Documentation, plug ins, Figma files, the list just goes on, right?

So we just have more systems for the same size team to have to manage from a product perspective.

And the irony, right?

As people being adopted, as I'm pointing to our OKR and initiatives, more teams go, yes, I want it.

There's more support that the team needed to do, and more requests were coming through.

Your design system was still the same size.

The organization didn't want to inject any more and go, you know what, you've got five, you're doing really well.

We've got more demand and we've got more assets to bloody manage.

I can tell you, the team were extremely stressed.

The interesting thing, and I'm not sure many organizations face it, UX designers, who are too busy, spread across, what was it, the 600 engineers, 1 to 55 ratio.

And we've got what we call full stack engineers.

Now, what do we mean when we talk about full stack engineers?

A lot of back end stuff, right?

CSS is just not their game.

So you've got one side, you've got devs going, okay designers, when you've done your pixel perfect design, can you hand it over to me?

Designers going, hang on, I've got to do that for 55 engineers, here's a sketch of the back of Mac, and you've got the design system, just do it.

And there's a gap in the middle, people look at each other and go, but hang on, can you just fucking do it?

No, can you just do it?

And there's this tension.

Then we really got resolved.

We started to resolve it by me hiring dedicated UI designers slash design engineers.

That's it.

But still, based on the ratio, that tension was always there.

And also, we decided that we would start to hire dedicated front end engineers as well.

Product roadmaps, right?

B2B business, you've got commercial team talking to global organizations, telling product managers, we've just solved this, can you go and build it?

And I'm there going, knock, can you make sure you do the design system by June, because we're going to kill the other one.

So very, complex and very stressful relationship between, myself and product managers.

You go, hey, we've got this OKR we're going to meet.

Yeah, I've got a bloody commercial team globally busting my chops.

It was really hard to manage.

Probably still is.

And the jury's there for Web Components.

As much as the team thought, okay, that's a good tech choice, many of the front end, many of the product engineers don't know what Web Components are, how they work.

And at the end of the day, the whole organization was going towards React.

So in hindsight, we should have just freaking stuck with React.

So I'm not sure what they're doing with that at the moment.

And the good old classic ROI, which we solved in a different way to REA, but there was always the conversation.

And we go, hang on, there's a team of five servicing over 600 engineers, for goodness sake.

But still, they wanted to know what's the return on investment, quarterly reports, finance, etc.

We're a fintech company, we want to keep the, wallet quite tight.

So I had to do a lot of that reporting.

Now, just quickly talking about the ROI, now it's funny, I was the first person who put my hand up when Chris asked that question is, I'd seen an organization who did amazing work that REA did, ANZ, which is one of Australia's biggest banks, did an actual test, they got a bunch of designers, they gave them a sort of a design use case and said, I'm going to time you, you're going to do it with the design system, we're going to do it with, without the design system, randomized, and then they checked the quality of the, match tools, the sort of the, that, that example, and how long it took that, took them.

And they did that across, I think, 30, 40, 50 designers.

We couldn't afford to do that.

So what we did was we Googled.

And we came up with a bunch of websites that actually had some very, evidence backed research in terms of formulations to how to do the, how to get an ROI on the design, system.

So we times it by the number of engineers and the number of components and number of modes.

And the figure we got, at any given point in time, 6.7 years of a single engineer is saved.

Look, that's phenomenal, right?

If you've got one engineer, they've saved seven years of their life if they use a design system.

So that was really impressive.

That's what got the stakeholders to go, OK, you know what?

Shit, this is important.

It's really important to do the ROI on that.

Now, to wrap up, the chapter three of where IRESS was planning to go.

IRESS is an organization, we've got, we can't manage 20 plus, years of baggage and 50 plus products, so let's go down a platform route.

Let's build a single, API driven, thank you, API driven, platform where we will build modules and components that when come together could create new value propositions for their clients.

So we said, you know what, the design system could be a very important part of that journey.

So if we go down the API first route, where the APIs would decide what needs to be rendered on the screen, they would then use our, atomic design principles, atoms, molecules, organisms, and layouts.

Sometimes we're using third party libraries, like we've got lots of grids and tables which we didn't want to repeat, so we're using things like AGGrid.

Supported by our design tools, our documentation, our courses, and meant, at any given time, IRESS could either create beautiful software, that's only in effect dynamically rendered, or we can give all these assets to our ginormous enterprise clients and go, you know what, if you don't want our look and feel, you want a yours.

Here's all the assets.

We'll publish the design system so you've got access to it.

We've got all the toolings.

You can have our Udemy course if you want and you can go and build your own software.

But you've got the standards there.

So just to wrap up.

So what do we learn through this journey?

Going down the product route makes a lot of sense.

Governance, ownership and a dedicated team is what really works.

What is working.

Building a community, right?

Especially if you don't have the opportunity to scale your team ensuring you've got that flywheel effect so that other engineers are helping each other out and designers are helping each other out makes a lot of sense.

And think about scale as your team and company grows, right?

Make the right tech choices, think about laddering and scaffolding of components, and get your ways of working tight.

But probably the biggest thing that we learned was the design system is a continuous journey.

There's never, you're never going to get it right.

But more importantly, it's fucking hard work, right?

And I found this, bless you, I found this quote, which I can't remember where it's from, but, when it comes to design system, there is no such thing as done.

So hopefully in that poll, I'll never get one company that says we've nailed it.

Because I won't believe it.

On that note, thank you very much.