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.
March 14, 2016
Digital Design Language phases and why we have an iterative design process
We’re building Tesco’s Digital Design Language (the DDL) like a product, using iterative design to continually optimise the guidance on the toolkit.
This means that we’re open to hearing how the toolkit, which is where we publish the specification can be improved. DDL is a collaborative project with teams across Tesco participating in its creation. It’s not a case of ‘us’ setting guidelines and ‘them’ picking holes in it: we all work together to produce the best design language that works for the whole of Tesco. We bake this into the development of the guidelines by incorporating people across the business into the studio team, as well as having weekly critiques with the heads of design. We reinforce this by gathering feedback once we have guidelines we feel are ready to implement.
That’s why we don’t go straight into publishing guidance on the toolkit and designating it as The Release. We have a beta phase for each element of at least four weeks during which we look closely at how the DDL element is working in practice for our various digital properties. We do stress test designs extensively during the design and development process so we’re confident in the guidance but there’s no substitute for real world evidence.
Most guidance you see on the toolkit is in at least beta testing, but here’s information on what each status means.
Pre-alpha is the design phase, lasing four weeks.
While in pre-alpha, we scope exactly what elements are in scope, before designing the elements. As part of this work, the team looks at how the designs would change how current and known future sites look. They’ll also look at logical groups of elements together, to test that they make wider contextual sense.
We do not typically publish work in progress during this phase. Instead, we hold weekly heads of design meetings to gather feedback.
Something designated as ‘Alpha’ on the toolkit has gone through the design phase and is currently in development, meaning that it’s being coded up in the DDL prototype and the guidance being finalised.
Typically, if guidance on an element is published while it’s in alpha, it will be the design PSDs or presentations that give a sense of the design work that’s gone into the element.
Alpha guidance is subject to some change, depending on how the interactions work in the browser. We don’t usually expect the look of a design to change at this stage, however.
Something shown as ‘Beta’ on the toolkit is reference design and code, available for consumption by early adopters and anyone else. As it’s beta, we might refine the guidance based on results from testing.
If you’re using beta elements, let us know, as it’s really important to have the results from real-world usage feed into the toolkit.
When we’re confident that the guidance is stable and not subject to change from testing, we designate it ‘live’. It can be considered the stable release version of the guidance.