March 27, 2019
Feedback we live for
- Make a compelling business case showing the large underserved market of customers to which no supermarket is making any attempt to capture
- Show how inclusive design and accessibility make the product better for everyone regardless of disability or impairment
- Let your leadership teams hear from customers who are being excluded from your services and how disappointed and frustrated they are by the experience
- Connect the work with your company’s values and mission - for example, pointing out that building accessible products and services is literally a ‘little help’
- Point out the legal requirements and argue the need to protect the business from needless risk of litigation
- Articulate how the careful design of well-designed, accessible, modular UI components means that while there’s an additional cost to their individual creation, the savings created by their re-use at scale are huge
- Talk about ethics - because fuck it, it’s a hot topic and why not use that too.
NOTE: none of this worked.
So good luck to you if you can make it work, but my experience is that while everyone will nod along and make the right noises, it’s rare that you’ll get the buy-in you’re after. At the very best people will ignore you and leave you to get on with things. So we just chose to do it and we were lucky enough to have a team of people that for various reasons didn’t care about what our bosses thought. In all other conversations that we’d had with Directors and leaders, we’d walked away with a the usual ‘it’s nice to have but it’s not a priority right now’. We all knew from past experience that our ethical arguments, our assertions about the Tesco brand, its values and our business cases would simply be ignored.
The reality was that I and a few others in the team knew we were fucking-off and so didn’t bother seeking permission.
Dumb luck and good timing
After yet another reorg, I found myself in the position of leading the design of Tesco Apps at a time when we were replatforming away from Xamarin and towards fully native Android/iOS apps. The state of the product design when I moved over to the team wasn’t great, and the team had been allowed to wander off deep into the weeds and were about to replatform and redesign the entire app. We quickly knocked that on the head, and moved to a far less stupid strategy of replatform then worry about redesigning anything, which meant a couple of things:
- Our focus moved from uncertainty about what the app might be to the specifics of what was worth keeping in the replatforming - we were now looking at the same app our customers were looking at.
- We released design effort from going into the act of creating certainty from possibility, which meant freed-up capacity for the team that could be directed elsewhere
So where did this capacity go? The team wanted to use it to lay down some strong foundations for the app in preparation for later iterations and change. There was a real sense in the team that the work we needed to do was to establish some clear principles and norms that would ensure that the app could respond quickly to our customers’ needs and expectations without creating unmanageable debt: the team wanted to make sure that we were making the most of that rare opportunity to start afresh.
The fact that we had people in the team who had already decided that they weren’t planning on sticking around definitely helped, and those of us who fell in that group were happy to provide the necessary cover for the team to do the work they believed in. For an
overhead manager like me, this meant shielding the team from too much attention and pitching the work as dull, pedestrian grunt-work that nobody would want to get too involved with. Telling people that ‘we’re literally just copying the old app’ meant the show-ponies and portfolio-building types saw no shiny thing and so ran a mile, and the perceived dullness of the venture meant that the programme folks twitchy about risk were reassured sufficiently to let things roll forward without endless status updates.
Accessibility, Parsimony and Utility
If I had to characterise those core principles that we wanted to establish, they were accessibility, parsimony and utility. One of the team, Rob did a little bit of genius-work and saw a way to link these to Tesco’s strapline of ‘every little helps’ and created a mnemonic which we came back to often.
Every = is it designed for everyone?
Little = have we pared this back to its essentials? And,
Helps = are we maximising for usefulness?
So right there, in our principles for the product was the intent to ensure that the app we were working on was accessible to everyone.
One of the things that we got for free when we started using native UI frameworks, was much deeper integration with the OS accessibility support. Given our principles, we’d have been idiots not to have made use of those and everyone in the team was interested and keen to use these hooks. I think we were particularly fortunate to be working with The App Business who provided pretty much everyone in the team working on engineering, testing and delivery as well as some truly great designers. TAB totally understood what we were trying to do, and the whole team there were as passionate and interested as we were about making the new app accessible to everyone - rather than seeing accessibility as an option or an aspiration, they shared our belief that it needed to baked in from the very beginning: in our UI design, in our development process, and in our tests and reviews. The team chose to use accessibility and inclusion as healthy constraints which guided us towards building a better product.
- Belief matters: everyone in the team felt that we had a duty to ensure that the new app worked for everyone: we had a strongly held shared belief
- Work with interested people. We had a team of people who were deeply interested in the mission we had set ourselves: to be the most accessible shopping app in the UK
- Choose the right constraints to guide the product development towards goodness - for us, that was accessibility, parsimony and utility. YMMV
- Trust and safety. We had a team that could be left to their own devices - I knew my role was to create the space for the them to make the right decisions, and ensure they felt safe to work in freedom
July 2, 2018
Doctrine Grid Tool
I wanted to use Simon Wardley’s very helpful set of universally useful patterns (aka Wardley’s Doctrine) in some forthcoming research I’m planning to do with a large organisation. When I’ve used it in the past it’s been pretty much as described in this tweet.
Print out some black and white grids, ask the person to colour each pattern in to denote how well developed the pattern is within the organisation (in that participant’s opinion) and then aggregate the data and use that to identify where next to focus attention. It’s a really simple, but very powerful tool.
So of course I wanted to make it a little bit more powerful, and because I’ve got a bit of time on my hands after quitting Tesco, decided to see if I could make a tool that captured everything using a form and held it all in a spreadsheet. My line of thinking here was it might be interesting to compare how different parts of the organisation saw things. It also meant that I’d find it easier when working across different countries.
Anyway, here’s where I got to with it - it’s very rough and ready, but it’s good enough. I’ve used Google Forms and Google Sheets. The form simply asks the respondent to assign a value (Good, Unknown/neutral, Weak, or Warning) for each of the patterns. The spreadsheet does the fun stuff, capturing everyone’s responses on the first sheet (with a summary result for each pattern) and on the second sheet taking all of the organisations’ responses and putting them into one of Simon’s original grids.
Please feel free to create your own copies for your own use. The easiest (I think, I’ve yet to confirm this) way to do this is to:
- Make a copy of the form builder
- Make a copy of the spreadsheet
- In the form builder, relink the form to your copy
Of course I’d really love any feedback or advice on improving the tool and I’d be completely overjoyed to hear if you do use them yourself, you can always find me grumbling about product and design on Twitter.
What needs improving
I really don’t like the way I’ve aggregated each pattern’s score for the grid, this is because I’ve no idea how best to handle things when half the respondents score a pattern as Good and half score it as Warning - clearly something interesting is going on here, but how best to represent it? With my information design hat on I’m thinking that there probably needs to be a better way to show the underlying detail rather than blocking it off with a single ‘score’.
When I was creating this, one thought in my head was, ‘people aren’t going to understand all these patterns without me being there to explain’. And when I asked for feedback from my friend Richard Warner who’s another keen Wardley mapper, he said (after doing some impromptu user research with his wife) that she was confused by some of the terminology and labels, such as Warning.
So yes, clearly room for improvement, but like I said it’s good enough for now. Like I said, let me know if you find it useful.
May 31, 2018
The shit chute
You’re a small team who are trying to change culture and practice within a large org. You’ve been set up well (like many other digital transformational teams) with strong, capable people who have done this shit before.
You know through experience that showing results, and showing a clear, detailed vision of what the ambition might look like gets attention and builds trust with the high-ups.
Build a case study, create an exemplar. So you start ranging around the org, looking for potential partners, people you can help make look brilliant by adding a little magic, bringing a bit of digital. And there you find the team, that one who get it, but just haven’t had the right people or investment to really move things along – they’re the one who are working diligently on that unloved, unsexy but deeply important thing that never had the chance to think about, let alone run as a product team. They’re excited, you’re excited.
But then word gets around, there’s a team who can help with design. They’re helping some bullshit team buried in the org, so surely there’s an easy argument that they can give a bit of time to that big, high-profile, super-important project that isn’t moving as fast as the high-ups want. So it begins.
“Why isn’t it working?”
“What do you know about your users?”
“How does this work with that?”
But the super-important project team don’t want those questions - they want you to pull together a deck that shows the vision (their vision). They want you to show what the thing looks like with that nice design system you’ve been building. They already know what their users need they’ve been working on this for years…
So you negotiate, a bit of the shiny for a chance to show them how they could be doing things better. Quid pro quo. You’ll help them with the short term if they open the door to the possibility of Doing Things Differently™.
And now, you’re part of the problem. Welcome to codependency.
When this project fails to deliver, when it continues to stagger around in circles, collapsing and spraying its dying guts all over the org, you and your team are going to have that shit all over you, just like everyone else who went near it with good intentions. Everyone will be to blame, so nobody will. But all that capital you built up in the team is pissing away because you got everyone’s hopes up and turned out to be just another bunch of bright folks who talk a good game.
So, what do you do next time?
You make a shit chute.
The shit chute is a process for making sure that if you have to deal with toxic projects, HiPPOs, JFDIs etc is that you get it through your team without ending up covered in shit.
Fundamentally, this means you accept that this will happen (because you’re a strong, capable team who get things done) and that you won’t always have the luxury of saying no. It operates on the following principles:
- You get this done and you do it fast, the metric here is speed. Treat it like a bullshit project at an agency.
- You don’t try and change the course, question the rationale, or challenge the process. This isn’t the hill you want to die on.
- You protect yourself from the shit by being clear about what’s being asked and delivering accurately and precisely (again, ex-agency people who have been good account handlers in a past life will be useful in your team)
If you can’t swallow this as an approach, then think about it as a sort of chaos monkey - this is a test of your team’s resilience and ability to handle randomness. This is about making sure your team live to fight another day.
It might be that you need to make this a more formal part of your team’s charter, that it’s part of the way that you all work: sometimes you’re on 20% time, and sometimes you’re helping on the shit chute. Point is that you don’t make this another team - it needs to be part of what the team does.
Last of all, another of the potential upsides for this along with the resilience test is that if the project manages not to collapse your team looks responsive, you’ve just built trust and a little bit of capital with those HiPPOs that you can save for later.
Yes, this is a weird thing to do. When I’ve spoken to people about this the reactions tend to be either uncomfortable laughter or disbelief. I think that’s because as designers we tend to want to make things better, and we belive that things would be better if only people listened to us and did things the right (ie. our) way. It plays against the narrative of designer as saviour because it speaks of the designer as shit-shoveller, which is precisely what all those Medium treatises and LinkedIn motivational posts tell us design really ought not to be.
I prefer a different approach, I believe that you have to accept the world (and more close to home, the products you’re working on) as it really is. If you really have no choice, then accept that fact and attend to it. Fighting against the reality of a situation, pretending that somewhere there’s something better out there that only you can bring to life doesn’t really change things in the world (or the org) you’re in.
If the shit is flying, then let it fly through chutes so your team is somewhat protected and maybe even makes them stronger.
May 21, 2018
Authenticity and integrity
I’ve had a problem with the use of authentic when it comes to describing some sort of aspired behaviour or way of being, but hadn’t quite got around to pinning it down until this tweet from the estimable John Cutler, who if you don’t already follow should do.
First up - this is purely about my personal reaction to the use of authenticity and I’m well aware that I’m blundering into semantics and risking a whole pile of dictionary-splaining. That aside, when someone talks about a person being authentic, it comes with an unstated set of ideas about what they’re assessed against: when a type of food is described in terms of being authentic cuisine, it’s because it’s been prepared or made in a way that someone or some group have defined as canonical.
To be authentic, the subject needs to be evaluated in regard to something else. It’s specifically that measureing-up which I find uncomfortable. To be authentic someone has to meet someone else’s set of criteria for authenticity rather than find their own.
When I work with my teams and helping people grow in their roles, I’m far more interested in people finding out and reaching their own potential, and I actively avoid the trap of tainting this process with my own pre-determined ideas about what I think someone could or should be. Obviously I can talk about what I’ve observed in others and relate my experiences, but fundamentally I believe that it’s more important that people find a way of being and a way of doing that works for them in a positive, healthy way.
I’ve found that rather than talk about this in terms of authenticity, that the concept of integrity yields a more valuable discussion: how do you live in a way that is sustainable and enables you to continue to develop freely? For me, the concept of integrity doesn’t carry any sense of a stopping condition - something can grow forever as long as it doesn’t collapse (i.e. lose its integrity), whereas authentic implies that movement away from the bounds of what’s acceptable causes a loss of authenticity.
April 21, 2018
Design Systems, brand and identity (part three)
Previously I’ve outlined why we needed to create a more systemic approach to building our digital UI and described how brand and identity play a role in this, in this final part I’ll talk about the design system that we built, which we called Tesco’s Digital Design Language and of course immediately gave the three letter acronym of DDL.
We created the DDL as a visual design system to address the challenge of our look and feel being utterly inconsistent across our digital estate, in fact we were often inconsistent within a product. The DDL is an initiative that was initally proposed to answer the question: how should our digital estate look to our customers? By getting the many design teams and stakeholders together we would create a specification for our most common user interface elements. By having standardised versions of these elements we created the ability to optimise and improve them for everyone, rather than at a local isolated instance - in effect, we created a feedback mechanism for our look and feel.
The second thing design systems like the DDL create is the ability to stop endless low-value debates about things such as, ‘should a button be red, orange, blue, rainbow sparkles’, ‘should a carousel have a stop button’, ‘how big are our headlines meant to be’, ‘how should we set up images to work responsively’ and so on. By having a standard, default specification, we allow our teams to focus on high-value problem solving and meeting customer needs.
Design systems like the DDL are a hot topic right now - businesses are recognising them as a way to consolidate and rationalise their digital channels, and using them to drive down operational costs, time to decision making, time to delivery and of course improving customer perception and trust. Indeed, some of the more pioneering businesses are open sourcing their design systems so that they get used, tested and improved by as many people as possible. Remember that Bootstrap was Twitter’s design system long before it became the web’s default UI.
These initiatives parallel similar system-wide approaches in engineering: shared architectural practices, code libraries and code standards. They all share the same idea of setting a common set of practices to allow greater autonomy and distributed decision-making within teams by trusting that they work from shared standards and removing gatekeeping.
Which brings us to the last piece of the naming puzzle - where visual design systems become UI design systems or libraries. We started the DDL as a system for designers, we avoided code other than where it was helpful to document how a particular interaction worked. But the thing we heard time and time again was from people wanting the code that the created the DDL elements so they could build with it. Engineers and developers are generally pretty sensible folks who like nothing more than a quick starting point. ‘Can you make a DDL version of Bootstrap?’ became something I had to regularly answer.
Late in 2017 we started work with the Technolgy function to extend the design system of the DDL into a library of UI components that are agnostic of the products they get used in. Technology leadership decided that they needed to build a set of core UI components that would enable distributed, autonomous teams to reuse, extend and contribute improvements to. Our collaboration with them created the foundations of a library, a distributed way of working centred around Github and the start of a workflow that ensures that everyone can participate and improve the library.
The power of having a living design system like this is that it allows us to very quickly build in a consistent way. Here’s an example of pulling together a set of off-the-shelf components to create a prototype of something like a new brand expression compliant Delivery Saver website.
Note that’s using production-ready code pulled from the Github repo. The editor you see around it isn’t ready for everyone to use, but you can easily imagine this being the starting point for a lot of our teams to experiment with different layouts and see how they respond across viewports. Tools and design standards like these mean that the domain experts in marketing or comms can solve their own problems and take a design all the way through to a viable solution that is potentially shippable.
This leaves our specialist design and engineering teams free to focus on the higher-value, higher-order problems. Design systems like the DDL won’t ever tell us how best to handle some of our unique experience problems like how we present delivery or fulfilment options, but they will free us up to stay focussed on that rather than redesigning yet another button.
April 20, 2018
Design Systems, brand and identity (part two)
This was intended to be about a talk design systems and how they relate to Tesco’s brand and identity. So let me start defining some terms:
Our brand is what people believe about us. It’s how our customers think about us, and how they talk to other people about us on the other side it’s about how we present our organisation to the world: are we a plucky underdog you want to win, a ball of energy transforming the everyday, or a giant moving mountains?
Our brand is not what we tell customers we are, it’s how we show ourselves to be. When people talk about brand within the business, what they’re talking about is the practice of making sure that the way we behave, communicate and express ourselves is consistent with our purpose. Just as we dress for work, become a little less sweary and don’t sit around with our feet on the desks, our business has thought about and decided how we as an organisation should present itself to our customers and investors.
We’ve invested a huge amount of time and money into revitalising our brand and defining what we really are as a business. We’ve made it simpler to understand what Tesco stands for: we’ve introduced clarity into what was a mess of competing brands and sub-brands. Again, for our customers there’s only ever one Tesco, so living up to this meant making decisions about how strong some of our sub-brands needed to be.
From our brand comes our identity. Our identity is how our customers recognise Tesco in its appearance and voice, it’s how we present ourselves to the world. Hopefully everyone’s seen our new brand expression, but if you haven’t then it’s exactly what you would expect: it’s how our new brand is expressed.
Our identity is important for a couple of reasons, one customer and one organisational. From an organisational perspective having a consistent, managed identity means that we are able to protect our business from people copying or passing themselves off as Tesco. The more diffuse our identity, the harder that becomes. And don’t underestimate the value of a well-managed identity…
From a customer perspective a clear identity helps establish and build trust. There’s an interesting psychological effect at play here: as animals we’re hardwired to look for signs of health and wellbeing, and more specifically to avoid any signs of ill-health: our brains like symmetrical faces for just this reason. When we see things that show harmony and order, our brains associate this with care and attention - we confer positive values on the thing we’re seeing.
There’s another bit of psychology going on here.
There’s a story about a magician called Vernon who was tasked with watching a great magician called Malini over the course of an evening’s dinner performance to try and pin down the great man’s sleight-of-hand secrets - in particular the block-of-ice-under-the-hat trick. Throughout the full evening’s meal, Malini never left the table. Malini then proceeded to perform the trick and when Malini lifted the hat, a block of ice the size of four fists lay in the centre of the table. While the regular audience members wondered how the ice got under the hat, Vernon was dumbfounded as to how the ice got to the table at all.
“Sometimes, magic is just someone spending more time on something than anyone else might reasonably expect.”
If you take this practice to the extreme you see brands like Apple spending ridiculous amounts on very small details - In psychology this is called ‘costly signalling theory’, but really all it means is showing that you are healthy enough to care deeply.
What I want is for us to see these details for what they are: creating protectable shapes and patterns, and creating the impression in others that we’re strong enough to worry about the tiny details our competitors aren’t able to care about. Do not underestimate the value of investing in identity.
So, to summarise: our brand has a way of presenting itself, that’s the new brand expression. This explains our tone of voice, how we shoot photography, the colours we use and in what proportions, the way we create signs and icons, our typeface and so on. This brand expression is what underpins the look and feel of everything we create: from packaging to store design to websites.
In the final part of this talk I want to talk about how we created the design system that ensures that Tesco’s digital channels look and feel consistent, considered and beautiful.