March 27, 2018
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
December 13, 2017
I’ve been thinking about value creation for the last week or so. I had beers with a friend and he made the crazily provocative statement that he felt like in his career there were only a couple of times where he felt that he was actually putting new value into the world, rather than just moving it around.
His line of thinking was that most of our working activity is spent moving value from one place to another, and that it’s rare that we ever actually put new value into the world. We talked about how design agencies we’ve worked at seemed to do a pretty good job of creating value for the founders/owners, which is nice but not exactly what we signed up for - despite my cynical tendencies, I fundamentally believe that the work I do is about adding value into the wider world rather than a few individuals.
Since then I’ve been thinking about how the larger organisations I’ve worked for might better be understood as systems designed to distribute power and money to the people at the top of the organisation rather than as systems to bring new value into the world.
The thought crystallised around the idea of rent-seeking, and the tendency I’ve seen amongst some senior managers and leaders to focus more on increasing their share of personal power and reward from their position than in creating new value from their position.
What does this look like in practice?
I think there are some common behaviours that you can attribute to rent-seeking leaders.
- Prioritising the appearance of productivity over progress
- Hiring of generalists and jack-of-all-trades
- Deep dissatisfaction in the team
- Focus on increasing the size of the team
- Excessive, often unnecessary knowledge brokering (usually between effective parties)
- Participant inflation in meetings
Appearance of productivity over progress
When a team is led by a rent-seeking manager, you can expect to see a lot of talk about progress and examples of interesting or innovative thinking. Out of context these seem impressive but don’t bear up under scrutiny and will mask a lack of significant progress. There will of course be explanations for this, often attributed to rogue team members or external factors.
A rent-seeking leader will tend to prefer team members who they can move around as a fungible resource. This allows them to appear effective by putting people where the most noise or demand is, rather than where they’re needed. By doing this, they avoid the accusation of bad hiring or the risk of their team being a bottleneck.
Related to the previous point, this is the outcome when your team is treated as resources to be moved around to keep other people (and with the rent-seeking leader that usually means superiors) happy. Expect to see people complaining about the cost of context switching, feeling like they’re skimming the surface of a problem, and in permanent fire-fighting mode.
Focus on increasing the size of the team
It’s pretty rare that anyone is specifically paid to have a larger and larger team, but a rent-seeking leader will almost certainly make this their core objective. Having a large team justifies their existence, and of course a large team is an effective tactic to gaining seniority in a big org. A large team also gives you plausible deniability (“I’m over-worked managing the team”) and people to lose should the business tighten its belt.
Unnecessary knowledge brokering
To get the most rent from your team, it’s important not to let other people get too much directly from them. Rent-seeking leader will place themselves between the team and other parties, controlling the information flows to ensure that they are perceived as the valuable contact.
Participant inflation in meetings
Rather than attending, processing and disseminating information from meetings this kind of leader will tend to pull in their team into as many meetings as possible. For the leader this means that their role in the meeting is simply one of presence, rather than adding knowledge, making decisions or saving time.
One way not to be a rent-seeker
Writing these down was easier than I expected, partly because I’ve spent enough time alongside and working for people like this, but never really managed to capture why I was so irritated by them.
Going back to my friend’s observation, and having thought about him and the work he does I’d suggest that one of the things he does, as a good leader is to invest his time and energy into helping his team become better practitioners and in creating an environment where they can explore and grow. That to me is a very tangible kind of value being created that might otherwise not come into the world.
August 7, 2017
When a company as large as Tesco creates digital products and services, they’re used by hundreds of thousands, even millions of people. As a brand we’re unashamedly mass market and aim to meet the needs and support the lives of the whole country. Designing for such a broad range of customers creates a fairly unique set of constraints and considerations on our product design teams including
I’ll leave the first three points for another day and focus instead on that last one.
This is a huge opportunity for large brands like Tesco. Moving from a technical mindset of meeting a set of accessibility criteria/checkpoints towards identifying and designing open, inclusive products that improve lives and benefit everyone.
Our design language and accessibility
I’m often asked whether Tesco’s digital design language is accessible, or ensures that a product built to the standard specification will be accessible. While the building blocks of user interface elements in the design language are designed to be accessible and follow industry best practice, it’s down to the consuming product design teams to put these blocks together in ways that create accessible, inclusive products. The simple fact is that it’s rarely possible to get accessibility for free - it has to be a explicit objective for the product team.
A better approach to inclusivity
A better way to approach this is to step back from the accessibility question and think more about the overall inclusivity of their product. Again, as a brand which is at some point part of the lives of most of the people in this country, it’s on us to make sure we’re ensuring that the products we create work brilliantly for the largest possible number of people.
One of the simplest things we can do here is to make sure our own biases don’t drive the design of the products we create: it’s very easy to use ourselves as a stand-in for our customers (think of those personas who are tech-savvy, time-poor, foodies) but when we do so, we often exclude whole groups of people who use the same technology but in very different ways to us, and often in ways that we haven’t accommodated in the design of our products.
When we design inclusively, we’re not designing a one-size-fits-all solution or creating a compromised lowest common denominator product. Designing inclusively means creating products that work for the diversity of ways people interact with them and the context they’re using them in.
For example, when we create effective products for people with a permanent disability such as having one arm, it benefits people with a temporary wrist injury or someone carrying a child. It was exactly this situation that we uncovered when we were working on a mobile version of our Scan as you Shop product: what we found was that customers carrying baskets are effectively situationally disabled and need a mobile app that’s optimised toward single handed use.
Approaching product development from this perspective opens up huge value-creation opportunities for not just existing customers, but whole new audiences too.
July 24, 2017
Observations, explanations and confidence
We’re in the process of creating an alpha for the store locator on Tesco.com, and we’re getting pretty close to the point where we’re ready to move into beta. For the last couple of weeks we’ve been building a prototype in the browser that allows us to test the decisions we’ve been making about the UI and to make sure we’re reducing the risk around moving into beta and production code.
Early last week, the team watched our researcher take people through some familiar scenarios in the browser and used a simple framework to collaboratively capture observations and insights from each session. As customers worked with the different variations of the alpha, the team wrote down positive, neutral and negative observations along with emergent research questions on colour coded Post-its which after each session were talked through and grouped on the wall. As you’d imagine, this method drives out a lot of observations and we weren’t exactly short by the end of the two days.
Many, many Post-its
In the process of reviewing the work, I’ve noticed that while we’re doing a good job of rolling this product forward and we’re improving the experience we’re giving our customers, we might not be being as effective as we can be in meeting one of the higher purposes of product designers which is to continually create better explanations of customer behaviours and their needs. If we don’t have solid, defensible explanations for why customers behave in specific interactions with our products, we’re at risk of jumping into the wrong solutions. In the spirit of continuously improving our working practices, we’re going to try out a revised summary report for product testing.
The new summary report
The act of creating explanations also requires us to state our confidence in those explanations: when we notice that customers are struggling to zoom in on maps in a UI we could explain this in several ways: the map is too small, the affordance to access a larger map is being missed, the gesture to zoom the map is unknown to the customer, or even that the scenario we’re looking at is biasing our research towards an unnecessary map interaction. For each of those cases, we can make assertion about how confident we are as a team with this explanation.
A statement of our confidence in any given observation allows the team to make a decision about whether we need further research, and also helps us decide what kind of testing at what fidelity we need.
Confidence vs applicablefidelity graph
One final point: even when we’re making positive observations about our products, these need to be accompanied by explanations: the explanation for why ‘The map view helped customers to identify closest store’ will be valuable to any other teams designing products that use maps and helps them to make better decisions when design their UI. By sharing our explanations we allow other teams to validate them and to build upon them, and create still better explanations which in turn leads to better product design and customer experience.
August 5, 2016
Why we do customer research
We’re used to using market research in Tesco, which is a powerful tool for building insight about large groups of customers or target markets. With our service design approach, we use customer research from the bottom-up and look closely at how representative customers interact with our existing or our possible products and services.
As a team, our purpose is to improve the way Tesco designs services, aiming for a joined-up and consistent customer experience. To be able to improve our products and services, we need to understand:
- Who the people are that use them
- What they’re using them for
- How they currently use them
Using customer research helps us understand how the products and services we’re designing will fit into the lives of the people they’re intended for.
Customer research doesn’t tell us what to build, but it can help us understand if the thing we’re building is going to be successful. It can also be used to help us understand where people are being underserved by the existing service. The work of taking this understanding and using it to improve the products and services that create Tesco’s customer experience requires careful, considered analysis and design.
So the role of customer research as a tool in service design is for illumination rather than validation: it doesn’t tell us if we’re right or wrong, it just helps us ensure we’re headed in the right direction and continually increasing our chances of improving the customer experience.
Why this approach?
There is a difference between research to learn about what people say they do (attitude), and what people actually do (behaviour).
Attitudinal research helps us understand what people think about things by exploring their opinions and stated beliefs, often in groups. This type of research is helpful in getting a broad understanding of how markets and audiences are responding to our products and services.
We tend to focus more on behavioural research: by observing how customers use our products and services in their lives we are more likely to be able to understand how to make them more appealing or valuable. The purpose of this research is to increase our understanding of how to make our products and services better for the type of customer we’re designing it for.
Key differences between market and customer research
Customer research (What people do)
- understand how people are solving the problems they have (these might be opportunities for new product/service dev)
- understand what needs customers have
- understand how we might help meet those needs
- to check our own assumptions and biases
- to understand how customers use our products and services
- Looking up close at how representative customers interact with our service.
Market research (What people say)
- Big picture or broad brush view of who will use a product
- look for patterns in consumer audiences and the market
- to segment demographics and buying behaviours
- Size market demand for a product or service
- Identify gaps in the market
May 12, 2016
Making Tesco’s websites more helpful by design
Before and after
Customers using Tesco online probably aren’t aware that our digital estate includes over 100 different websites and dozens of apps. But they do notice when something blocks them from getting what they need. They’ve been telling us they often find it difficult to move between different Tesco sites, and struggle with having to do things differently on each different platform.
So we’re changing. Last week the Tesco PLC website got a new look. This is just the first of many of our sites and apps changing in line with a new Tesco style: we call it Tesco’s Digital Design Language.
The Digital Design Language is a toolkit to help Tesco teams create websites and apps in a way that ensures they’re recognisably ‘Tesco’ and designed to be helpful for customers. How? We’re doing this by creating a set of commonly used elements (like forms and buttons) along with some basic rules for colour, fonts and layouts that help teams to build quickly and consistently.
Everything we design is guided by how we can serve shoppers better; such as making sure that the ‘Menu’ option is always in the same place so it’s easy to navigate around our sites. And every element is tested with customers so we make sure we’re implementing the easiest, most user-friendly elements. We’ve defined colour and sizing rules to make clear the difference between words that are there to help people navigate (such as ‘Next’) and words that are part of the content of the page. On their own these are little things, but when they add up they will make a big difference to our customers just by making their online experience smoother.
As you can see in the PLC site, the new style is much simpler, and less-cluttered. This means the stuff that’s most important to our customers, our products and content, is easy to find.
This is just the first of many improvements and marks an important stage in Tesco’s digital maturity. In the past we’ve worked hard to create many different ways to meet our customers’ needs wherever and whenever they arise, and it’s now time for us to start joining those various pieces together into a simple, more consistent, more joined up experience for customers. Watch this space.