Strategies In Building A Mature UX Environment At Workday

Ailsa Zircher at UXDX Community: Ireland. Video: https://youtu.be/SqKj3kufxGA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction: the space I work in

[00:00:05] Thanks very much for joining. My name is Ailsa. I've been working in UX and design for about ten years now. Probably I stopped counting about five years ago, so I don't know what that says for my math skills, but I've definitely been working in the industry for a while. The last five companies, I've led design teams in different software companies. At the moment I'm working at Workday. I joined a year ago.

[00:00:30] Workday is an HR and finance software company. Most of our clients are medium to large enterprise. Me and the team that I work with, we don't focus on the Workday applications. We work on a mobile backend service. It's the experience of deploying customers to Workday, so it's kind of like a backstage space that designers don't normally go. Our end users are professional users. They've been trained how to use our tools, the deployment teams.

[00:01:01] It's a complex space and there's an awful lot of interdependencies, and some of the projects they work on go on weeks, months, if not years. So there are challenges to the designers in terms of understanding the interdependencies, and there's an awful lot of technical jargon as well. I suppose I'm kind of highlighting the complexity of the space because I wanted an excuse to show you my complexity graph. So the problems we're solving, they're not right up there with climate change problems, but they're not as simple as getting a haircut during the coronavirus either. We're kind of in the middle. Think of it more like we're trying to solve a problem like how to entertain your child during the coronavirus when you have to work.

[00:01:43] And speaking of which, my child is beginning to develop her imagination play, so when I'm not working I'm forced to play baby, or worse still, pretend to be the daddy dinosaur who has to change the baby's nappy, the baby minion, or even worse still, her latest game is pretending to be a slimy worm, and guess who has to be the slimy worm.

How the Workday design team evolved

[00:02:06] But back to Workday. I want to just give you a little bit of context of the Workday design team and how we have evolved until now, before I start talking to you about some of the strategies I'm trialling. So Workday was founded in 2005. Quite early on the leaders differentiated themselves from the other enterprise solutions by saying that we're going to focus more on being competitors to consumer-based applications. It's a new breed of enterprise software on the cloud.

[00:02:35] And from there they heavily invested in the design team. By 2015, with a strong design team, we were directed to show the value of early concept designs as well as the usability in downstream work, and we reached a milestone this year by hiring a VP of design. So there's about 150 of us in total at the moment, and to us we feel like that's a pretty sizable, meaty team. We've got our design operations in place, we've got two juicers[?], we've got design education, we've got a design system. We're feeling quite strong about who we are and where we are today.

[00:03:08] But when you just take a moment to step back and look at the org that we're serving, this is a 2,000 product org, and that's not even including the technology org. And when you look at Workday overall there's 12,000 people. So suddenly we start feeling like, where am I? You could say a small fish in a big pond, or how I prefer to think of it, more like a baby shark. I'm just going to leave this hang for a minute to make sure that gets ingrained in your mind for the day.

[00:03:45] But all right. It's not just the fact that we're serving and we're trying to influence and provide for a large organization that also has, I suppose you could say, mature software and supporting systems. There's also the challenge of the industry. The needs[?] are growing and the expectations of users are increasing. Just like you guys, you expect to be able to just book your holiday at the weekend, and to us that means zero downtime. We expect HR and the financial system to be integrated, so if you achieve your quarterly goal that you will get the bonus automatically, well, hopefully.

[00:04:22] So the expectations of the prospects are also getting higher. They want this type of software to come in and transform their business. So design is becoming more and more important in our industry, and for Workday ourselves it's becoming more and more important that we operate at a higher level, that we're still able to support the downstream user flows, but we're also able to get the user represented at business level decisions.

[00:04:53] So internally we're looking at different strategies that we can trial, and there's one that I want to talk to you about, and I'm going to give you some practical tips of what you also can do in house if you'd like to try it out. But first, what I flipped to my team, and what I'm also suggesting to you, is just be open to considering the role of the designer. What is the role of the designer?

35,000 decisions a day

[00:05:12] But first, a quick question. What happens 35,000 times a day? I know what you're probably thinking, it's the amount of times Matt Damon was spotted in Dublin. I know, Mary saw him in Dalkey, and he was in the steakhouse, and he was up in Seapoint swimming. So it may feel like we've seen him 25,000 times a day, and we'd probably even like to see him 35,000 times a day. But it's not actually that. It's that we make 35,000 decisions daily.

[00:05:48] That's a huge, huge amount. There's a big scale. The big future decisions, you could think of who we get married to, where we decide to live, whether we decide to watch Ozark or Tiger King, or maybe liberals[?] before we sit when we're working from home, whether we have a drink of wine, maybe one night of the lockdown, every night of lockdown.

[00:06:08] But my point here is these small decisions, or at least some of these small decisions, they have impact, they add up and they impact your life experience. Do you have a pain in your back if you're sitting? Have you drunk a little bit too much wine, maybe every night, possibly, like me, and you're starting to get the fear? What I've heard people talk about is the pandemic pound. Are you not doing your exercise and choosing wine instead?

[00:06:36] But I'm not here to talk about wine and exercise. I think another good example is even this conference. This is a small decision. You had other things to do but you decided to come to this conference, and that decision in itself won't change the course of your life experience. But if you consistently make these small decisions to stay up to date in the industry, to catch what's going on, you're going to start getting new strategies to bring to your projects and the initiatives that you have, and that's going to bring new opportunities to you. All these small decisions add up to create your life experience, some of them obvious and some less obvious.

The experience is the result of everybody's decisions

[00:07:14] And the product experience that we are working towards is exactly the same. It is a result of so many decisions, some obvious, that we know are design decisions, but some less obvious, made all around us. There's the classic one that we as designers make: what should the user flow be like, should it be one step or two steps? And then there's the broader decision about the user segments that we're going to go after.

[00:07:38] There's the engineering decisions about the performance: do we let the user wait three seconds to load that table, or do we address that performance issue? There's the business level decisions about acquisition: do we acquire that data analytics platform and help give effective insights? And then there's more specific decisions on the ground about call to actions and how do we guide the user through the flows.

[00:08:02] The experience that we create isn't a result of just our design decisions. It's a result of all the decisions made all around us, and if it's a good experience it will be the result of many good decisions made. So design is a team sport. We as designers don't drive and make all the decisions, and we'll create the better experience if, just like I said, everyone together makes higher quality decisions.

[00:08:31] There are some classic decisions that are more user-focused, whether we display data in a table format or in a dashboard, and there's some design decisions that are into the technology a little bit more, the performance, the load time for example. But the main point I'm emphasizing here is that a good decision needs to take into account the business, the user and the technology.

[00:09:00] Take for example Google Glass. They brought business and technology value, they had that nailed, but they just didn't consider enough of the user needs. Users couldn't find a reason to use the Google Glass. And Theranos: did they consider the user needs? So you guys probably know what Theranos is, the company behind looking at how to do a very quick blood sample test, from one drop of blood do a whole range of your tests. So did they consider the user need? Absolutely, they nailed it. Did they have the technology, the engineering, to back it up? They most definitely didn't.

[00:09:40] What happens when you over-invest in one area and you don't consider the other? Well, in this case we're going to find out this August, she has her court case coming up. So I just want to lay down this point, because I know the concept of design being a hero is long gone, we know we don't make design decisions alone, but just to really emphasize that the design and the experience we create is a result of everybody's effort. We succeed if everyone is making the high-quality decisions together.

Have we really got the team sport?

[00:10:15] And as designers, we know we've got this right, don't we? We just thrive in collaboration. I know in Workday we really put a huge effort into being at the forefront of this collaboration, design. From working on project briefs in the early stages, highly collaborative, we make sure we bring the project teams into research or analysis workshops, highly collaborative. We even run design workshops where all the team including engineers, architects, whoever would like to get involved, actually works through the solutions together. So it's very easy to think that as designers we've totally got this team sport already.

[00:10:55] But I'm noticing internally, and I also wonder is it the same in other places, but have we actually got this concept of designing and creating everything together with business, technology? To get UX involved is a huge effort and puts a huge strain on us. We have to make decisions like, do we focus on the user flow and getting involved in that, do we support the engineer just before the release to production? Sometimes we even ask ourselves, are we actually working on the right initiative, is the initiative itself solving the right problem, should we have been involved earlier on before we decided to greenlight this initiative in the first place? So the feeling of knowing decisions are happening all around us, and knowing that we need to be there to represent the user at all different levels, puts a strain on also trying to figure out where we need to focus.

The day my only designer resigned

[00:11:48] So bringing it back to the org that I support. About seven months ago a designer in my team, he was the only designer on my team at the moment, I was only in about three months, he asked to talk to me and we went for a walk in Smithfield, had a cup of coffee, and he told me that he was leaving, he had handed in his notice. I just remember that day so clearly, because I'd only been in the role three months. I did have a couple of open headcounts at the time, but the org I was supporting, there were so many different initiatives going on, and like I said the space is quite complicated.

[00:12:26] I wasn't anywhere near the level of understanding which of the tools we're developing was actually answering the user needs, which were the ones with duplications, where more chaos was being created. But I did know that a lot of the decisions were being made without that user-focused lens. The simple things, like words that just didn't make sense, that were quite technical, or information that the users were looking for that was like ten clicks away when we could have just surfaced it initially. I'd only a superficial view of what was going on, but I knew that there was so much need for design representation in all these initiatives that we were working on.

[00:13:06] So as I started hiring my team I started thinking about what the strategy was that we were going to try out in the team. There's the usual one where we just go for focus. I could pick two of the initiatives, put the designers and the researchers that I knew and brand new in the roles that I had hired, and just go for delivering great quality in those two areas. Or the other approach is just to support everybody a little bit, just address maybe the usability concerns, either the content or the guidance throughout all the tools, just a little bit for everybody, which in Workday we call the peanut butter effect. Most people don't get value from us, except me, which I love, I tend to love peanut butter.

Pass the ball

[00:13:53] But anyway, I stood back and I started thinking about what the strategy is. If design decisions are being made all around us, and a good quality decision requires business, the user and the engineering perspective, the challenge I asked myself is, how can I get the user represented in all those decisions even if I don't have that headcount to just automatically assign a UX resource to these areas?

[00:14:19] And that's led me and the team to trying out a new strategy called pass the ball. So if design is a team sport, we started looking for opportunities where we can pass the ball, and the ball here is standing for the user information, the user insights, letting other people understand the user perspectives. So the fact that we could pass them the ball and they could run with it, meaning that they had the information and the context they needed, they would continue to make their own decisions but they would bring that context of the user to them, and that ups the quality of the decisions.

[00:14:52] So over the last year, and a few the year before as well, I kick-started a lot of initiatives under this concept of a pass the ball approach. But what I'm going to do is just deep dive into one of them to talk to you about it, so if it's something of interest then you can try it out in your company.

The Improvathon

[00:15:16] So it's the Improvathon. Last year we organized a week-long event with the product org that I was supporting. There's about 80 devs and 11 PMs across two locations. The idea was it was a week long where everyone downed tools, stopped working on their own work, came together in the two different locations to learn and understand the tools and the experience we're building from a user's perspective, and then they had two days to self-organize and make any improvement that they can do from the user's perspective within those two days.

[00:15:53] So it's Improvathon, because if we were only focused on those minor improvements, but the goal was to change the perspective so that people themselves, the engineers and the architects, had the context of the user when they were working on the features. And on the first day we did an empathy session. This was the first time that some of these guys actually even heard from the end user. Like I said, some of them were working on such back-end stuff that they didn't even understand or have that information as to how their code related to a feature and how that related to a user doing a task, what the user was actually trying to do at the end of the day, and most importantly that the user was actually just a normal human being. Sometimes we drift from that.

[00:16:36] So we mapped out personas, and then that flowed into everybody learning how to use the tools, specifically how to complete the tasks that our end users actually have to complete. So it was a day and a half of learning, going through and completing the basic tasks, and this again was the first time people could see how their code related to what the user was trying to do and accomplish.

[00:17:01] And day two was when people were going through this experience. They were noting down on the post-its all the problems and all the ideas they had or the barriers they bumped into going through these tasks. So by the end of the total two days, both rooms were just covered in hundreds and thousands of post-its, which is probably normal when you work with UX anyway, there's always too many post-its.

[00:17:24] So on day three, four and five the guys self-organized into teams to ideate, design and develop. So people just pulled post-its from the board, a problem or an idea that they had that they wanted to work on, self-organized, they themselves would be brainstorming, doing the design, the ideation, sketching, prototyping. We had our end users walking around the room as well as UX, so they would be pulling in the end users and getting feedback. But what I'm emphasizing here is that UX was facilitating the experience, but it was those guys that were deciding what was the most important things to go after, doing the prioritization, doing the design thinking, the design process, the iteration.

What came out of it

[00:18:07] And just to make it a little bit more understandable, I'm just going to give you a couple of examples of the kind of things they were working on. And I do want to emphasize, these were just minor changes. In this example we had pagination. There was a feature at least two years ago, and let's just say there were eleven pages people need to paginate through based on the customer data, but if people viewed it from the wrong browser or a different device the pagination just disappeared. And this is something that people used thousands of times.

[00:18:38] One developer spent five minutes fixing the pagination. He changed it from like a fixed height to relative height and boom, it was fixed. And when we showed that to the customer, the customer said they nearly cried. Imagine, the professional user has to go through this every time and just works around it, and somebody had to fix it. So such an easy thing to do from a code perspective. It's just having the perspective to understand that this is actually such a blocker for the user.

[00:19:08] And another simple example was this graph. When people visited this feature, the graph loaded by default, but on average this graph took about three seconds to load. But we found out that ninety percent of people always clicked the list view. So they wait for the graph to load three seconds and then they click list view. Again, a developer just changed the default to the list view instead of the graph view, so that saved three seconds. And they do this task 11.5 million times a year on average, so just adding up that time, that saved about 1,003 hours[?] of effort.

[00:19:46] So these small changes really added up to time saving, and the reason why I'm emphasizing time is because that's what this project team measures. Their OKR, our goal, is to reduce the amount of time it takes to do these tasks, to get the customer live earlier. So time is the metric we're measuring against.

[00:20:05] So within the full week the guys and us, we brainstormed thousands of ideas, designed and iterated on over a hundred, developed 41, demoed 37 and shipped 20. But like I was saying earlier, obviously each of these initiatives and each of these ideas did take a sizeable chunk of their time to implement, but the real main value that we got from it was that mindset, the fact that everyone had a perspective now of the user, what they were trying to do, what they were trying to experience, and they can bring that to any of the decisions they make moving forward, which then frees up the design team to make a bigger impact across the space and even have time to focus on other initiatives as well.

[00:20:58] So the Improvathon, like I said, it's turned into a biannual event for this project team. We got enough value that we're going to keep it going twice a year. I'm already seeing that focus continue, because like we said there's lots of initiatives happening at the moment that we haven't resourced from a UX perspective and they're still bringing that user-focused lens to their decisions. I'm also scaling it, we've run one already that's across a slightly bigger Improvathon.

Recap

[00:21:25] So just to recap what we've been talking about, and I guess my message to you guys is: designers don't own all the design decisions, it's a team sport. Design decisions are being made all around us, and the more we can lean into that and help everyone make better quality decisions, the more impact we'll have. We really feel this challenge in Workday and I'm sure you guys feel it as well, like how can you be there to support all the initiatives, the user flow, the usability testing, but also help influence business level decisions, getting the user represented up there.

[00:22:00] A bigger UX team isn't the only strategy, or not even the best strategy. So I'm asking all of you to think about how you can scale your operations, and if you can pass the ball of information and user insight to other people in your team to go ahead and make decisions, you'll be sure to scale the impact that the design team has. That's me.