Boring Design Stories

Jill Quek at UXDX Community: Singapore. Video: https://youtu.be/NeBwD1m-v3U

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.

I love designing boring stuff

[00:00:01] Hey everyone, and welcome to today's session on boring design stories. Before I begin, let me introduce myself. Hi, I'm Jill Quek, and I'm currently a product designer at Automattic, which is the parent company of WordPress.com, Tumblr, WooCommerce and others. Previously I was at Zendesk, which is customer service software, and before that I worked with a bunch of clients designing consumer apps, websites and print media.

[00:00:31] So there's something about myself as a designer that I've discovered over the past decade, and that is, I love boring design. Or maybe more accurately, I love designing boring stuff. So what do I mean by that? Things that are complex, or painful, or tedious, or unsexy, I kind of enjoy designing. Because I've realized that they often are tasks that people need to do, or they're products that people just have to use in order to live their lives, or just to do their jobs.

[00:01:09] And something that I like about it is, a little bit can go a long way. A little bit more design love, a little bit more usability, really can have such a big impact on users. And I definitely think you find a lot more of this type of design, or this type of work, in business or enterprise software, but I definitely think you see it in consumer software as well, and I'll talk a little bit more about that later.

[00:01:39] Okay, so the session is called boring design stories, so I'm going straight into story time. Today I'm going to tell you about two projects. I'm going to walk you through a little bit of our process, some of the mistakes that we made and some learnings that we took away, and ultimately I'm going to share with you four tips on designing boring things.

Story one: the migration maze

[00:01:59] So the first project we'll call the migration maze. Here's a summary of the problem. We built fancy product X, but for our customers to use it they first had to migrate from feature A to feature B. Sounds exciting, right? No, not really. But we knew that it was a necessary evil. It was on our planning documents for months before we even started, but it was like a can of very tedious worms that nobody really wanted to open.

[00:02:32] So we started investigating it a little more. We figured out the nitty-gritty of how long this migration would take, who it would affect. We scoped it all out, we ideated on some initial solutions, and we presented this to our stakeholders in a meeting. And here is an actual photo from that meeting with our stakeholders. Okay, obviously it's not, but it's very representative, because nobody really cared.

[00:03:01] And it's not because nobody wants to care. It's just that this migration flow, compared to all the other flows and all the other things that we were working on, it was very hard to prioritize it, because we had a limited set of resources, a limited amount of time. So the response initially, even from us, even from the team working on it, was like, how can we just do the bare minimum here so that it meets the basic requirements, and then let's move on to other things that we understand better and that we know are important, or that everybody agrees are more important. And so the risk was that, because it was so complex, it could sort of become an afterthought that would result in a fairly painful experience for a significant chunk of customers.

[00:03:50] So for me this project in particular is a good example of something I've learned about boring design, which is, it's very hard to love. It is difficult to intuitively connect with it, it's difficult to understand, and that becomes an inherent challenge when you're tackling this type of work, because you have to advocate for your problem in a way that maybe you don't have to when you're dealing with other types of problems.

A lion, a cat and a mouse

[00:04:14] So how do we solve it? With a lion, a cat and a mouse. And this idea is credited to Mike Chen, who's the head of design at ShopBack Singapore right now, and we were partners on the project at that time, so he had the idea of creating these three characters: Leo the lion, Cleo the cat and Minnie the mouse. And each of them represented a specific kind of user role in the product.

[00:04:39] And we put them everywhere. We put them on our slide decks, our design working files, our Miro board, all our notes. And we basically created these little dialogues or skits about the three characters. And so Leo the lion might say, hey, have you tried out fancy product X? And Cleo the cat might say, yes, we need to get our teams trained and set up to use it. And then we would show the experience that Leo the lion would have and Cleo the cat would have, because they might see different things. And so we used it as an overview for the entire user journey, and we would splice it together with our interface designs and use it as little annotations as well.

[00:05:19] And it really helped to create a lot of empathy and clarity across the team, because instead of an abstract problem it really became a story about three people working in a company. And the result was that we got a lot more resources, we got time and developer resources to design and build a more user-friendly migration flow. And aside from that, we also got a lot of appreciation and kudos from different levels of management and people from other functions, because we managed to turn something that was very unapproachable into a pretty clear problem. So that really helped.

Tip one: make it lovable, tell a story

[00:05:59] So my first tip for you when you're designing boring things is, try to make it lovable, tell a story. I've seen other designers do this using stick figure comic strips, or GIFs, or emojis. You could try an interpretive dance, maybe. But basically you just want to try to help people connect with your problem and understand what your solution could be, and come along that journey with you.

[00:06:30] So there's something from consumer software that came to mind when I was reflecting on this project, and that's the migration flow from an old phone to a new phone. I don't know how many of you out there are like me, but when I used to get a new phone I would dread setting it up, because I would have to download everything from my old phone into one place and then re-upload it into my new phone, and it just used to take hours. It would take hours to sync back, and for some reason it would always screw up for me, something would always go wrong and I never could figure out why. So I would procrastinate setting up a new phone for days and weeks sometimes, because I hated this process.

[00:07:13] But today, if you get a new phone, if it's a new iPhone for example, you put them next to each other and it'll sync wirelessly, or you can download directly from iCloud and start using your new phone immediately, and the data downloads in the background. And that's obviously such a much better experience. And when I think about the product team who worked on this, I can only imagine, out of all the things a new iPhone can do, this migration flow must be one of the least sexy flows to work on. But what an incredible impact some thought and greater usability has here, and I'm sure it impacted a huge proportion of their customers as well. So I really appreciate the work that went into this flow.

Story two: the technical tangle

[00:08:05] The second story that I'm going to share with you is called the technical tangle, because I like alliteration. So this is a summary of the problem. We built fancy product X, a different fancy product X, but for any customer to use it they needed to configure a lot of really technical settings, which is terrible. And if they did it wrong they would get a whole bunch of errors, which again sounds like a really user-friendly experience, right? Nope.

[00:08:32] And it was so complex and the level of detail was so high that, to even understand the problem, the team and I had to go through hundreds of slides in a slide deck just to talk about the requirements, and we had multiple days in workshops just to understand it. So not even ideating, not even talking about the scope, but just understanding the problem required several days.

[00:08:59] And I'll be honest, this was me after that whole process. I spent, I'm going to say a week, in this state of, I have no idea what I'm doing. And I went down a whole bunch of rabbit holes, I got lost in documentation, and I just didn't really know how to wrap my head around it.

[00:09:19] So what I did was, I tried to create without the complexity. I created an extreme ideal version of the flow and I tried to ignore some of all the requirements. And my primary objective at this point was really just to test my own understanding. Am I getting this right? Do I even understand the basics of what we're doing? Is this sort of what it could be?

[00:09:45] And the unexpected result of that, and of sharing that with the team, was it really energized the team. I think a lot of them were going through the same process of, I don't know what I'm doing, as I was, and so it really helped them to point to this extremely ideal prototype to say, yes, that's what I was thinking too, or, no, I was thinking something quite different at this portion. And one of my team members even said to me, it's really good to see it look almost real. And I think that really helped us step away from all the complexity as well.

[00:10:19] So something else that we did was, we put some semi-ideal prototypes in front of customers. So what that did was, we were able to test overall usability, get their perspective early on on some key concepts, but also it helped us to validate certain requirements. Some of these customers knew already how technically complex the setup could be, so they actually asked us about some things that we had deliberately left out of this prototype. So they would say, oh, where's this setting, or where's this other setting, because I would want it for my specific use case.

[00:10:55] So the reason why that was great was, of course, it helped us to prioritize certain requirements, and it helped us to understand a little bit better why those requirements were needed, or in what situation they would be needed. So obviously that was really helpful as we were building it out.

Tip two: test, test and test

[00:11:12] So my second tip to you today is, test, test and test. And I think that this is something that designers definitely do very often, we would want to test our solutions. But I think particularly with the super confusing stuff, what helps me is to test not just my solution but also my problem, and also myself, to make sure I'm understanding it correctly and make sure that my understanding is aligned with the rest of my team.

Tip three: take it step by step

[00:11:41] So something else that we did in this project was, we set up a structure. And you might notice that we did that with the first project as well, the three animals that unintentionally became the structure around which we put all our solutions. But for this project we had maybe a more traditional structure of just different epics that we defined across product, development and design. And the product people took these epics and they wrote their user stories, and they basically did their work around these epics that we had defined. And likewise, as a designer, I put this into my working files and arranged all my screens according to these epics. And development as well used it as a basis for creating issues and tasks in GitHub.

[00:12:29] So my third tip is to take it step by step. This seems really obvious, but massive problems are just a lot easier to solve when you split them up. They're more palatable, they're more defined, and they're just overall easier to tackle.

[00:12:46] There is one note of caution I want to mention here, which is, I have seen huge projects get split up in a very isolated way, like maybe it's just a small group of people, or it's just one function, like all designers or something, creating the structure. And that can cause a lot of confusion and chaos rather than clarity, because the segmentation can end up all wrong. And the reason why I want to bring that up is because I think this seems like a simple thing to do, to set up a structure, but honestly it's just not that straightforward.

[00:13:19] And I found that ideally what you want is an ongoing dialogue across all levels and functions, and everyone having the right expectation that this structure is a flexible one, that everyone should be giving input and feedback about the structure, and potentially it might adapt as the project gets worked on or people uncover new things. So I found that that expectation really helps, because the value of having a shared language around this map, to help you figure out where you're going and where you've been and where you still need to go, is so valuable when you're dealing with huge projects of great complexity.

Tip four: transparency builds trust

[00:14:02] And that also ties into my final point, which is, to work on complex and tedious problems I think you need to invest a little bit more in transparency and communication, because transparency builds trust. And I think for sure that's important for all design projects, but particularly for complex ones you can't take things for granted. You can't take it that one person is going to see a problem the same way that you are, you have to put in that effort to communicate a little bit more.

[00:14:31] So for me as a designer, what I found helpful was, I made all my design files open, all my Google Docs are accessible to everyone, and I aggressively would invite people to come and take a look and give feedback. And I found that incredibly helpful, because I managed to get feedback not just from product people or developers, but also from marketing, business folks, other teams who had never worked with design before but who knew a little bit about the complexity that we were trying to solve for. And they were able to really add value in terms of their feedback and really improve the solution ultimately.

[00:15:08] So the result of this entire process was, we managed to streamline everything down into a three-step setup, and our users were very excited about what we were building, the users that we had consulted. And that's for sure a very good feeling, when your users are excited about what you are designing and building.

Summary of the four tips

[00:15:27] So here's a summary of the four tips that I shared today. So the first tip: tell a story, make the unlovable a little bit more lovable. Number two: test not just your solution, not just your problem, but also yourself and your alignment with your team. Number three: take things step by step, break up the problem, be flexible as you create that structure and draw out that map. And transparency builds trust: communicate, and keep things out in the open. It might be slower, it's true, and it does take more effort, but ultimately I think it is really worth it when you're dealing with a lot of complexity.

[00:16:09] Thank you so much for taking the time to watch this session today, and I really look forward to connecting with you all and hearing about your own boring design stories.