A transcript of Episode 201 of UX Podcast. James Royal-Lawson and Per Axbom discuss two articles that have grabbed their attention – this time they’re about Consistency in design and polarity mapping.

Transcript

[Music]

PER: You’re listening to UXPodcast coming to you from Stockholm, Sweden. We are your hosts Per Axbom.

JAMES: And James Royal-Lawson.

PER: We have listeners in 181 countries from Ukraine to Belgium.

JAMES: And episode 201 is going to be a link show. And for those of you that don’t know, that is where Per and I choose articles that we’ve stumbled upon in recent weeks and talk about them and discuss them with you.

PER: Mm-hmm. And today those two articles are Consistency in Design is the Wrong Approach by Jared Spool who is @jmspool on Twitter.

JAMES: And the second one today will be The Joys of Polarity Mapping by Stephen Anderson who is @stephenanderson on Twitter. Well, go on let’s jump into it.

So Consistency in Design is the Wrong Approach, this is an article that Jared Spool published recently.

PER: Oh yeah, it’s a recent one; December 12th, right.

JAMES: And really recent. And part of the UX Strategy Playbook blog that he has. And I read this note and I thought it was really thought-provoking. So what I’ll do; I’ll give you a little bit a summary of that it’s about first. I’ll read some of it. Consistency in design is about making element uniform, having them look and behave the same way. We often hear designers talk about consistent navigation, consistent page layouts or consistent control elements. In each case, the designer is looking a way to leverage the usability by creating uniformity. After all, if the user learns to operate the design in one place, why not have that knowledge transferred to the next?

“This is all good but wrong,” says Jared.

PER: Yes.

JAMES: Now, what he also says – I’ll ready a little bit more to give you the definition, I suppose, of why this is the right and wrong way of going about things. The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. Is what I’m designing consistent with other things we’ve designed or others have designed? And Jared said this is the wrong question to ask.

And what he proposes is the right question to ask is, “Will the user’s current knowledge help them understand how to use what I’m designing?” Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs. That’s quite a lot to take in but – I mean, I know me and you over the years of the podcast we’ve mentioned consistency a lot and we always fall back.

Like Jared says, we feel that consistency is one those building blocks that we always have with us when we’re doing design. It will be crazy and alien if we kind of sketched an interface or suggested a design to someone where it had five different button types of button designs.

PER: Right. Or five different drop down menus.

JAMES: Yes, or two completely different navigations. In fact, when you do a heuristic evaluation you’d mark people down. WCAG, the accessibility guidelines would mark you down, you’d fail it if you had navigation that was inconsistent. So it’s a really core belief and way of working that we have.

PER: It is.

JAMES: So when Jared talks about how the consistency in design is wrong. Okay, what’s Jared getting at?

PER: And he’s absolutely right. He is absolutely right. Because what he’s saying is that when you make something in one way just because it has to look in the same way as another thing, then you’re not even considering user needs. So he’s putting two things against each other. One of them is understanding what the user wants and the other thing is copying what else is on your website and making it look like that. And we even have design pattern libraries.

So sometimes I think even a calendar selection could be different on the same website depending on the context the user is currently in. I think we have to be prepared to at least accept that that could be the case.

JAMES: I mean, the thing that flipped my understanding when reading this was just the whole idea that consistency, by and large we have as an insular thing. So when we’re working on our website or our products and we try to be consistent within the realm of that thing, that website. Now, that’s all very well and good. But if the thing you’re being consistent about is wrong, then you’re being consistently wrong.

PER: Exactly

JAMES: And whoever is wrong or right, you can have all kinds of arguments about these designs patterns or kind of standard and so on, but ultimately, this is Jared’s point – what makes it right or wrong isn’t whether you’ve used the same thing everywhere on a products website. It’s more, “Does the user’s knowledge and understanding of what you’re presenting to the allow them to appreciate the consistency that you’ve deployed?”

PER: And he does say, when you think about consistency, you’re thinking about product. When you’re thinking about current knowledge, you’re thinking about the user. And that’s the big main point here, isn’t it? That it takes so much energy to really understand users, people fall back into consistency because that feels alright.

And then there’s a word of warning towards the end as well which I really like, because we see these beautiful, beautiful websites and they’re really consistent. So someone may even have done the right thing and it turned out consistent but then other people think, “Oh, it’s because it’s consistent that this website is useful so I’m going to copy that.” So they’re copying instead of actually doing the research themselves.

JAMES: Hamburger menus.

PER: Yes, excellent example.

JAMES: UX design has kind of adopted the Hamburger menu as if it’s, kind of, everyone understands it, everyone knows exactly what it means and we’re just going to roll it out there. Yet, it’s a complete nightmare, it’s a completely mixed level of understanding of what that actually will do.

PER: I was in a meeting three weeks ago when a designer actually said, well, that is now becoming common knowledge, what a Hamburger menu is. And I fell out of my chair.

JAMES: Do you know what? We should actually carry buzzers with us, and when someone says “common knowledge” we should press a buzzer. I’ve got four of them from our Christmas quiz we did. So I might put one of them in my bag so I start “woof, woof, woof, woof.” Like the dog woof or something whenever someone says “common knowledge”

PER: I have a big huge bullshit button in my bag – oh I have it in my studio, I should have it in my bag.

JAMES: But another thing I was thinking about was this. What happens if current knowledge is inconsistent? As in you’ve got divergent groups of users for your product or system or website. I can use an example from what I’ve been working with, one of my projects. We have a situation where most customers for the product – it’s an enterprise product. So most customers are from the same sector, they’re related.

Whereas, most users are from a specific sector with a very different set of knowledge. So it’s an example, actually. The group that’s different is more healthcare professionals, whereas the group with the most customers is more customer services, for example.

PER: Right, yes.

JAMES: So the knowledge of these user groups is very divergent. And that then creates a tension, a conflict between, okay, what do you design for? Most customers or most users? What is the clinical knowledge? Which is the knowledge that rules?

PER: Well, yeah, that’s the problem with anything that you build, really, isn’t it? It’s a prioritization always. Someone always has to be your primary persona but that also means you exclude other people. The trick is finding ways to not exclude, of course. And that means just finding as many similarities as you can, diving deep. Usually in my experience, when you build something that works really, really well for one group of people, other people will be able to learn it much easier than if you try to accommodate to all the needs of all the people.

JAMES: Well, I think some of this is also down to language. I think, possibly, the answer to my own question is you’ve got to find the lowest common denominator rather than excluding a group. I mean, you can’t exclude a group in this situation where you’ve got a bulk of customers with one set and a bulk of users with another kind of set of knowledge. You’d have to invest the time into finding out what does work for both.

PER: Or you also need to be aware that you could actually come to the conclusion that there is nothing that works for both. That could be a possibility, and then you’d have to build two different things if they don’t have the same need.

JAMES: Yes, exactly. But that would be investing the time in order to understand the lowest common denominator which, in that situation, would be two separate products. That’s the basic thing that we have to do is slit this up into two distinct products or websites or offerings or however you want to kind of wrap it up. But it still means that you’ve thought about the user.

PER: Yes, and that you’ve done the work.

JAMES: Rather than being internally focused on being consistent within the work you do. I think this if we think about all the talk now about design systems which has become a massive topic in recent years and for any of us that have worked with large systems and multiple products or suites of products with organisations that design systems are essential or you just drawn, amongst other things.

It’s thought-provoking but how do we then still consider the current knowledge of the users when you’re spreading a design system across multiple realms?

PER: Yes, that’s when you need to understand when you’re taking a shortcut and when you can take a shortcut by stealing from your own design pattern library and your own design systems and when you need to actually put in the work to understand, has something happened here that we need to change it. And you raised something that was really important before as well that there could be something that we have in our design system that actually turns out to be wrong, it’s consistent and it’s wrong so it’s consistently wrong across the website.

Which means we need to build into our systems ways to change something across everything that that’s why, of course, we have CSS and CMS systems that should be able to do this for us. We will always need to be aware that if we build something that is the same across the sites, then if turns out to be bad we need to be able to change it all over.

JAMES: Thinking about, the common knowledge, you said – in Jared’s article, the example he brings up is on avis.com where they use the asterisk star in forms to denote fields that were not mandatory. So basically, the opposite of what common knowledge, I would say, was what you did, as in you’d normally put a star next to the fields that you had to fill in. Thinking as well about what we just said about Hamburger menus. When does something get elevated to being true? Jared says, don’t think about the consistency in your product, necessarily, think about current knowledge. Who is owning that kind of database of information that says this pattern has now elevated to common knowledge and current knowledge amongst the users accepts it and understands it so it’s okay to use?

PER: I think nobody owns it because there is no shortcut, you have to actually go out and talk to the people who are using your product. That’s how you investigate and understand and synthesize and realize, wow, they’re not getting it so we have to do it differently. So they could absolutely have the hypothesis that, yes, we could try and denote the fields that are not mandatory with an asterisk. But then that would show itself and the first user test, I think, that wouldn’t work.

So they failed to actually this with users, to do the proper research, to understand their target group.

JAMES: I think a nice spot to finish off would be to say that absolutely everything is a hypothesis until you’ve done your testing of it.

PER: Exactly, yes.

JAMES: And that’s even the case for all of these common knowledge patterns and so on or even things in your design system that you’re rolling out, until you’ve actually applied it and tested it or done the research to see whether it will be understood. And you don’t know, it’s a hypothesis.

PER: So let’s move on to The Joys of Polarity Mapping which is an article by Stephen Anderson which was actually posted the day after Jared’s. That doesn’t merely mean anything but that was fun.

[Laughter]

JAMES: Clearly it’s all planned out. They gather together in a little room –

PER: Yes, of course.

JAMES: Content planning.

PER: Stephen Anderson was behind the mental notes cards. Remember those? That were handed out to you at UXLx, one of the first ones we were at, I think, many years ago in Lisbon. They were all in our goody bags and everybody had cards – oh, you’re showing them to me on camera now. You have them, you brought them out. Wow.

JAMES: [Laughter] I still have them on my desk.

PER: The hunger effect, I saw. Yes, I loved those, they were really cool. I had them on my desk for a long time. I actually have them just in my shelf here so I’m meters away from them. But Stephen is really good at putting together these artefacts to help us make sense of information. And he himself has fallen in love with a tool call polarity mapping. And it’s used for facilitating good conversations about complex topics. And he gives some examples, see if any of these tensions sound familiar should we do more learning or start building? Should we focus on innovation or efficiency? Should we prioritize deadlines or quality?

And most people who work in any type of projects realize that, yes, these are typical things that people argue about. Is it now cost? Is it quality? Is it time that is the most important thing that we should focus on? And so this little tool that he’s presenting in this article called polarity map allows you or helps you to understand that these types of topics are never mutually exclusive. You have to choose one or the other because they’re always present. Choosing one doesn’t mean you can ignore the other, they’re both true.

And that makes it a complex topic because we always have to consider cost as well as time or time and quality. We can’t just ignore one and just focus on one of them. So the tool helps you map that out by thinking of the benefits of a focus on the left pole and the benefits of a focus on the right pole. So in this tool, he has actually chosen it’s always two, so it’s a dual system, there are two concepts that we’re trying to help coexist.

You can also think about, so what would be the unintended consequences if we focus on just this one or the other one. And that means, you can build a system for understanding when could this potentially pose a problem. So he’s focusing on the learning versus building polarity problem in his article. So are we learning about what to build or should we build it? And sometimes we argue a lot about it. So we should focus a lot more on research before we build it and some people say we should build it so that we can show people stuff so that we can learn from that.

So both of them are true, we need to focus on both and sometimes we need to focus on building, sometimes on learning but we’re focusing on both at the same time. Sometimes we need to understand what is going wrong, what are the unintended consequences of just focusing on building? It’s an over-focus on the right pole in this example.

JAMES: What else is said is the kind of looping between these two polarities is an important aspect of it that you’re not kind of stuck on one side or stuck on the other, you’re constantly switching between these four quadrants of benefits of one polarity, benefits of the other polarity, unintended consequences of the other polarity. And understanding how you move between the benefits and unintended consequences is the whole essence, really, of understanding what’s going on.

PER: Exactly. So an example of the unintended consequences of just focusing on learning is that you have analysis paralysis, you have so much information you’re trying to figure out what this all means, and the competitors beat you to market. Which means you sort of need to realize when you’re doing that so that you can move away from it and maybe now we have to build something in order to not get stuck in the learning process and just spend too much time in it.

For me, this is an excellent tool, it just makes a lot of things very clear. The only thing that I realized when I was looking at it, it doesn’t have to be polar, it doesn’t have to be just two items because the things I mentioned in the beginning which I am coming across right now in our projects. So is it most important that we focus on keeping costs down? Is it most important that we focus on getting it delivered on time or is quality the most important?

I could actually map all those three items into this same tool, which is what, actually, I started trying to do. Which means that, yes, somebody may say that it’s more important to focus on one of them, but that will have its unintended consequences. Which means that we have to actually think about all of them at the same time and put up with all these warning signals, when are we triggering the unintended or unwanted consequences even. Like putting up an early warning system and in meetings bring up, how do we know that we’re reaching out the unintended consequences of just focusing on cost or just focusing on learning or building like he’s saying?

JAMES: But at the same time I think there’s a real advantage with keeping to polarities because the complexity, of course, will increase by a huge amount when you start bringing in extra dimensions to this tool. I mean, you going from two to three and three to four is incredible task. One of my reflections when I was reading this was also, wow, this is really good because we’re constantly in our organisations trying to solve these issues. Agile was a way of solving time to market. It’s an answer and it’s a dogma. Whereas, what Stephen says is, no we’re never solving this, we’re just dealing with a balance. And we used to say balancing user’s technology and business are all in the same thing which is what we try to do.

But I started to think then, okay, once you’ve got these polarities, you can use the tool to map it, then I think it would be really good for surfacing, understanding or becoming too understanding. But how would you decide on the polarities?

You’ve side-stepped it by saying, “Just make it three.” I think that kind of, maybe, is missing a healthy part of the process.

PER: You could very well be right.

JAMES: I was trying to map it into my own experiences thinking, well, how would you know which two things are fighting against each other? You don’t always know if it’s quality – what was the other one you said? You said quality and?

PER: Quality, cost and time.

JAMES: Yes. I’ll say quality and cost, those two. Or it’s innovation or efficiency. How do you come to the point of knowing that’s the friction in your organisation? I actually don’t really have a good answer to that. I think you’ve got to get a feeling for what’s going on in your organisation to be able to pencil down what it is that your organisation perceives as being polarities that are connected and need to be balanced.

PER: That’s a good point. I mean, the conflict has to be there before we can start mapping it out. It need to be really clear what the conflict, perhaps, is. And that’s probably why I jumped into those three because that is the conflict I’m having right now. So maybe I will actually land in that are most important to think about and the third one is obviously something that will be taken into account, anyway.

But that will be something I will want to try because what I really like about it is the early warning system thinking that you have measurable indicators, things that you can count that will let you know that you’re getting into the downside of the right pole or left pole. How will we know that we’re focusing on the wrong thing right now in the current moment and should move on to the other side of this polarity map?

JAMES: Stephen himself, in the article, he said language matters. So I think this ties in with evaluating and understanding what the polarities are because you’re then building shared understanding about what polarities you’re working with and trying to balance. So then you can understand when you’re dipping into the unintended consequences or when you’re kind of pushing the benefits of one polarity too much compared to the benefits of another polarity.

PER: I just thought of one, I don’t know why but sometimes people argue we shouldn’t have meetings, we should just have short stand-up meetings. For me, those are polarities because sometimes you need the longer meetings to dive deep into a topic and sometimes you need shorter meetings because you spend too much time in meetings and not actually working on stuff.

That is something, actually, I could really see me mapping out. How do we know that we should have longer meetings and how do we know that we just need short stand-up meetings?

JAMES: I think you’ve just come up with an excellent practice test of this that almost any of us out there listening can actually try. Get your team to try and map out the polarities of meetings versus stand ups or longer meetings versus short meetings – whatever phrases you want to put them on. But have them as your two polarities, long meetings and short meetings and map it out and see where you come to. I think it would be a really good way of starting off with this.

PER: That’s actually a good point because it’s a simple topic and everybody has an opinion about it. And usually, that is very polar. People say, “We don’t need those meetings.” And people say, “Well, the stand-up meetings are too short.” And it’s like they all really both need to exist and that’s why this is a good map.

JAMES: Yes, because you can’t exist with just one of them, you can’t survive only on stand-ups. You’ll drown if you just had long in-depth three-hour workshops every day.

PER: Exactly. And that could give you a decision support system for actually deciding what type of meeting you’re going to have in the end.

JAMES: On the article itself, Stephen published, actually on UXMastery.com. He does actually have links to PDFs for the actual polarity map to use in workshops and he also gives a link to a polarity map that – well, he says it’s completed or a complete one.

PER: No, actually, I clicked on it. I thought the same as you, I thought exactly the same as you. It says complete polarity map. I thought, oh, it’s filled out. But it’s actually not, it’s just the one that you actually use. But the other one is poster.

JAMES: Yes, exactly, I should link to the poster. And I didn’t look at the other link until now because I thought it was an example. And it’s not, it’s more of a kind of reduced map, simplified, I guess.

PER: Exactly.

JAMES: But either way, the links to PDFs are at the end of the article which I think you could really use.

PER: And that was Stephen’s Christmas present to the UX community. That’s how I found this article via UXmas, actually, the advent calendar for UX-ers.

JAMES: And you’ll all get it as a New Year present.

PER: Yes.

JAMES: Thank you for spending some time with us today. As always, links and notes from this episode can be found on UXpodcast.com. And if you want something to listen to next, I would recommend Episode 89 which is where Stephen Anderson joined us as part of a panel were we discussed MVPs. And another episode that you could possibly dabble into now is Episode 120, Product Management and UX which Melissa Perri.

PER: Remember to keep moving.

JAMES: See you on the other side.

[Music]

JAMES: Knock knock.

PER: Who’s there?

JAMES: Udder.

PER: Udder who?

JAMES: Udder madness with all these knock knock jokes.

This is a transcript of a conversation between James Royal-Lawson and Per Axbom recorded in January 2019 and published as Episode 201 of UX Podcast. 

Cover art: Chain links by Howard Lake (CC BY-SA 2.0) Cropped.

Transcript kindly provided by Qualtranscribe.