Science Of Design

Tem Aguerra at UXDX Community: Stockholm. Video: https://youtu.be/wAv9t7kEZZ8

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.

People care about their problems, not our products

[00:00:11] First I'd like to thank you guys for coming out. I'm just here to give you five short tips for smoother design while you wait for that new design process, acetylene [?], that you're learning today.

[00:00:28] What does this girl need? A chair? A ladder? Or, if we're thinking in the form of needs rather than solutions, she needs to reach. Or maybe she needs boundaries. She's been on that tablet for about four hours, and her parents put it there for a goddamn reason. In a company scenario, business analysts would have seen this as a dramatic increase in the need for more books this quarter and set that as an important KPI, all while the design team is tasked with coming up with new ways to sell more books. This company is not interested in design. Design is the intentional solution to a specific problem. Selling more books is not a problem, it's a desire. Increasing KPIs is not a problem, it's a specific desire. Deep down we need to realize that people don't care about our products. They care about their problems.

[00:01:33] My name is Tem, and I'm a UX lead and a strategist, but I'm also a designer, and as a designer it's my job to question things in order to find new and better solutions. I'm just going to move my... However, most designers work within a context where priorities are not completely rational. There are too many interests going on that have a direct impact on the user experience. We have product managers, we have business analysts, web developers, we have marketers, we have CTOs, we have CEOs, and they all have their own agenda. Too often competent designers are subject to a broken process for making decisions. That's why we see smart people make stupid decisions.

Design is not random, and design is unpredictable

[00:02:26] If you're a product owner or in a leadership position, and part of your job is to have an opinion on design, there are two things you need to realize. Design is not random. "I move things around until they look right." This is Milton Glaser, one of the great graphic designers of our time. He made things like the I Love New York logo and Brooklyn Brewery, for which, incidentally, Stockholm is the second largest market in the world. He said it jokingly, but traditionally that's how we view design: something esoteric, this mysterious process that involves a lot of thinking and a lot of inspiration and tons and tons of Post-its. And in some ways it's true.

[00:03:21] You might have seen this before. It's called the design squiggle, and it's often used to show the design process. There's some form of research going on, then it synthesizes, then it goes into some form of concept phase, and then you end up with this one design. That's great, but it's not a very fair description of how design actually works. Design is not random. There's actually a method to the madness. It's about methodically testing different solutions until you have enough data to move forward. Otherwise you're just designing for the sake of design. Making stuff look good is not a goal, it's a desire. It's about designing with purpose, designing with intent.

[00:04:17] Number two: design is unpredictable. Ironically, most companies today value repeatable and predictable quarterly profit reporting, but design doesn't conform easily to estimates. It's really difficult, if not impossible, to calculate the return on investment in creativity, or to predict exactly how much value will be delivered through a better experience. Once you understand this and accept these terms, design will be a lot easier to work with.

Tip one: make design less agile

[00:04:52] So here are my five tips on how companies can make the design process a bit of a smoother experience while we wait for all these big methods and processes to settle in. Number one: make design less agile. What I mean by that is, take design out of your scrums, take design out of your agile process. A lot of tech-driven agile focuses on requirements and deliverables, but like I said before, design doesn't conform well to estimates. We are looking to produce changes that improve the product here and now. Lift design out of the development pipeline, ditch the estimates and start with deadlines. Why? Because designers work really well with deadlines. Like we said before, when is it time to stop? When time runs out, or when the money runs out.

[00:05:57] Create a separate design pipeline. Work in weekly, maybe biweekly, sprints. Start off each sprint, preferably on Monday, in a group session where designers, product managers and developers get together and collectively define the product problem that you want to work on this week or this sprint. Aim to leave the first session with one or two high-level product problems or design approaches that you can test with users. Each approach should have an underlying hypothesis that the testing will either validate or invalidate, which brings me to my next tip.

Tip two: what's our hypothesis?

[00:06:43] What's our hypothesis? This statement is great, and I use it all the time. Whenever I come to a discussion that starts devolving into what everyone thinks or what everyone wants, the first thing I say is, "Well, that's great, we don't have to think so much, because we have data to see what's going on. But also, what's our hypothesis on this?" We can't solve a problem until we understand it. That means we need to study it. We need to test our assumptions, all these statements about what we think is true. We don't need to actually know the truth, we just need to have an opinion about what we think is true. Once we have that, we can build a hypothesis. But we don't want to spend too much time doing studies either. Just enough, like I showed you before: just enough data to move on to the next step towards this great solution.

[00:07:39] Lean UX has a great way of doing this: they work with experiments. It's called a hypothesis-driven experiment, and it looks a bit like this. You can word it differently, but first you have a hypothesis, "we believe that". Then you write down how you plan to test it, and then the evidence: how you would know that it's either valid or invalid.

[00:08:10] If we start with the hypothesis statement: we believe that creating this, for this person, user or persona, will achieve this outcome. For instance, we believe that adding a vendor rating system for the buyers will make buyers feel safer and more comfortable. Or, we believe that a pop-up prompting new visitors to sign up will increase account creation. It doesn't have to be worded in that order, but this is a good... what's it called? Never mind.

[00:08:47] Once we have this, it's easy to create an experiment. For instance: we believe that a pop-up prompting new visitors to sign up will increase account creation. We will make an InVision prototype and test it on six users, or we will run these A/B tests, et cetera. And we will know this is true when we see these numbers change, like when we see four out of six testers signing up via the pop-up. That's a sprint. All you need is one week, or two if you feel insecure.

[00:09:28] Continuously testing assumptions like this is a low-cost way of minimizing the risk of developing the wrong thing, because developing is really expensive. Running A/B tests is also really expensive, but we're not going to talk about that today. It's especially good if developers and designers work together in creating these experiments. It also serves as a great reminder that we should always design with purpose. I have it on the inside of my notebook when I moderate design discussions. I have this thing here, so I can always open it and say, "But wait a minute, what's our hypothesis here?" It stops all the discussions going on and brings everybody back to: what is the actual problem that we're trying to solve here? Base it in some form of problem that I need to solve.

Tip three: be where design is

[00:10:29] Which brings me to number three. If you're a leader, or a product manager, or anybody leading any type of organization that has design, you need to be where design is. There's no excuse. Weekly design reviews are a great way of doing so. A company I helped lead design at recently had design reviews once a week, every Tuesday between 10:00 and 11:30. We had about 12 designers, the CEO and the head of product together in the room, which meant we as designers had full access to the CEO and the head of product for an hour and a half.

[00:11:17] Each meeting starts by going around the table setting the agenda, sort of like a Lean Coffee type thing, where you write it up: what does anybody want to talk about today? You write it up, and if it starts to get to a lot of things, you can do dot voting or something like that in order to prioritize, and then you go through them one by one. If anyone needs to discuss their experiments, get some critique or get a decision in order to move forward, they put it on the agenda. And it was fantastic, not only because the main decision makers were in the room, but because these managers, and this is really important, understood that the design review, for somebody in a leadership position, is not about governing. It's about being informed and being there to answer questions and make decisions to help move designs forward.

[00:12:08] It's also about being respectful, always. As a leader, remember, you are a guest in that context. Your goal is to help the designer make intentional choices, to create intentional design, to design with purpose.

Tip four: tolerate failure

[00:12:26] Which leads me to number four: tolerate failure. Design is about minimizing risk, and that's why it's important to tolerate failure. A design culture is nurturing. It doesn't encourage failure, but the iterative nature of the design process recognizes that it is rare to get things right the first time. Apple is celebrated for its successes. When you ask clients what they want to be, everybody says, "I want to be Apple, I want to be Tesla," and then we say you can't be Apple, you can't be Tesla. A little digging actually uncovers products that didn't fare so well, like the Newton tablet and the Pippin gaming system. It's important to leverage failure as learning, and to view it as part of innovation, part of business, just like when we change processes or adopt new models.

Tip five: a model is only as good as we allow it to be

[00:13:21] Which brings me to number five. Adopting a UX model, like UXDX for instance, is a great step, but it's not going to be a silver bullet that solves your entire product pipeline. A model or a process is only as good as we allow it to be. Leaders need to create a culture that allows people to take chances and move forward without a complete logical understanding of the problem. You need to trust your designers and empower them with a sort of creative confidence, because innovation, and this is super important, innovation is by its nature undefined.

[00:14:00] Give designers business context and allow them to identify opportunities that grow the business, and you will soon see how you, as a business or as a product, start solving real problems. This is the key here: give your designers the business context. Why are we doing this? Why am I asking you to sell more books? Well, because we just saw a super dramatic rise in the need for books among little girls aged four to eight. Okay, well, why is that? Because they need to get to that tablet. Well, they just talked to the parents. And that's what user experience is all about. Thank you.