Assumptions & Principles; Underrated UX Methodologies

John Buckley at UXDX Community: Amsterdam. Video: https://www.youtube.com/watch?v=Jm8CcOUwcbQ

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: two documents that bookend discovery

[00:00:10] I'm a lecturer at the University of Limerick, and I'm also a UX designer, as Contra [?] mentioned, at Frontend.com [?], which is a consultancy based here in Dublin. We do projects all around the world, and have since 1998. Typically they're in healthcare, they're in software and FinTech. More recently, though, we've been doing some work, and I guess this ties in with what Rory was mentioning, in helping teams, and typically helping UX teams. We would have just worked on projects and other products, and now as things were going in house, we're helping teams evolve and helping them figure out how to get to their own solutions.

[00:00:47] So it's founded from that that I'm going to be talking today. As was mentioned, I'm here to talk about the sexual attack problem to vision [?], which is actually my favorite part of any project. It's trying to, I guess, look into the weeds and try and find a direction. More specifically, I'm not going to talk about research and all that; I'm sure you're familiar with it. I want to talk about two documents which I think bookend it quite well. The first is the assumptions document, which we'll go through first, and that's the very beginning of the project. And then towards the end of projects, design principles, which I think is a useful tool to bring the team together.

Assumptions documents

[00:01:35] So, assumptions documents for design. This may seem like a familiar image. A lot of times you'll make evidence-based decisions that come to a solution, and it will be insight driven. And then there's bringing it to the team, bringing it to developers, bringing it to the client and project managers or whoever it may be, and eventually it changes into something that is something like what you knew, like that. And sometimes those changes are great, and sometimes they're brought upon by someone like this guy. This is what I think is the most dangerous person potentially on a team, and the most dangerous line there is "I think", because if you build a product on assumptions, that can be expensive and dangerous, and derail and delay the project.

[00:02:27] So this is the guy you need to look out for, and the way you go about that is assumptions documents. For those of you who don't know these, they are essentially working documents where you list all unverified statements or beliefs. So any time that someone says something, a statement that sounds definite, you try and just put it into this, and you do that as a collective.

[00:02:53] The real benefit of this, though, is that it actually creates culture change. If you have a senior stakeholder, in a lot of cases, who, I think we're familiar with this, has a strong point of view: okay, that's great, let's put these assumptions up and let's challenge that. And if you create this culture where every statement gets into this document and gets verified, you no longer have an issue with women or survivors [?].

[00:03:18] So there are three easy steps. One, gather assumptions. Two, challenge assumptions. And three, repeat. The repeat is important, because we think of this a lot of times as being the start of the process, but actually it's useful throughout, especially in startups with products where that's wholly true: you're constantly having new assumptions.

[00:03:42] One of the biggest issues is identifying assumptions to start with. Everything is an assumption. Typically they're divided into three categories, and these can be different from team to team, but a lot of the time they're user assumptions, business assumptions and technical assumptions. And trying to understand what is an assumption is actually quite a challenge, because you're looking for statements like these, anything unverified. Actually, the best way to think about it is like a scientific essay or thesis, where usually you have to quantify it or give it a reference. So it's almost like that, but in a real work context. And the challenge, of course, is where you have internal talk, your own mental models: it's hard for you to actually recognize that what you are thinking is an assumption.

[00:04:28] The best way to do that is with something like a Google Sheets type thing, or some people I know use Trello. Basically it's something that's easy to access, editable, and just readily available right there and then. Best practice is to have someone responsible for maintaining that document. And then finally, and this is really important, empowering the entire team to identify and add their own assumptions. The person responsible will be driving this forward and pushing this as a central [?] document, but the whole team needs to be engaged. If the whole team isn't engaged, then it's not going to be relevant for them, and they're not really going to work from it. So making sure everyone's bought into this and everyone is working from it is really key.

[00:05:13] One of the great things about it is that it actually aligns the whole team. In a lot of cases you might have different people who are almost on the same point, but maybe from different points of view. You probably notice sometimes where you have a conversation and it feels like you're all in agreement, and in the words you know that someone's not quite there. So this is a great way of just putting a statement down and saying, this is what we all agree is the definition of how we see this. It can really align the team.

Prioritizing and challenging assumptions

[00:05:42] It's also great for research, in terms of prioritizing what research you might do. The obvious questions are: is this assumption critical, do I need to challenge it? Could the project [?] fail because of it? How widespread is the assumption? And then finally, how difficult is it to answer? If it's a case that you're going to have to do user research, well, in an hour-long research study you're going to have about 20 questions. Should this be one of the 20 questions, or should you defer it to another round of research? These documents are also quite a good way, I guess, of prioritizing the research in general.

[00:06:22] And then finally, challenging assumptions. There are different ways of doing this. You can either put them into a question format, or, what I actually personally like, put them into a statement format. And then decide on a testing method. Is it going to be user research, stakeholder research, the internal team? Do you want to talk to the dev team? Can you do secondary research? A lot of my students forget about secondary research. In many cases, especially earlier on in the project, secondary research is probably even a better way of addressing some of the assumptions that you have.

[00:07:00] And then consider a validation metric. This isn't always appropriate, but getting back to something Rory mentioned earlier, it can be very helpful to say, okay, look, we're going to say this is the assumption, and we're going to say this is the data point that'll prove it. Then when you do the research, you just say yes, we hit it, or we didn't hit it, and you've agreed upon the definitions of what is or isn't a pass.

[00:07:23] So here's, I guess, the takeaway slide for assumptions. It's essentially a very basic spreadsheet to guide research and inquiry. We use them to ensure the scrutiny of commonly held beliefs that could derail the project, and to provide a shared understanding amongst the team, and you do so with those steps I just mentioned.

Design principles as guiding lights

[00:07:45] Okay, the second one is design principles. My view on design principles isn't absolute, and my thinking has evolved as I've been exploring them. I've written a few design principle papers and things, and with some of them I might now disagree with what I came to at that point. This is, I guess, more towards the end. Actually, this is at the very end of this process, but it might be more familiar to you guys at this stage. It's once you've finished all the thinking, but before you start to design it.

[00:08:16] I refer to these as being guiding lights. What I mean by that is that it's something the designers and the team can base their decisions upon. It also guides them in terms of what they should be designing overall. And it also inspires the designers to really create something.

[00:08:40] A really quick metaphor for this: think of a company that decides they want to create a burger restaurant, and there are two unified teams at that point. One team decides that, based upon their user research, based upon their business model and everything else, they're going to focus on speed, convenience and consistency as their principles, and they'll end up with a McDonald's type thing. A different company had the same starting point, but said, well, based upon our business model, based on our ability, based on our user research, the thing that matters to us is a quality experience. And they would get to a completely different end point. So design principles, if they're designed well, can completely change the direction of, not usually a complete company, but even a feature, and how it might lead to something significant.

What makes a good design principle

[00:09:33] Here are, I guess, the main points for good design principles. The first thing is that they should be memorable, so that the whole team is able to remember them, rely on them and go back to them. Second is that they're concise, so they're easily grasped. Again, it's like memorable. Third is that they're relatable. This is the idea that really well-written principles are emotive and evocative, and you can think about them in context, and it really tells the whole story around just that one line.

[00:10:07] They should be insight driven. They shouldn't just be reflections, but really driven and founded from the whole discovery process to that point. They should be universal, so you shouldn't be focusing on a website or on a certain channel. And I think that they should be differentiating. That's really important to me. There's no point in having a design principle for your product that doesn't differentiate. But they also have the potential to disenfranchise [?]. They've got to be complementary, so they don't contradict one another. And then finally, they should be guiding. If you're creating a core design principle, it should have the potential to instruct your designers.

What a design principle is not

[00:10:50] There are some things that it's not. The first is that it's not the principles of design. If you type in "design principles", you're going to get the five, I guess, principles of design, which are consistency, white space and so on. Those are great, but that's not what we're talking about here. And equally it's not, I guess, these. These are from GOV.UK. They have some really good ones, but they also have a mixture of poor ones in their core design principles: "Start with user needs", "Build digital services, not websites." To me those are more about process. They're team related, not product related. So that's not really a good example of core design principles.

[00:11:28] Also, these are Facebook's core design principles: one word, "transparent", "universal". You don't have any context, you don't have any emotion. There's nothing really to them that's going to be guiding or memorable. The flip side too: my students will come back with full paragraphs. These shouldn't be paragraphs. They should really be something memorable and concise. You can provide additional information for sure, but around a key statement.

[00:11:58] And then they shouldn't be obvious goals. A lot of times you have "easy to use", "aesthetically pleasing", "user friendly". These should be totally basic. That isn't a differentiated product. If the insights you've gotten so far only go that deep, you'll have a whole lot of problems further on. And then this is similar, but my students keep relating them to the process of how the team should work. This is probably the worst one I've ever gotten: "All team members will complete allocated tasks to at least the minimum requirement of quality." And true to their promise, I did find their project was at the minimum level of quality required to pass.

Examples of good design principles

[00:12:45] So, some good ones. GOV.UK has this one, and it's great: "This is for everyone." The subtext here is really where the meaning is: "Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance, so be it. We're building for needs, not audiences." So "this is for everyone" is memorable as a statement, but the subtext really helps guide the designer: okay, if I have a decision to make here, I know the trade-off I need to make. And that's really powerful for your design team.

[00:13:14] Another good one is Airbnb's. I love this one: "Design is the mutual friend." If you use Airbnb, you know it's not Booking.com. Booking.com is a salesperson. You've got all these nudges pushing you to buy, and you know the relationship you have there. Airbnb obviously want you to buy their products, they want you to engage with them, but they don't ever really push it on you, and they really come across as a friend recommending things to you, with subtle nudges. They have a number of different ways of doing it, but it never feels like they're pushing something. It always feels like it's from your friends. And you know that the design team has probably come up with some Booking.com type features, then challenged them against this and realized that it's not them.

[00:14:02] Here's one from the City of New York: "Make government simple." For their website they came to this. Above the scroll line they have just the main things that people look for: is parking in effect, are collections on schedule, and are schools open today, boom, boom, boom. And then when you scroll down just below that, you'd expect all the complicated silos of government. Instead you get this beautiful yellow box here where you can make complaints. A complaint that goes to noise complaints will inform the police service; a complaint about potholes informs the roads department. So basically it's cutting across all the silos and making it simple.

[00:14:46] But my absolute favorite design principle is actually from Adaptive Path, for a continuous glucose monitor concept. This is a device you have to wear on your body 24/7, and their number one principle is "Wear it to sex" [?]. It's really, really clever as a principle, because it's memorable, and it tells people you need to wear the product 24/7, so make the product elegant, discreet and comfortable. It really tells a lot about how it's worn and that it's worn all day. It has to be waterproof, movement can't affect its performance, and people must feel comfortable and confident wearing it. I mean, obviously you're at your most vulnerable when you're having sex, so if you can design a product that works when someone's having sex, then they can obviously be confident at all times.

[00:15:42] You can see how a principle like this can really challenge the design team to go one step beyond where they're at, to make sure they're actually going to get to a really clever design solution, in a way that, if they didn't have that principle to follow, maybe they would have designed something that was just all right for walking around.

[00:15:57] My final point is, I guess, that great design principles are just like great sex: evocative, unifying, memorable. But most likely, unfortunately, they are typically incredibly rare [?]. All right, thank you very much.