Warren (00:00)
Welcome back everyone to another episode of Adventures in DevOps. And before we get into the episode today, I just want to introduce the sponsor, is building a product that promises a high SLA like we are knows that remediation as soon as possible is absolutely paramount. Out-of-date runbooks result in wasted crucial Often companies told us real challenge is that no two incidents are exactly And that's one of the reasons I'm appreciative that Incident.io is sponsoring today's episode.

because they've got this awesome technology that dynamically assembles runbooks

you know that you're most up-to-date on your team's actual and in the context of what's actually They're connected to all the popular tools in the space and I can honestly say they're the for those paying attention, their founding engineer on our recently and it was a fantastic we deep dived into their cutting edge As be in the And now back to the show.

Warren (00:58)
I've brought in our guest, Elise Stanley Breval,

VP

of UX and customer journeys at Unleash.

Elise Stanley Brevald (01:03)
Yeah.

Warren (01:05)
What's the difference between VP and head?

Elise Stanley Brevald (01:08)
To me it's about like who can I get access to when we discuss and when we do chats with customers and stuff like

VP is closer to the management team and is also focusing more on revenue, on risk mitigation, joining leadership to make sure that we are setting the goals and the expectations.

Warren (01:29)
You know, I think that in each sort of micro organization within even a larger company, these titles end up getting very confused very, very quickly. And some companies have believed like head is like the top right under say CTO or CEO and VP is just the title you give to some of your sales folks. So they sound important on their sales calls.

Elise Stanley Brevald (01:48)
Yeah,

And unfortunately, this is also the same when it comes to customer experience and customer journey, that the better title, the more important.

Warren (01:53)
Hahaha

Elise Stanley Brevald (01:57)
It also means that I actually have the option and the possibilities to actually go in and have an opinion on what's going on in all the different departments. So very often I am the annoying lady in the room, come and sneak peek and make sure that we can actually deliver this world-class experience in all the touch points.

Warren (02:17)
So you have almost, I think I looked at your LinkedIn, almost 30 years in basically UX and user experience and just focusing on delivering what I assume is the best products to your users as possible.

Elise Stanley Brevald (02:28)
Yeah, to me, like, I entered this space even before we had a name, before we were called UXers, after I left university, before Millennium.

It was still not normal that we were discussing UX. It was very much like developers coming in Deciding what to build what to do and then you have the customers and your user decide and they just needed to adopt into the experience had no clue what's going on on the screens, but but that was how it was that back then so my first years. I was more into business process optimization. I tried to understand better like

from the customer perspective, always advocate for the users,

Warren (03:06)
what you've described in sort of your experiences that good UX is blurring the lines with product management and really they're both these roles or really facets of an organization are getting down to building the right thing. And it's interesting because in almost every episode of this podcast, we end up talking about how it's one of the hardest things to do. And I'm going to go out on a limb and say that there's like a lot of distractions that are keeping

organizations from actually being able to deliver the right thing today. And it's interesting that the way you talk about it, I've always sort of segregated some of those responsibilities as product management and some of the other ones as UX team or UX researchers. But the way you talk about it really tells me that, actually these things are heavily overlapped. How can you think about what...

an application or platform should look like without actually understanding the direction it's going and that means interacting with the users and understanding what their expectations are. Whereas I feel like a lot of companies actually keep these organizations as separate entities who may not even talk that much.

Elise Stanley Brevald (04:06)
So until now in this startup that we are building right now moving from these like we started out with five people five years ago

we haven't had any product managers. So the way we have been organizing this is to first of all make sure that we have really skilled employees.

then people will probably argue that you need to have a product manager first.

So what we have seen until now is that we haven't had a need for a product manager

Warren (04:31)
I think that's a really critical mentality you've got here because I really push the same thing on the engineering side as well. When you're hiring anyone, I think fundamentally you have to understand area that you're in or the skills you bring to the table, there's still always to solve some cornerstone area that's really business driven. And I know saying like, what's the business problem or business strategy is such a dirty word in engineering that everyone's like, ⁓ business, that's something else.

Elise Stanley Brevald (04:34)
Hmm.

Mm-hmm.

Warren (04:58)
We don't need to think about that.

there are a lot of failure modes though that happen.

When you have a dedicated UX team, I've seen the opposite side where you have something called the UX team in your organization or your company and they just create components for every UI element that you could possibly have. And they're off designing fancy UIs and don't actually understand what the users are actually doing or what they need. There was one example from my past where the UX team wanted to help everyone and they eventually got to our organization and they were working with one of my teams.

And they're like, we should change the UI to do all these different things. And there's a better user experience for them. Having done no research whatsoever on how many people actually use the screen, what they're using it for, what the user journeys are that really need to be solved there. And they're removing elements and putting things other places. I'm like, what are you doing? Honestly, what did you think was going to happen here?

Elise Stanley Brevald (05:50)
When I start discussing UX for me and that's also why I mentioned the UX strategy in the beginning because

As you said, you can outsource the UI if you want to, but UI is for me more like, how does this look and Then you have the interaction design

then you have the more important thing and that's the core fundamental thing for

is actually going behind the scene. This is really starting to understand what problem is it actually that we want to solve here. And then we can always decide how should that look like can always decide how should it if we don't manage to ask the fundamental question, what problem are we actually trying to solve?

then we have an issue.

Warren (06:30)
two problems I see pretty frequently. The first one customer or your collaborator or your client is asking for something. In them, you really need that? Or what's the real problem?

They think they want that. It's almost forcing them into an existential are they really doing with their lives as far as their business goes, because they may have actually never thought about what it is that they really need. And I found that to be an ongoing challenge with companies at all coming in to help. And you said this at the beginning where...

you're getting paid and you just ask a lot of questions clients are unhappy because obviously most people want to be told ideas are fantastic and they're doing the absolute right thing and not tried doing the exact opposite thing that you have been doing for an extended period of time? I feel like that's a hard sell for a lot of people.

Elise Stanley Brevald (07:17)
It is, it is. And this is also why it's so important for me to split into what is UI, what is UX, and what is the strategy. Because once you start explaining this, especially if you are internal in a company, when you are inside a larger company

ask just deliver this button to me or can you change this color of the button? I'm just like, why? And once I start asking that why, they need to argument and then I will ask one more time, why?

and in the end I will ask them so it's not because I don't want to do this for you I just want to make sure that we are really solving the real problem. it's about communication.

I remember I was hired in as like UX like to do this big turnaround ⁓ in a larger nine years ago

expected me be the UX expert, coming in, setting the stage, setting the team, show them like, we need to organize like this, I need to have these UX resources, we have these six team development teams. They would be part of my team, but they will be like this virtual team working very close together with engineering.

Warren (08:21)
It sounds like a mess.

Elise Stanley Brevald (08:22)
and they said, what should we do? you I said, do know I don't know. I don't know. And they got so mad You are the UX. So just I am. I don't know all the answers.

we need to go out and actually speak to the users We need to speak to the

Warren (08:39)
I think that's

management innovation I group the engineers and the business into one group, realistically. There's external, your users, then internal, wherever that ideas come from. And then I usually throw in competition because they're not your users, but maybe they one would hope that they did some research, which I don't know is actually the case today. And you can benefit from the outcomes of that research without actually having to go through the

Elise Stanley Brevald (08:46)
Mm-hmm.

Warren (09:05)
process yourself well that can lead you in bad directions especially we see these products that just copy their competitors and they don't actually understand what the core problem is and then five years down the road their competitors fail and they fail too because they didn't understand really what the core problem was and they were just copying someone else who seemed like they were making money and seemed like it was a good idea at the time.

Elise Stanley Brevald (09:11)
you

And I fully agree with you. I really don't like and I don't believe in copy-pasting features.

Warren (09:31)
I absolutely agree 100%. I'm laughing because I think there's a couple of aspects to this. one of them is that you're in a lot of organizations where you're leading and you have this mindset. But I also see the other side where there is an engineering organization and they've been beat down into just doing whatever anyone else says because when they try to ask questions, the customer says,

Well, I need it to be a link because someone else is paying me money to make it be a link. And so I just need you to do this. see a lot of people that just don't have the, it's not necessarily the capacity or the desire to ask the questions, but they are just not empowered to do it.

Elise Stanley Brevald (10:06)
Yeah,

I have seen in other companies is that you have this friction between sales and success team versus engineering.

engineers would sometimes like to speak to the users to actually see, hey, it actually work? The things I was working so hard on, it actually like, did you actually like it? I mean, that's, it's a fair question.

Warren (10:29)
some different flavors of engineers excited by knowing their thing is being used, but then I get I know the other ones that are absolutely terrified of being what I have to talk to a user. I don't want to do that.

Elise Stanley Brevald (10:38)
Yeah,

is back to the we have engineers that really, really don't like this and we should never ever force them into speaking with users. To me, there's so many other people that would like to do it.

Warren (10:51)
but it's interesting you

bring that up though, is because actually and on...

not this episode, one of the, I think the next one actually will be doing on the Dora report for 2025. And the interesting thing about the does actually identify that no matter what role you're in in an organization, you are creating something and there's someone else who is using that thing, which means they're users. No matter what position you're in in a company, you have a user and by not talking to them, you can only be doing the wrong thing.

Elise Stanley Brevald (11:20)
What if you have a whole team that I mean, it's not a one man show building software. It's a team

Warren (11:26)
think there's a couple of different aspects here. The first one is for sure is a middleman problem, a telephone game, where there is maybe a disconnect on delivering information. And so if there is an engineer leading a trying to figure out what to do there, I would absolutely expect them to be on the call. I may not be expecting them to answer every question should be there absorb it in a

Elise Stanley Brevald (11:27)
Thank

we are totally agree because to me what's important is that they should join the call, they should be close to the users and also listening in to the feedback that we are collecting. But I don't want to take a good, like a world-class developer and force him.

Warren (11:48)
Yeah. Yeah.

Yeah.

Elise Stanley Brevald (12:04)
to be the one facilitating the call or force him to ask all the questions

in the previous jobs putting a developer in front of a lady who has been like learned how to use IT and technology being responsible for doing like the monthly salary in a company the gap can simply be like

too much for him. So he can join the call, but he doesn't necessarily really want to ask a lot of questions. I want them to join, but I don't want to force people if they don't like that.

Warren (12:24)
Wow.

Wow, I have like the

complete opposite perspective here, which is just fascinating to me. seen more engineers at every level.

Elise Stanley Brevald (12:38)
Thank you.

Warren (12:41)
be interested in, joining calls or talking with whoever the end user are, irrelevant of the technical complexity of the product they're creating, my perspective is it has to do with the scope and the impact that they want to deliver. So for sure, for engineers who are inexperienced, who have just gotten into the industry, I don't expect them to be able to connect all the dots a ladder of leadership.

Elise Stanley Brevald (12:41)
Mm-hmm.

Warren (13:04)
by the author of Turn the Ship Around, which is absolutely fantastic, that talks about what sort of work are you doing, what sort of level is it at? And I find that the jump into, we'll call it like staff engineer, actually starts being the point for me where you can't get ahead unless you're able to answer business and product related questions. I just don't see there middle ground there where you can just.

Elise Stanley Brevald (13:16)
Mm-hmm.

Warren (13:26)
continue down in an engineering focused approach there. And I think the ones that do make the jump, they know this and that's why they're able to get to principle or higher seen that, okay, in order for me to actually deliver the right technology, I need to fully what the product or business problem is.

Elise Stanley Brevald (13:42)
Exactly.

always bring them in, has them in as many calls as possible. No matter if this is UXs, if this is success people, if this is engineering people, I want them to be on the call. mean, people being responsible for documentation should for sure be on the call. We are hearing about the feedback around the documentation. That's the only way we can really listening in to all the great

end of the day I my employees my engineering team my whole organization to be the one shining And I would love to have them on the call every time What we did

in the startup a couple of years ago when we agreed on that, okay, we are actually growing pretty when you are in these lots companies, you often see this friction or this gap between sales success versus engineering team.

one of the things that was very, very important to me was because I've seen this gap between these silos in an organization.

I promised myself I will never build that silo in this company

Warren (14:43)
I like the perspective of when you're making your own company, which I guess I have some experience doing. You get to take all the great learnings that you've had over the course of your career and bring them to it. From experience though, I see a lot of people sort of making the mistake of... There's a great quote in Jurassic Park too when they're talking about making a new dinosaur island and Richard Hammond did, I won't make the same mistakes.

Elise Stanley Brevald (14:51)
Thank

Warren (15:05)
when making the new was Dr. Malcolm says, no, you'll make all new ones. Because I think there really is this aspect where there are so many things that you can get wrong and just your list of experiences are only like a small part of.

⁓ everything that the organization can do to be successful or not. I love your optimism that you can just go at it. I think maybe there is this magic number here that maybe like 20 or 30 years in the industry and now you've accumulated anxiety or debt of doing it all the wrong ways. You're like, I'm not going to make all the same mistakes if I could go and do it myself.

Elise Stanley Brevald (15:38)
have learned, this is of the reasons

I'm working so close together with the rest of the departments is to prevent us from making of course, you will always have small frictions, small gaps, stuff like that. And especially when we are in this remote first setup. But.

We are not having the silos when it comes to the customers and to me that is super

this is something will continue protecting as much as I can.

when I say in a feature one of the most important numbers that we can measure. Of course we are measuring

What about the loyalty score? What about the satisfaction score? And that's something that we have been measuring from day one in this company.

Warren (16:16)
was

so afraid you were going to say that you measure or optimize for the dwell time of users on a particular page. The engagement score, because that's the worst possible thing. I actually, don't know if that's worse than generic NPS, which a lot of companies use and just isn't a great metric of whether the success of a product or your company is going further. I like the aspect of actually collecting

Meaningful feedback is quite quite better than just asking someone. Hey, would you recommend this operating system to your friend? It's like well, no, I don't often talk about which opera unless unless you're an engineer and then of course, you're probably recommending arch to someone

Elise Stanley Brevald (16:56)
Yeah,

yeah, I'm more into nice food when I speak to my

Warren (17:00)
So one of the problems I've seen in my experience is that the customers where you have the most to learn from are exactly the same set that are most hesitant to share anything with you. it's priorities, often focus is somewhere completely their standpoint in communicating with you. And what I often see is that's the exact sort of feedback that would be helpful in

helping them solve whatever their business problem is. Because realistically, I hate to have a solution which is fully 100 % self-service, because it means it's never changing itself without your metric collection of data. Which, of course, you can do. And you can either do some sort of anonymous user feedback research or whatever, and collect additional data, whether it's happening in your UIs or application or APIs. But realistically, actually getting a better understanding of how the business is working and where their focus is.

tends to be a really hard, challenging problem.

Elise Stanley Brevald (17:51)
what we are doing is that we are granularly rolling out new functionality to users. And even before sometimes we are deciding, should we do some rapid prototyping? Should we try to show some of these mock-ups in front of the users?

I would say in this company that we are building right now, we don't have that issue because what we have been working very hard on is making sure that we cannot sell stuff that we don't have, that we haven't built. And that is a super, super strong culture value that we are really protecting a

So the whole sales organization are not overselling but we are realistic when we are speaking with customers.

problem can we actually help you

the feedback because we are measuring the feedback directly inside the product.

can always leave that feedback to us and then of course good old reaching out to do surveys we focusing a lot on on both the quantitative part of measuring but also the qualitative part

Warren (18:50)
It sounds like you have a very mature strategy for handling sales within the company at every level, applaud you on that. One thing that comes to mind though is that it's good to test the boundary of what you're selling. If you never sell a feature you don't have, then you could be selling more and potentially figure out, that's actually something good that we could innovate on by actually adding it to our product.

Elise Stanley Brevald (19:06)
Yes.

Yeah.

And this is the interesting one because of course we get a lot of insight from prospects. Of course they have needs, they also have problems and we want to understand that better. And sometimes what we have to do as part of the sales process is looping me in or looping in the CTO, jumping on the customer call, really carefully listening into what are they asking for because maybe there's something we haven't seen yet. Maybe this is also a problem rest of the customers has,

We haven't identified that

I haven't mentioned to you yet is that everyone that feedback, customer input, prospects input, it could be something smart, coming up with something, saw something somewhere else. It could be feedback from our surveys, the NPS, all these kind of things

Warren (20:01)
think that having the dedicated spot where you can put in these requests that may align with across multiple customers or even over multiple years, it's interesting because sometimes I do go to ours and I see like, actually we solved this one accidentally via another process. Like we ended up taking care of it. It's early on, we tried to be strict about what direction we wanted to take with a bunch of our products and found that actually the times that we would potentially say no in a meeting, we're just like, we're going to change our process.

Instead of saying no, say, yeah, sure, why not? And then write it down and then see if we change our minds because I think there is a large number of times where we have gone back to it and thought about it we're like, no, actually we had the wrong mentality here. And I think it's a great approach. I think it helps innovate and change your product and have it keep growing in the right direction, which is why, and I really want you to level with me here. Why are there so many bad applications out there? And what I mean is with ones with bad user experience.

Elise Stanley Brevald (20:31)
Yeah.

Warren (20:57)
And I have to know, like do you think that having good UX, is it hard or are people just lazy?

Elise Stanley Brevald (21:03)
I don't know if I really can answer that question, not because I don't want to. I don't know if I can, I can answer like from myself.

Warren (21:06)
Like you can, but you don't want to.

Elise Stanley Brevald (21:14)
To me,

I would never ever like to deliver a product. I would never ever be proud if I'm not deliver a has a world-class

years ago now, ish. I was a consultant. I went into this. It was one of the largest enterprises in Denmark. I was asked to come in and do a on a Not easy, but I had to do it and I managed to do it.

the hardest part was actually that they had this design agency who had so many money. I don't even remember the number anymore, but it was huge amount of the

Like this is the now the new design you communicate on the website, when you are communicating on like in papers and letters and all this kind of things. And they gave it to me and they says, and by the way, you just need to fix that on these two applications. And I looked at them and I says, do you know what? I And they say, why? We have spent so many money. And I say, I can't do

Remember this is a tool for people that will be working in front of this screen eight hours a If I put this primary colors into these screens, you will have a problem with your employees because they will end up not feeling well. You will give them like problems with their eyes because these colors can never an application that you have to look at in eight hours a day.

And they got so mad at me. I a piece of paper, seriously a piece of paper. I colored it in the colors that they were asking me for. I gave it to the management team of this And I said to all of you just look at this now in 30 seconds and then look at the white wall.

was not a nice experience and then they were convinced

Warren (22:55)
there is this aspect where we see much worse things get released. if anyone works in the accessibility space is probably unfortunately familiar with this one episode of the original run of Pokemon, which I think it literally would induce a seizure if you watched it. And it was pulled before making it to outside of Japan. But if you see this and you don't have any sort of epilepsy, I still think that there is some...

Elise Stanley Brevald (23:17)
you

Warren (23:18)
denigration that you will suffer ⁓ by looking at it because it's just so bad.

Elise Stanley Brevald (23:20)
Yeah,

yeah, yeah. are a lot of experiences out there. I just don't want to put my name on an experience that is not super nice. to be honest, I can't talk from the rest of the UX world, but we have like...

At least from Scandinavia and Denmark, have pretty strong design traditions. And you also see that in in furnitures and stuff like that. And I think that's probably why at least I and also I know like people in my community are caring a lot about like high quality interfaces as well. And then, course, accessibility and other things. And I think this could sometimes also be culture related.

Warren (24:00)
I think you're definitely onto something there because realistically, there can just be a lot of people that are in the peak of the Dunning-Kruger curve, right? Where they think that they are actually trying to do the best they can, and they may even be doing that, but they don't realize.

all those issues that come and they need someone like you, Elise, on their staff, leading them and showing them how to actually look at colors on a piece of paper to actually validate that there's accessibility problems with their design or usability issues with their application that they're putting out.

Elise Stanley Brevald (24:23)
Yeah.

Yeah.

I am more curious actually how much do all this new AI, probably take over like a lot of the tasks that we are doing in UX and in UI space.

I'm pretty curious to actually see like what about the accessibility?

Warren (24:48)
Well, I think the interesting thing about utilizing models to design or even build the components for UIs is one of the things that we keep talking about is expectations when it comes to interacting with any sort of visual application. And not necessarily visual, I I assume the same is true for those that are visually if you think about just or audio signals.

we actually want statistically the most common thing for a particular culture, right? Like it may not be synonymous everywhere you go in every single country, but within an area. And so I think this is one of the things where models excel at because they are probabilistic. And so picking the most relevant thing is often the right choice in these areas and trying to go off the curve is problematic. And the other thing is that I think in the years or so, accessibility has become a really huge thing, especially throughout

that we are getting specifications involved where the expectations are codified and models do a really great in translating. so from translating from a spec to the expectation. So I think those things included without any change in technology whatsoever, I think we're at a pretty good height of the creation of UI-based technology.

design of components automatically via the tools and I don't know how much better it needs to get but also that it can

Elise Stanley Brevald (26:04)
think one of the best tools that I have actually been testing out so far was

of surprise for me and I don't know if it's a surprise course I would expect a great experience but I've also been trying other tools where I was just my goodness just asking about like a simple can you help changing this color from like from the purple to blue and then it turns out to change the

whole

screen and adding like some AI text I'm just like no I didn't ask for that I just asked you very specific to change this I think we can get there but sometimes it's also just still faster for us to actually do minor updates at least that's where we are now and maybe if I come back like six months from now we can have a very different conversation here yeah

Warren (26:50)
Well, that's certainly on the table. I do want to just ask about the core functionality of the product that your company is building just to give a little bit of flavor

Elise Stanley Brevald (26:59)
we are working in this feature flag domain,

and what we are focusing on when it comes to the feature flag

either as an team or you as a business can whenever you want to make your features your customers and your But what it also opens up is the opportunity to

to roll out granually and actually faster to start collecting feedback.

also means that I can actually be in customer strategic customer. We can talk about like we are now about to go GA with this or we are now entering a beta with, I don't know, for instance, our release management functionality.

doing the call, I can actually turn it on for this customer.

What we also can do is make sure that we can minimize the risk because we can actually start rolling this out and once we're rolling it out we can actually see the impact. seems to have an impact on our does it break anything in the application and all these kind just

Warren (28:00)
⁓

she said the trigger words there. like the aspect to control access to individual features within the enough though, think using any sort of flags for rolling out software that is untested or to verify that it doesn't break stuff in production creates this sort of pit of failure.

engineers or engineering organizations end up pushing out work that is now untested because they a crutch that allows them to test. And from our own validation and what I've seen at some other companies, they end up in this scenario more likely to break production because of the introduction of a system than to actually do the testing upfront. so one of the questions I actually want to ask you is, how do you encourage teams to

Elise Stanley Brevald (28:35)
Mm. Mm.

Warren (28:46)
have a healthy mindset about not relying on the technology to replace, say, critical testing before actually pushing it out and leveraging this mechanism as a safety

Elise Stanley Brevald (28:57)
as always, I don't have a single answer to this. But one of the answers is that we are working from an MVP the developers are taking the ownership of actually doing proper testing before we are releasing anything.

Warren (28:59)
You

Elise Stanley Brevald (29:11)
We can't have developers who just go to work and doesn't care.

this again is back to like how do we build our organization? How do we manage to build a where it's okay to fail, but it's also okay to learn a lot and also feel safe when you're actually doing this because we could also have a culture where we are pointing fingers of each other and we don't want that.

As an engineer, you're never left on your own. As an engineer, you will always have your engineering manager, you will always have your squad lead who will guide you, help you, teach you if there's something that you are a insecure around.

We still need to have people to review this, but we don't have any dedicated testers. We have people that really cares.

Warren (29:50)
love it. And you brought up like three other topics, which obviously we'd have no time to cover and we'll have to dedicate individual episodes to building a blameless culture and remote work. But I think maybe that's a good point for us to leave off the episode and shift over to picks. So, Elisa, what did you bring for us today?

Elise Stanley Brevald (29:53)
Yeah.

Yeah.

Yes.

Maybe you already heard about this, maybe you haven't. To me this is pretty interesting. Gimini is now UI. Which to me seems very promising.

but also a bit scary to be honest. It looks like Google is really trying to disrupt how we have been building websites and how we have been building products.

And now they are diving into this like we should have individual ⁓ user interfaces. So each individual user will have this like generated UI whenever they have a I haven't read the article yet. I haven't looked too much into this, but I just want to share with all of you. And for sure, this is something that I will need to dive much more into this upcoming weekend.

this is really and can be disrupting

Warren (30:55)
the idea to go to a chat interface or even a voice interface was always sort of going backwards in a lot of applications. And I think this is the necessary piece that reconnects it back. It's like as society picked dedicated interfaces for whatever we're using a cash register or manufacturing bench, et cetera, the tools you have or even the digital widgets you have on your browser.

I think we've realized that those are the best. And in certain areas, we're already doing this without LLMs at my own company, where if there's an incident, we're dynamically generating exactly the dashboard with the metrics you want to see, as well as what code changes were relevant there so that you can go and make a change or do the investigation. I think we already see that there is a huge value in this. I think there is an aspect of getting the right thing out for the user, not just

for the user, in that particular ⁓ incident or issue or whatever their user story is that they're trying to complete. So I see this as a necessary forward path there, where it can only be done because we've spent arguably a huge amount of work in the last 30 years on what is the best UI for a particular user experience that we can have. And without that, don't think we would have been able to, or Google would not have been able to steal that work. mean, we'd not be able to have a

Elise Stanley Brevald (32:09)
You

Warren (32:09)
use research

on that work and provide us a new experience there.

Elise Stanley Brevald (32:14)
Yeah, absolutely. No, but I agree with you and cool that you're already doing this in your company actually.

Warren (32:21)
For some things, yeah, absolutely.

So one of our products is of Slackbot, so we don't control the UI at all there whatsoever, so no ability to change anything. And the other one is an administrative interface, so we don't have to spend a lot of time on user research or building out the UI because it's used in, it's a very technical product.

the UI is used rarely most of the time we're selling an API. So if we need to do things, we care about a very high uptime. So being able to glean into insights, we can spend all of our collective UI and UX juices on designing the best internal monitors that we have. So innovating there is really something we have to do.

Elise Stanley Brevald (32:55)
Thanks.

Warren (32:58)
Yeah, okay. So what did I bring today? I had one pick, but I think I'm going to change it based on our conversation. There's a great website run by a couple of UX researchers called growth.design. I'm sure you've heard of it. They have like 30 or 40 different case studies where they went through different applications or UIs and basically tore them apart. Like what's wrong with this? And not just like what's wrong with it from a user standpoint, but like looking at it through the eyes of a business. It's not just like,

user would think this would want to be different but realistically as a business if you want to make money or capture engagement etc like what could they have changed and should they change to make that happen and they are really well done every single one of them they do like tick-tock and Airbnb and stuff like that and I think every single time one comes out it's is a good introduction to what UX design goes through but also even if you are experienced like just learning about another new interesting

bias or value being utilized or abused by certain companies to get you to do what they want in their app.

Elise Stanley Brevald (34:01)
truly agree with you. We cannot have like UX cannot stand alone UX is part of like the bigger picture. It's just a piece in the puzzle. and we really need to to better understand.

Warren (34:13)
were actually able to take insight from Growth.Design and something that we were doing. They had a whole case study on optimizing the login flow. If someone signs up and you get an email to your inbox, it used to say forever, yeah, go open your email and click the link. And they're like, that's dumb. You should at least figure out which provider they're utilizing and then automatically provide display buttons so they can click on the appropriate one.

and go to that page. we're like, why is this just research? We're an off provider. We could just make these buttons, make it automatically work. And so now we have a whole part of our application which automatically uses the MX records to figure out which email provider someone is utilizing and then automatically redirect them to their mailbox to click the link because getting stuck on this screen is just one of the worst user experiences ever. And I really thought this was quite insightful.

Elise Stanley Brevald (35:03)
Absolutely and it will absolutely not help your conversion rates so just go fix it.

Warren (35:07)
it's really bad. they're

talking about even having the right buttons there, like boost the conversion rate by a 30 % extra on top, which is amazing to start with, and then taking it the extra steps that we did has just been such a game changer in a lot of ways. ⁓ hesitate to bring up that new topic here, so maybe we'll stop here for the episode. Thank you so much, Elise, for coming and joining with us today and talking about everything there is to do with UX.

Elise Stanley Brevald (35:19)
Yeah.

at least part of it, but yeah, thank you for having me. And then we can always continue diving even more into this space and other spaces as well. Thank you.

Warren (35:33)
Yeah, absolutely.

We may need to get you back on the show. And thank you so much to Incident.io for sponsoring today's episode. thank you for the listeners. And hopefully, we'll be back again next week.