Crafting Digital Products for Connected Appliances and Other Stories

Alexis Macleod at UXDX EMEA. Video: https://youtu.be/FKJ6emJIwoU

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: highs, lows and acronyms

[00:00:00] Alexis: All right, I'll give you time to shift. I feel like there's a shift happening in the room, so I'll give you a moment. Bathroom breaks, it's important. People, stay hydrated. Okay, you all good? Nice. Then I'll kick off.

[00:00:42] Hi, I'm Alex Macleod. I'm the design director for connected experiences at Electrolux Group, and I'm very happy to be here at UXDX 2023. I'm going to tell you a little bit about the digital transformation journey that Electrolux Group has embarked on, a little bit about my role in it, and I'll take you through the highs, the lows and the acronyms that we have encountered along the way. Because there are a lot of acronyms. You all love acronyms, right? You down with that?

[00:01:18] And I know you all love a pithy takeaway. That's what you come to conferences for, so you can get the takeaway. I will finish with three things that I believe it takes to build great digital products in the context I'm in.

[00:01:31] It's also featuring design, because I am a designer. Sorry. Well, I'm a UX designer, which is why I'm using that beautiful handwriting font. That's for all you real designers in the audience to go, "Oh, why is she trolling us with that?" Wherever you see a little star in the corner, I'm going to be talking about design, and if you're not interested in design because you're product or tech, then you can just look at your phones when the star appears. It's a handy signifier for you. You're welcome.

Building digital products in a 100-year-old manufacturer

[00:02:03] When you start out to build great digital products, you think about companies like Slack and Spotify. If you're doing that in a startup context, it's a blank slate. You can set it up however you want. If you're in a scale-up, you've got some established ways of working, which you might have to readjust, but it's in your world, it's in your grasp. But when you're doing it in an established corporation, particularly one that's a hardware manufacturer, there is no blank slate. In fact, there's no precedent for building digital products. But there is a precedent for how we build hardware products, and that may conflict with the way that you think is the best way to build digital products, because it's very different. You're in a context which is maybe not in your control.

[00:02:55] This is my context. I work in a manufacturing company that's over 100 years old, and the history is in manufacturing, and that means absolutely waterfall throughout. It's so waterfall you wouldn't believe it. It's the most waterfall waterfall ever. It also means that they can launch things into the market and then it's just, "Bye, see you later," and they never have to go back to it again. They can make every single one different, and it's fine, because they don't have to revisit it in the same way. Whereas we know that when you're making digital stuff, once it's launched, that's just the beginning of the wonderful journey of digital products. It's quite a different mindset to reconcile.

[00:03:43] There's no real intention to standardize the user experience on hardware products once they've left. Of course, you want things that are usable; that's a standard. But they don't necessarily have to be usable in the same way. It's a pretty big company, in lots of markets. So how do you build great digital products in this kind of context?

[00:04:06] This is a screenshot of our head office, and I always like it when there's an error on the internal screens. They should be showing brand videos, and instead they're just showing, "Oh, you haven't clicked on the thing, people."

[00:04:18] One way to approach this problem would have been to optimize the approach based on how the organization works. We could have gone to Electrolux and said, "Okay, how do you do these things already? Let's try to work with that and slowly nudge you towards being a bit more digital." That could work, but it's hard to sustain and it's really, really, really slow. And we don't have all the time in the world. We're people who like to do stuff. So instead, we started with what we believe is the right way to build digital products, and then we tried to do that, and find ways to do that within the context of this environment.

Why connect a washing machine to the internet?

[00:05:03] Lots of appliances, and a subset of these appliances are what we call connected. That means they've got a little Wi-Fi module in them. The question that people always ask me is, "But why, Alex? Why would you connect your washing machine to the internet?" Of course the answer is: why not? Because you can. But no.

[00:05:23] The use cases for connectivity are primarily, well, for what we call our wellbeing appliances, which are air conditioners, air purifiers and robot vacuum cleaners, the use cases are pretty clear. If you want to see where your robot vacuum cleaner has cleaned, then you probably need it to be connected to the internet, and then have an app where you can track it. Again, with an air conditioner, you probably want to switch it off when you're not home, and maybe it's nice to set a schedule. Again, you probably want to do that on a mobile phone. You don't want to be doing it on the UI of the air conditioner, because it's up there, and it'd be super annoying. Those things are fairly clear, I think.

[00:06:03] When it comes to laundry appliances, maybe it's not such a strong use case to connect them. But when you think about things like an appliance that can run when electricity is cheapest, or when water rationing is not in place, you start to see that connectivity can play a sustainability story there. When it comes to things like hobs and ovens, you're thinking about sophisticated appliances with quite nice features that people tend not to get the best out of, and again connectivity can help guide or educate people. The classic thing is that people buy steam ovens and then never use the steam function. Like, never. And it's like, well, maybe we can help you use the steam function. Maybe that would be cool.

[00:06:48] There's also this use case, which is the main thing as well: keeping the owners of these appliances informed about maintenance, and being able to keep the appliances going for longer. And then there are fridge-freezers; that's probably going to be more about food storage and preventing food waste.

The app as a conduit for transformation

[00:07:09] Right now, we need an app in order to connect appliances to the internet and be able to extend the UI of the appliance and give more interaction to the users. But it's not just an app. Apps are part of what I do on a day-to-day basis, but the app is a conduit for helping us bring digital methodologies and ways of working into this large manufacturing environment. The app is just the starting point. It's a manifestation of the digital transformation, but the transformation affects everything: team structures, tools, ways of working and culture. Dovetail was just mentioned; we use Dovetail and things like that. These are not things that would be used by some of the more established teams working on the hardware side.

[00:08:00] We're moving from a world dominated by electronics and hardware to one that's more digital, and that is uncomfortable. This is not a natively digital environment.

[00:08:10] Project to product: it's a theme. But we can't ever get away from projects in our environment, because there will always be these appliance projects that are delivered over a two-to-three-year period. We never get away from that. It's more about coexisting with these projects in a way that allows us to be successful. But what we always have to talk about is the fact that we're launching products which are going to be iterated over time, and that blows some people's minds a little bit.

[00:08:42] Agile. Just as we're reconciling products with projects, we also have to reconcile agile ways of working with the waterfall world, and we have to do that in a respectful and collaborative way. We have to sit down a lot with teams who are working in these ways, understand how we can work together, and where we would need to see change on both sides, or sometimes just change on their side, I know. But we also have to think about that in a collaborative way and understand why people have to do what they need to do.

[00:09:16] We're asking a traditional organization to be okay with more uncertainty. We're like, "Yeah, we think we're going to try this thing, and if it doesn't work out, we're going to try something else. They're called hypotheses. We do all this stuff." And some hardware people are like, "You're crazy." They've actually said that to us sometimes.

[00:09:39] It's also hard in an environment where, particularly with a large established R&D, they are experts, and they believe in imparting the expert knowledge at different points in a project process. That's very important to them, and it makes them feel really secure in what they do. And we're saying, "Well, we don't always know. In fact, we might change, and we might want to do something differently, and we might want to go back and reassess those things." These things are very hard in this kind of environment, because it's not natural to it.

[00:10:12] Also, a very large manufacturing company has a lot of regional business areas, as they're known. Working in regional business areas does not get us to where we need to be with digital products, because digital products are expensive to produce, and they need a centralized team that works on things that can go global. Again, this is something that is uncomfortable for an organization like this. They prefer to have a lot of stuff in the regions, as opposed to in a global central team. But there we are.

Starting small with two appliances

[00:10:45] How do we do this? When I joined Electrolux in 2019, we already had quite a few mobile apps that controlled various different appliances, but it was quite a scattered, fragmented app landscape. We picked two of our favorite appliances: our robot vacuum cleaner and our air purifier. They're little data machines. One produces information about what the air quality is like in your home, and the other maps your home and has a whole relationship to the floor in your home. We prototyped the whole way of working that we wanted to do with these two appliances.

[00:11:23] We chose these specifically because we thought we could get the most out of those experiences. But also, these are what they call small domestic appliances. Things like washing machines are called major appliances, and we didn't want to go to major appliances straight away, because that would give us a load of headaches. We needed to give ourselves a little corner of the business where we could experiment in peace, and these appliances allowed us to do this.

[00:11:53] We did so with some key principles. I just want to say we have lots of principles and ways-of-working documentation. We have a whole handbook, which I'm not going to show you all of now. But this one, I think, speaks for itself. We wanted to always really do less, and not try to have too broad a remit from the beginning. We always focus on fundamental things, everything from the information architecture to the app startup time. It's always about building a baseline experience before we try to do anything fancy.

[00:12:26] And we wanted to create a heartbeat. Every two weeks we have an all-hands, every two weeks we release the app, every two weeks we have sprint demos. This is what we do, and we always do it. Again, very different to an organization that works in different phases of projects.

[00:12:46] We were also co-located. Can you see how happy this developer over here is to have a designer sitting next to him? Look how happy he is. They're just so happy. When we started our journey, we were all co-located in beautiful Stockholm, with a fantastic yellow wall at the back there. We were looking at these pictures again for this presentation, and somebody said, "I don't remember that wall being yellow," and everybody else was like, "How could you forget that yellow wall?"

[00:13:19] At this point, because, as I say, we were just working with a couple of appliances, we could put all of our stakeholders in one room, which made life a lot easier. We could talk to everybody at once. We even got to experiment. We actually started running a pay-per-use robot vacuum cleaner scheme, where you could rent the appliances from us, all using refurbished appliances, which was great. We even just had them in the office with us, because they couldn't give us any warehouse space. We literally had piles of robot vacuum cleaners everywhere. It was pretty basic, but we could try stuff out, which was really nice.

[00:13:59] We could not only do usability testing, but also have everybody in the usability testing. These are all developers sitting in one of our usability testing sessions. We did all kinds of user research as well, but specifically usability at this point. We had user research included in the organization from day one, to allow us to do that. This was great, because it built us a culture of engagement, not just for the design team, but also for our development teams, because a lot of them hadn't done this before, really sat and got to see user research. And also our stakeholders. We were able to use user research as a way to help build this collaboration.

A cross-functional team and a new design vocabulary

[00:14:40] Traditionally, in a large hardware company, design is a design team that sits in the various different business areas, and they're used as a service. They provide designs at a certain point in the hardware development process. We wanted to make sure that didn't happen. We're working with a cross-functional organization, which is led by a leadership trio of myself, a tech lead and a product lead.

[00:15:09] Oh yes, and we're also having a design moment, aren't we? This is what the design team looked like when we first started. That's myself as the UX lead. We had one software product designer, a UX researcher, and we had half, which is why Max is only showing half of his face in this picture, half of a UX writer, because the other half of him had to be given to the web team, of course. We were sharing him. This was deliberate right from the beginning: equal amounts of research and design, and as much writing as we could get. It was a real MVP team.

[00:15:51] As you can also see, we were making sure that we weren't using the language that was typical in the organization. Of course, people had heard of technical writers and copywriters, but we were like, no, this is UX writing. It's different. Special. Better. And of course there are market researchers, and we've got usability testers, all of that already in the organization. We were like, no, this is this UX researcher person. And we weren't calling ourselves UI designers, because that was to do with the appliance UI, and we wanted to differentiate ourselves. The job title for this one was not so successful. Cliffhanger: we'll come back to this one later.

[00:16:33] And tools. For some crazy reason, we moved from Sketch to XD. Again, we can come back to that one later. If we don't fail, we don't learn, right?

Launching remotely through COVID

[00:16:49] Now, I'm wondering if this year is the last year where you can put a COVID slide in. I don't know, any votes on that one? But basically, of course, COVID hit us. We were all co-located, and now we were socially distanced as well. This is what COVID looked like in Sweden, by the way: we could actually still hang out together a little bit. Sorry. But we were already using a solid digital setup, so the move to remote working was not the worst for us. But it meant that, when we launched the first version of one of our apps, we had to do it online, in the App Store, and release this version. Wait for it. We are live.

[00:17:45] Just to say, we don't do it like that anymore. It's all automated now. But that was the first time we did it, and we had to do it online on a call, which was a bit sad, considering we'd been going on so much about how we had to be co-located and all together. Then we actually came to one of our first significant things, and we had to do it remotely. This is what a remote launch celebration looks like. This is Daniel, VP of product, and he says this picture is so sad. It's just him with a little champagne glass. But Martin, the guy who was launching, wore a suit for this, even though he was online, which I think was excellent.

[00:18:24] We were getting stuff done. We moved from apps that supported individual appliances, one app per appliance, to what we call ecosystem apps, which support several appliances. We were supporting more brands; we've got quite a large number of brands that we have to support. We were getting from apps that had pretty much no data or instrumentation in them to ones that had some. And we moved from this, which is what the UX of the robot vacuum cleaner app looked like when I joined, to this, which is what we were moving towards, which you can hopefully agree is a slight improvement.

Scaling the approach

[00:19:04] We considered ourselves successful at this point. Never be too successful, though, people, because then you have to scale. So then we had to scale. We scaled our approach to all of these different types of product, not just the robot vacuum cleaners and the air purifiers anymore. We went from two product teams to way more [?]. We bigged up our leadership. We got very diverse. More locations, because why not? More time zones, again, why not? Which meant we really had to embrace hybrid life, hybrid working.

[00:19:43] Everything is now on Teams. Yes, there are some things the corporation will make us do, which is to make us use Teams. There are some things we can't get away from. And we spend a lot more time in these. I don't know if anybody else in the audience spends a lot more time in booths than they used to. You always have to be sitting in a booth, even though you're in the office. I spend a lot of time in booths.

[00:20:02] And of course we always got more acronyms, because remember, we love acronyms here. We already had a lot of acronyms, but now we were bigger. Everybody knows this one, right? What's a QBR? Quarterly business review, thank you. You know this one. And look, we've even got the T-shirt. I know, right? This one, anybody know this one? This is big room planning, which is taken from the Spotify model. The idea is that you have quarterly planning in a room together. Our big room plannings went from big to bigger to bigger to very big. They're like little conferences now. This is how we get together every quarter, physically and also hybrid of course, to plan better.

[00:20:49] Also, personally, I got invited to join the design leadership team at Electrolux, which previously I wasn't a part of, but now I was, so I got to do that.

[00:20:59] And this is what the team itself looks like. Getting bigger all the time, growing to support three product areas. We've basically got a full-stack design team in each of the product areas, and they work to support all of the teams within the product areas. We had to scale all of our ways of working, which was fine. We're working on our design system, so we're scaling that; always be scaling design systems. And making sure that we still get to collaborate and have team sketching sessions as often as possible.

[00:21:37] And back to the job title. "Software product" didn't really work, so we're going with "digital product" now. I'm just rolling that out. I don't know what you'll think; you can tell me in the comments in the thingy. This is another big room planning. And yes, of course, we moved to Figma. What else were we going to do? Not move to Figma? Of course we moved to Figma.

Localization, brands and design tokens

[00:21:59] The apps that we work with are now in 91 countries, which is quite a lot, and we support a lot of languages. The .5 is Swiss German, because we just have a little bit of script that swaps out the double s for the special s. That's how we do Swiss German, in case anybody's wondering. And we've got this nifty tool now, so we can publish the App Store screenshots into the App Store in all the different languages, and they're actually taken from the app. It's pretty cool.

[00:22:33] Now we're supporting a lot more appliance categories, as I said, and we've added another brand. We now have Frigidaire, which is our North American brand. We need to think about the brands more. We have essentially the same information architecture, and certain things are brand agnostic, but we also have to work with different brands for the visual expression, using design tokens of course. We've got a supercharged design token system that we use for everything from color and typography to corner radii, and we're going to extend that to things like opacity in the future. We also had to upgrade our tokens ways of working, which meant we had to move from two Labs [?], which was a cool little plugin, to Tokens Studio.

[00:23:32] We're cleaning up some of the fragmentation that I talked about at the beginning. We're going to be moving from multiple apps into these three key apps, and we're getting a lot more data as we do so, which is fantastic. And we are making our users a little bit happier. I don't think App Store ratings are the most important thing, but it is very nice, of course, when people enjoy what you're doing.

[00:24:00] My journey at Electrolux started with transforming our connected app experience, but it's just the beginning. We're now moving into a much broader program of digital transformation to do with ways of working, and maybe also extending this out to our appliance UIs as well.

Three takeaways

[00:24:17] But I promised you three takeaways, so here they are: three things which I believe are what it takes to build great digital products in my particular context. The first one is: stick to your principles. It's important. If you believe something to be important, then you sometimes have to fight for it. But also, you have to work out what your principles are. Second: start small and scale. I can't emphasize this enough. If we had tried to go in at the beginning to do what we're doing now, we would have totally failed.

[00:24:53] And it's all about the ink. It's a little-known fact that the more tattoos your team has, the better your products will be. I promise you, it's a total guarantee. And this is only a small selection. There's a lot more ink than this in our teams; I couldn't get permission to photograph everybody. There's a lot more ink than this, and it's really, really necessary.

[00:25:17] But no, it's not really the ink, though we do like the ink. It's fika. Does anybody here know what fika is? Fika is the Swedish tradition of having a nice cup of coffee, coffee not tea, because they're Swedish, and I prefer tea, and having that with some cake, sitting down and talking. It's a wonderful time for team collaboration and discussion and everything. Fika is really the thing that fuels... no, not really. But fika is very important.

[00:25:45] Twinning. When your team is so in sync that it starts to wear the same clothing, then you know that you're winning. That's when you know you're really doing the great stuff. No, it's not twinning, though twinning is fun. It is, of course, the people. Without the people we are nothing. It's about these wonderful people who can build wonderful things, and about really building that culture and having those people around you. I just want to big up the people. And that's me. Thank you very much for your time. I appreciate it.

Q&A

[00:26:20] Host: When you were trying to move all these parts and you weren't part of the design leadership team, what were some of the unexpected challenges once you got added and were able to scale your team up to the leadership team?

[00:26:32] Alexis: I think you come in and you have to understand where you connect with people. And actually, you know what it is? It's a respect for research. I think the one thing that design really aligns on is that respect, and how research can be brought into it. That's actually something that really drives all of those engagements: how can we get the best user insights into what we're doing? I think all design leadership teams are actually, secretly, nerdy user research teams.

[00:27:03] Host: Wonderful. Okay, let's dig into some questions here from our favorite person, Anonymous. How did you measure UX success?

[00:27:12] Alexis: Honestly, right now we are still trying to build quite fundamental parts, so a lot of the time the UX success is that we did the thing. We made that happen. We have OKRs, and we follow our OKRs, of course we do that. But right now I think we're still working on what the really best measures are, because, as I say, I don't think App Store reviews are the best. This is something that we're still iterating and working on. Sometimes it's just through that continuous assessment as well, and being able to research as often as possible and hear back from people. It's an ongoing process, that one.

[00:27:52] Host: Okay. You mentioned OKRs. Do you have your own, or are your OKRs the business OKRs and it's just your contribution to them?

[00:28:02] Alexis: We have both. I would say in the product area OKRs, and the overarching OKRs for the whole of our organization, sometimes there will be ones related to design, research or user experience in general. But we also have our individual ones, which are actually very, very simple. Something as simple as, we're running this many sessions per quarter, for instance, or we are supporting this many appliances. Quite simple ones on the design and research side. And also for UX writing, because UX writers are so good at these things. They've got a very detailed set of OKRs that they're following.

[00:28:40] Host: That's great. My writers and localization team always had their own OKRs, and they were always so well written. Whenever you read them you're like, oh wow, maybe that's true for everyone.

[00:28:51] Alexis: Well, they're writers for a living. They're too good, those writers.

[00:28:58] Host: Okay. I feel like we all know this answer, but why did you move away from XD to Figma? Was it a good move?

[00:29:06] Alexis: Honestly, if you've used XD, the collaboration was just not working. We actually even spoke to Adobe. We called them up and sat down with them, and we said, "The collaboration features are just not working, and we don't understand what's going on." And they just did this thing where they went, "Mm." Like, that's not a response. They said, "Yeah, we have thought about fixing it." And I'm like, thought about it? Really?

[00:29:32] Host: And then of course I think they were planning... Homer Simpson backing into the bush.

[00:29:36] Alexis: It was a lot of Homer Simpson backing into the bush, exactly. And the whole of the design team were like, "Figma, Figma, Figma." And I was like, okay. But also, it was actually design tokens support as well, a big push. We asked and asked Adobe, "Can we have support for tokens?" And they said, "Yeah, we're thinking about it." And I'm like, okay.

[00:30:01] Host: Thinking about it. That canned response when you're a manager: "We are thinking about it. Thinking about it a lot." Brad Frost just gave a talk recently about how design tokens and web components are going to merge into this beautiful world of one global design system, being able to push things out across 17 brands, three software, hardware, digital, non-digital, AR/VR. And some companies are still going, "Hmm, we're going to use XD." Calm down.

[00:30:30] How do you communicate the value of UX, and the design process in general, to leadership? Besides your design leadership team, to general leadership?

[00:30:38] Alexis: I'm very lucky. One of the reasons why I joined the company is that I have a very supportive VP of product who really understands the value of design, and I think that's half the job. If you're spending a lot of your time and energy fighting for why you should exist, you have to question whether or not you're in an environment that can really support you. I know that's not an easy answer for a lot of people.

[00:31:02] I think as well, there's something about being in hardware where people do appreciate the nature of design, because of the physicality of what they do. That's somewhat ingrained into the organization. It's like, "If it looks great, that's great. If it works great, that's even better." And I'm like, if it looks and works great, guess what you're going to do? Amazing. So there is that built in. But again, we've got a great chief experience officer, and it's his sponsorship that's helped. I'm afraid the C-suite really has to get it, and if they don't, then it's tough.

[00:31:36] Host: It is tough. I have a whole workshop for when they don't get it, because sometimes they get it up to a certain point. Maybe they get ergonomics very, very much, because you make a physical product, and if they don't feel like they can use it when they see a demo, they understand that's an issue. But maybe they don't understand why a certain feature isn't great and why you should prioritize that, for example.

[00:31:56] Alexis: We get lots of top-down feature requests. Not so much from the really top, but more from mid-level, I guess, because there are a lot of expectations like, "Well, our competitors are doing this." And I'm like, of course your competitors do, but are they really getting value? Is it really working out for them? That's always my question back: can you show me that it's providing value for the competitors? And often not. They're like, "But they've got the thing. We must have the thing as well." And it's just like, maybe not.

[00:32:29] Host: "Bring back Sketch."

[00:32:33] Alexis: I'm sorry, mystery man, not going to happen.

[00:32:36] Host: How is your work with localization impacting your software design?

[00:32:39] Alexis: Okay. As you can see, we're working with quite a few languages, and that's not even all the languages we've had requests for. Oh my God, there's one language which we'll never do, because it's just too niche. It was a very small language, I can't remember... Luxembourgish. Yes. I was like, no, Luxembourgish, no. But you never know, we might still do Luxembourgish. Never say never.

[00:33:04] With localization, we are actually part of the translation tool chain, so we have direct hands-on work with the localization. It's not done by a different team as a separate thing; we don't have that dependence, because with the tools we're using, we have localization built in. We do have to work with a lot of native-language reviewers as well. But because we're working with a very smart tool chain for localization, we can turn most translations around in about two days. And if we get a fairly quick response from our native-language reviewers, we can usually do everything within the sprint. It's a lot in the tools, and a lot in being able to get people to validate it fairly quickly. That's the main thing.

[00:33:52] And then of course with the designs, we have to allow for... Czech [?] gets so long, doesn't it? Why is Czech so long? We have to make sure that we've got space for that and always allow for it in our components. But I think that's just the nature of work nowadays. We can't just design for English.

[00:34:08] Host: Do you have a QA team, quality assurance, sorry? Do you have a quality assurance or QA team?

[00:34:14] Alexis: We have a small QA function that works across the product areas to support that, but of course we also have QA in each of the product areas. We have both: one as an enabling function, to ensure that the ways of working are being carried across successfully, and then the actual practitioners are more within the product areas. So yes, we do have QA.

[00:34:35] Host: Okay, fantastic. One big loud round of applause. Thank you so much.

[00:34:40] Alexis: Thank you.