Scaling Design in Healthcare SaaS: Dealing with the past, Building for the Future

Thank you, guys, and big thanks to Viv too. I definitely am rethinking my hot dog choice for dinner tonight. Some really good practical tips there too. Guys, just conscious we've been sitting for a while too, I give you all permission to stand up and move your arms around a bit and get the circulation going if you want while I do my little intro. You can get a bit rowdy if you'd like.

So yeah, thanks again for having me, John, and Steve. Get well soon as well. It's really an honor to get to be here, to get the mosh pit happening. It looks like there's a bit of crowd surfing now. Awesome. Yeah, as John mentioned, I'm Lucas. I'm the general manager of design and customer research at Magentis. Here to share today a few interesting learnings and findings around integrating design in a company that's got a lot of legacy and how we can be innovative in our processes of modernizing a lot of health tech solutions.

So whoops, I've got my clicker. So a bit about Magentus. We're a health tech company with deep expertise in clinical systems, practice management and health informatics. So we're a provider of solutions for health care providers. So we like to think that we help the people who help people. So although we're not directly focused on patients, we really get to see a great outcome when we help those people who are working so hard to help them.

So with clinical systems, we're providing eighty percent of The UK's radiologists with the software that they're able to look at images of our body, key in a lot of the information and make sure that they're able to deliver the best insights in diagnostics. For pathologists in Australia, more than fifty percent of pathologists in Australia are using our software to look at our blood and report back to doctors on how we're doing it in our health with our eyes in the microscopes and things like this.

In oncology, we're also providing most of Australian oncologists with planning out cancer treatments for patients and planning out a lot of those pathways. And in practice management, our products are the backbone for the majority of medical specialist practices in Australia, in private practices, managing patient appointment bookings, the clinical record, seeing patients and managing prescriptions and billing as well for a practice.

And health informatics is really around building that future of AI with access to a lot of health data, which provides so much insight to training a lot of these models that we are learning about today, and also about how not to be too reliant on them. Whoops, that's back. So Magento actually represents we're a fairly new brand, but we represent the coming together of decades of different products through different acquisitions. And whilst that gives us a great position to be able to serve customers and connect up a very disconnected ecosystem, it also means we've inherited quite a lot of legacy.

And whilst the practice of design in the business is also relatively new, and only in the last seven or eight years, it provides us a lot of unique challenges for dealing with the past and also trying to look to the future and how we can build it. So I had the privilege of leading the design and research team in Australia and The UK, and both getting to hear about what a lot of designers have been doing today.

I'm definitely having a bit of FOMO in terms of being hands on in design, which sadly I don't get to do as much nowadays, but it's really inspiring to see everything that my team's doing. But a little bit about me. So this is a photo of me back in 2020 taking a great leap of trying to move my family back from Berlin to Australia. I've got my young son Max strapped onto me there.

That was for about thirty two hours of flying. He was there constantly taking the mask off. But on the final leg going from Doha to Brisbane, I remember having this feeling of careful elation and taking a deep breath through my layers of masks and just thinking, somehow, we've made it. We eventually made it into the country, and little did I know that the two weeks locked in a hotel with two under three two boys under three, climbers was gonna be the next challenge.

But if there's anything that that taught me, it's that when the pressure's on and things like COVID can unexpectedly happen, we can do great things and take great leaps forward. So I remember in my days working as a management consultant in Europe, we had a lot to do with embedding design practices in the digital transformation journey of a lot of clients through EMEA.

And despite all of the hurdles and challenges that we had to put to them and things we've heard about today as well around challenging our ways of thinking, around bringing customer insight and bringing empathy into the conversation, As soon as the pandemic hit, it really forced them to rethink the collaboration model, the way of doing work internally and the way that we can connect with others.

And so it really shows that sometimes these great forces force our hand for change, which, from a designer's perspective, it can be good. But sometimes it can seem insurmountable. So this is an image of Berlin's bureaucracy museum. So apologies, I'm not mocking Germans because I love the German people, but they're well known for their bureaucracy.

And sometimes these problems can actually seem too hard to really try and solve. This says, welcome to the waiting, waiting, waiting, waiting room, with a typical patient stuck in that void. So while industries are moving forward, the health system is significantly lagging in this space. And that's not due to any singular problem.

But as I'll talk about today, there's a lot of technological and process and people and organizational elements that can actually contribute to this. And that's really a great design challenge for my team to have. So when we observe the journey of health industries abroad as well, we've heard earlier from SASH about strategic design and the way that we can apply design to largest macro scale problems and systems.

And this is something that gives us the opportunity to collaborate and rethink the ways that we can try and solve them. And as I'll talk about shortly, the elements of do we just try and recreate a system in a digital in a modern cloud way or do we actually need to rethink the way that the system is built, is an example of looking at these challenges.

So Marco Steinberg, a strategic designer from Finland, introduced the notion of eighteenth century institutions in a twenty first century world. So things like government and health. A lot of these systems existed before the internet, before computers. And the big step with bringing them into under the fold of technology was often just digitizing a system or a process that already existed. So design as a discipline was also quite nascent back in the day. So you'd often see engineers just taking a system and digitizing it and then that's now how we do things.

And again, that's been a great opportunity for my team to really get closer to the people using these systems now. And so when we do get a chance to rethink them, we make sure that we put them back together in a way that's moving forward. So two things I'm really gonna cover in this. One is around the realities of designing for legacy systems and the other is around building the future versus improving the past.

So one of the first points to talk about with legacy is that things wear out over time. So maybe I'll just get a quick show of hands. Hands up if you've ever used a fax machine. Nice. A few of us are showing our age. Sorry, I'll put mine up too. What about in the last ten years? Oh, yeah. Still a few.

You must work in health. Well, 80% if you're working in a hospital, chances are you probably use it every day. So 80% of Australian hospitals still rely on this method of communication for a lot of processes. And this really highlights the persistence of analog systems in a sector where, despite having an interest to try to move forward, often there's just a lot of hurdles that can overcome, whether it's cost or even the cost of change.

And that figure's 82% in Germany, so we're a little bit better. So a lot of our products, despite their success, a lot of our products have also shown their age at Magento's. They all sort of carry with them the legacy of when they were built, back when digital data entry was a marvel and they were engineered to be served from sort of server boxes that sit in basements.

And so the idea of updates is not something that is as smooth as you'd expect nowadays. And even things like UI design or usability testing or any kind of user feedback or product branding were either an afterthought or non existent at all. So as some of these products began in the mid-90s, this was with 28.8 Kbps dial up modems.

Had Windows 95, was the hottest thing out. This was a great web design, great use of typography, refined use of animated GIF backgrounds. And I'm sorry if Jesse is in the room, but great great job. I think retro might be coming back. But yeah, as I said before, UX design at this period was still really coming into being.

And so having to carry the past with us into the twenty first century is something that also carries a lot challenge. So that didn't stop progress, though. And a lot of successful uses of software and technology got us to where we are today. And especially in health, some of them are still serving.

So these are actually some of our products at Magentis. And in a room full of designers, don't cringe, There's actually still a lot that doctors get from this. And there's not necessarily massive problems to solve. I mean, there are, but it isn't always necessarily due to the UI or the UX of this software, so we think.

But the thing is that over time, things can wear out. And that's really that point around legacy here. So has anyone heard of the elephant curve? Sorry, not the elephant, that's a different analogy, the bathtub curve? Well, basically, the bathtub curve looks at the lifecycle of a system's reliability. And in the early stages, it's usually sort of messy and not as stable and working well.

Then once it sort of comes into being, it's usually stable for quite a long time. Then it usually starts to curve up again in terms of its failure rate here. And we see in modern technology the ability to do product updates is what we see in this blue sorry, software updates. That can prolong that sort of uptake of failure, but just over time, it naturally happens.

And so that will always drive us to need to relook at what technology and infrastructure we're using. And the reality, number one, of healthcare is that with this gradual creeping, it always will drive the need to review and change. So the second point is, and this is much closer to home for designers rather than technology, is just reaching users.

Now, this may not be unique to health, but sometimes, despite our best efforts, actually trying to get through to the people who actually are using the software is easier said than done. In some of our practice management products, we have a much closer relationship to the people running a medical practice. The buyer is often the doctor who's actually using the software.

Whereas for other products where we may be working with hospitals or larger groups, actually knowing it and knowing who the people are that are using it takes a considerable amount of effort. And when we consider what designers are really focused on doing, that sort of operational element of actually trying to get access to users, find out the email addresses, find out if it's okay to be reaching out to these users and asking them for their problems.

They're all hurdles that we need to step over as well. So part of that conversation is also setting expectations. Often the relationship between software vendors is, well, if I'm gonna get on a call and you're a designer asking for my feedback, then I'm gonna give you my list of things that I'd like you to do and then I'm not happy until I see exactly what I want. So setting that expectation around how we bring together different themes and a diverse perspective is an important conversation to have as well. That also goes along with expectation setting around showing a Figma prototype in a way where we're fooling people into thinking that these are actually working software in order to get the insight that we want. But there's a lot of very busy, very burnt out people who see it and think, well, I actually just want working software now. And so having a productive conversation with those people is also an important thing to build up in your relationship with users.

And I mentioned before, but that sheer challenge of even finding the contact details. And then actually building up a database of who have we spoken to. If we reach out to this doctor again, have they already told us the answer to our question and we don't want to waste their time, especially when they're very much focused on delivering care. So just these are a few photos of our teams as well. So we try to go where the user is.

So in this case, we're going to medical practices and actually just observing and getting them to talk through a day in their life. We learned so much around the reliance or the preference for keyboard over mouse, which in modern desktop SaaS is we sort of think that maybe clicking and dragging and swiping is a welcomed thing. But some of these users love the keyboard and actually love all the keyboard shortcuts. They've got mouse pads, ironically enough, with keyboard shortcuts on them. A couple of other things, so it's hard to test and learn. So with legacy software, the idea of continuous deployment and as we heard about earlier about continuous discovery habits, actually being able to ship and test and learn isn't necessarily as easy as we'd expect or hope for.

So we've got to be really careful and it puts much more focus on getting it right before you work with engineers to build things. And also, no design system and component libraries. You'll see a few interfaces over time here, but the idea of making sort of global rollout changes to the software is usually just seen as something that's too hard.

Even the idea of trying to improve accessibility can be difficult if you actually look at the effort of actually needing to go through and change the overall contrast of the applications. And again, people are very busy. So I mentioned a few more great things. This isn't actually one of our products, and apologies to whoever's product it is. I just pulled it off the internet.

But this is an example of what we see when we've got these legacy products. And a common thing is this shift to the cloud as well. Like, we used to talk about digitization or digital transformation. But really, in modern age, having things in the cloud and deploying them that way is a really necessary step.

And it also carries the opportunity to rethink and redesign things, which is usually where we see a great opportunity as a designer, is because there's an appetite to we're either starting with a blank slate or we need to find out a way to move all of that into somewhere new, and that's a great opportunity. We also need to think about the sort of wicked problems that exist in the domain of health as well, is that when we talk about complexity from a UI, UX perspective and overall usability, there's also the inherent complexity in medical here.

If things go wrong, people can be can what's the word? People can get hurt, and and there's a lot of clinical risk in in getting things wrong. And there's also the situational complexity piece as well, which is really around whoops, is that my mustache getting in the microphone? I was warned of this.

I should have shaved earlier. That would be an interesting presentation. So really, the idea that a lot of these systems that exist also had processes built around them and resourcing models around how many people do we need to actually use this software and whose job is at risk if we're actually redesigning it.

And they're all the things that we, as designers, need to sit down and understand with the organizations that we're working with, too. I love this graphic too because this really sort of points out the fact that there's a lot of interesting start ups and innovative products that are coming out, and we think this will be great and helpful, so just go and ask them to adopt it.

And the fact of the matter is that the cost of stopping often to even think and consider a technological change is something that's just too much for a lot of organizations. And again, that becomes the design challenge, is understanding even if we have a great new technology that could work and that we see value in, how do we really find a path to getting that benefit for people that are very busy.

It also talks to why a lot of the sort of base level application of AI has been around dictation as well because it's often something, as I'll talk to later, is a common thing where people are either dictating now or employing typists or actually just wasting a lot of time getting things out of their head onto the screen. And so that's actually a great example of where use cases like that can slot in really easy with existing processes.

So lastly, on the migration piece. So there's a lot of different ways if we're trying to take people from the legacy through to the modern world. One of our practice management products, Genie, the new system, cloud based system, where our designers are spending a lot of time working is called Gentoo. And we actually took the sort of big bang adoption approach. So we actually see it as a new product that we can migrate people running a medical practice to over time.

And the actual service of migration is something that we also invest a lot in the experience. We've got other products like Charm, which is our oncology product. And the team actually built up an understanding of the different modules that exist within the software and how it actually fits into an oncology practice today and actually find ways to serve the new modules while still using the old software.

And again, if you're a designer there, then it does give you a little bit more scope to try to focus on just solving some really core jobs and workflows well, Whereas some of the other approach can often seem like, well, we've got to take an entire thing and move it to a new thing, and how long is it gonna take to really understand the ideal state for that.

So the last thing there is around don't mess with what's working. And this is, I think, where research and design comes in it becomes really important because the sheer opportunity to be able to rethink something, whether it's with a clean slate or at least some core modules, is to think that we must redesign it.

We get an opportunity. So while we're there tweaking the UI maybe because we get a chance to put a new skin on it, maybe we should just sort of move this here or move that there or change the tab order, which, as we've seen already with DIV's presentation, that can have a lot of unexpected side effects. So sometimes there's the bobby pin, there's the toilet roll or any of these examples here, the fork and the spoon.

If it works and if we know that it works for customers, we don't necessarily want to change that for them. And that's a really we have to take great care with that because that nature of asking for the faster horses is often something where users, if they're asked, they may just say, well, no, I don't want to change at all and I just want it to stay like this. But then maybe we understand that that's actually not the most efficient way that they could do it.

So that's, again, where co designing and working with users becomes really important. So how do we determine what needs to be redesigned and what needs to stay the same? And that's really moving into this building the future versus improving the past piece. So I think many designers in the room probably understand the notion of the lipstick on the pig.

Another quote from Marco Steinberg. He said, We need to ensure that we designers don't inadvertently contribute to the problem by making today's flawed solutions simply look more pleasant and more user friendly. Sort of that aesthetic usability effect of making it look like it must be easy because it looks thought through.

We have to ensure that while we deliver better products and services, we also have the capacity to make sure that we're asking the right questions as well and that we contribute positively to the broader direction of travel, which in health, there's always more steps to be taken. So that's really about the fact that we can't just be putting lipstick on pigs and hijacking that effect just to make it look as though we've got a brand spanking new product and it looks great and it's shiny and it's in the cloud.

And then when you use it, you sort of realize, actually, I missed the old thing. And that's an important step to take as a designer, is to understand where to place the lipstick and when not to. So when we talk about building the future versus improving the past, that's really around that difference between we've got something that we've done forever and we might need to redesign it or move it over and make a few tweaks here and there, or actually rethink it completely and leverage a lot of the modern technology and build for that future. So UX research and product design come into that.

So here's some examples. I've got a few screenshots on this of just some dovetail screens where we're really focused on spending hundreds of hours with users over every year. And that's really around finding the best way to get their insight, to bring it in and actually do that affinity mapping that many of us do in designer research to really actually try to dig under the hood of what we heard and work with users to then come back with potential ideas to improve things as well. Again, this has a lot to do with user research.

A lot of what we've done in those years of spending time with customers has also built up quite a comprehensive medical practice journey map. And as we may get to see in a few minutes, this really shows the complexities of this is just even in a medical practice as opposed to as a radiologist or a pathologist. But really, the way that we brought together this understanding of the practice's journey is also around jobs to be done and formulating a framework that we call top jobs because we also asked a lot of our customers around what's the relative importance of a lot of the jobs that they need to do in their practice.

So an example might be booking and managing appointments or conducting patient consultations. Those are things that actually just need to exist as part of the job of seeing patients and running a practice. And so when we do get feedback and monitor a lot of that feedback, we're able to actually see over time which of those jobs are actually serving customers the best.

There we go. Amazing. Well done. Yeah, so this is the journey map I mentioned before. It's pretty difficult to see because it is a photo on the wall of our office. And this is some research we did where we asked for that relative importance of certain jobs versus how well the product is performing as well. We've also used that taxonomy of jobs to be done in our VOC repository.

So this is a lot of work that the team put into. I've been talking to a few researchers this morning around how do you deal with all of the insights and all of the data you get up over time. And we found that actually categorizing things by these jobs helps us to also make prioritization decisions in the product.

So maybe this quarter, we're really focused on the doctor. And if we can see that booking or conducting patient consultations has a lot of feedback, the sheer volume of that feedback can help direct our decisions. And finally, we've also got that in Salesforce. That's where we keep a lot of the research because we keep it close to the customer record.

And that allows us to also go back to those users at the end when we think that we've solved it for them and said, your feedback is really important. And the value of spending time with us is that you can see now that your needs have been fulfilled. So just gonna move on to efficiency. And I know Steph was talking about this earlier, and it's a big important keyword in health especially.

We surveyed 1,000 medical practices just this year and 66% of them all said that the number one priority is around efficiency within their practice. So you'd often think that the number one priority is patient care, but there's a and in a way, it is but there's a real link between how well the practice runs and how well they can care for patients if the software creates friction or gets in the way. So when we dug deeper into that, we could see things around staff shortages, time constraints and productivity bottlenecks, and they're often driven by these inefficient systems and processes.

We heard from Taran earlier about the extensive wait times for people to receive the care they need as well. And when you actually think about all of these different contributors to why there can be delays in care, that's just not good enough. So here's a few examples of how we've unlocked efficiency. So QuickScripts is a feature that our team and practice management worked on. In medical specialist practices, often they're gonna prescribe often the same thing or common things because they're a specialty versus GP practices where each consult could be different.

So this is sort of the idea of a preset set of scripts with either dosage and frequency preset. This was actually an example of the bobby pin where our older product had quick scripts. And what we learned from users was that the way it works and the way of going through that flow worked just right for them. And so it actually meant that when we brought it into the modern product, we could just do a lightweight sort of set of usability tests to see that it's still working well and we could give everyone that benefit now.

And we get thousands of quick scripts a day now with our practices. Gentoo mobile app, so this was another example of so Gentoo is practice management software, all of the runnings of a practice. And one of the thoughts was, well, if we're gonna have anything in mobile, do we need to create the entire PMS? It's the unfortunate acronym of practice management software.

Do we need to create all of the PMS in the mobile? And through user research, our designers found that if we're focused on the doctor on the go, because they're often the people who are on the go through a practice, what are the core things that they really needed to do between consults? And often it's just seeing the next appointment, seeing a comprehensive overview of the patient history.

And so we knew that things like appointment booking and things like that didn't necessarily need to be prioritized to get something of value out there as well. We've also got this is in the interoperability space, so medical practices work with hospitals. Often if a specialist needs to perform a procedure on a patient, they'll book them in at a hospital and that's another moment where the fax comes in.

At least it was that way. And you can see there's a lot of admin burden with that. If there's a no show for or a cancellation, often just the communication of the changing of those bookings means that a lot of the theaters go empty when other people could have been receiving care. And so our team worked with hospitals as well who were not our direct customer at the time to actually understand how the existence of these sort of alive theater booking experience would also alter their processes and worked with them to really find a way to make sure that the whole process works.

And we also worked on patient eligibility. This comes from research as well and seeing that in doing a theater booking, often the patient will come to the front desk and then the admin staff will call up Medicare to double check whether they're eligible for that procedure. And that can sometimes take forty minutes sitting on hold. And so while we were connecting up hospitals, we were also able to connect up that new service of testing eligibility and actually send that through to the hospital as well so that they also are not providing any confusion to the patients on the day.

I'll skip over a few just in the interest of time. So then getting a little bit more into design systems. So for some of our products, we do get the benefit of what you'd expect in today's modern design systems. The Vitality design system is something our team created. It's a comprehensive Figma library as well as a React library.

We focused early on, thanks to Brad Frost, the godfather of atomic design, on also getting the process of governing a design system down pat so that as we are building out new patterns, we can really efficiently think them through and come up with the right standards and bring them out. But we also based them in design tokens, which is a sort of lower level. I think many people in the room would know this one. It's a lower level sort of variable of each design choice or color or spacing or typography.

And because we've also gone down to that level, we've been able to apply it to some of those legacy products. So this is just an example. Our engineering team needed to rebrand one of our older products when we became Magentis. And a lot of the images up on the top left here, they are bitmap files with hard coded background colors.

And so any moment that we wanted to change oh, and of course, the source graphics went missing probably on New Year's Eve in the year 2000. So we had the choice, we could invest in rethinking them, redesigning them. That would be change for the user. But the team really found an innovative way to pull our design tokens out as coded variables, write a little Python script that just read all of those bitmap files and replaced the pixels of blue with the pixels of the correct violet.

And that allowed us to really focus more on actually delivering improvements and value to the customer rather than getting too bogged down in those aesthetic changes. So yeah, I've just hit my time, but last example here is just also product ops and where we're actually trying to leverage modern technology in house. And this is, I mentioned the top jobs before.

And some of the things our product team and design team are working on is sort of a North Star metric for each of those jobs. So if booking and managing appointments, as an example, is a job to be done, one of the core performance metrics is how full is the appointment book and how many patients are you getting to see. So we can use a lot of modern analytics that can feed into dashboards like this.

This is one of our product ops guys. He's vibe coded this, so we know vibe coding is the hottest thing nowadays. But it's actually allowed us to connect up real data and get a lot of the infrastructure together to actually test whether this kind of thing would work. So I'll just wrap up there. I didn't get to talk a bit about scaling design, but I think we've heard a lot about that already in terms of the cultural shift required. I'll just sort of finish with an example of where I think we need to do better.

So an industry colleague recently told me a story of her father who was an outpatient at a hospital. And he spent six hours there being passed between five different doctors who asked him most of the time the same questions and input the same information into what looked like the exact same system. And all throughout this experience, he was also really stressed and anxious because his parking had expired and he didn't have a chance to go out and renew it for fear that he would miss that next appointment that he was being passed through.

And if that's assume I mean, that system is working as the system was designed, as we heard earlier, but it really shows that there's a lot of potential and a real need for redesign in all of those kind of things. So with that, I'll say thank you and have a good afternoon.