A look at the processes and structures that support commercially successful product design. Jane will draw on her experiences from across her career, focusing specifically on The Telegraph and MOO. She will present four case studies from The Telegraph, each one emphasizing a particular aspect of design methodology. They will exemplify how her processes evolved to allow her team to ship well designed software at speed, maximising their effectiveness while minimising waste. Jane will then turn to her experiences at MOO, explaining how to lead an effective design team in an organisation that is scaling Agile. She will present the structures, the day-to-day processes and the lessons she has learned.
← All talks 
Build Product Turing Fest 2017
All the Things You Need When You Want Great Design
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
APPLAUSE Hello Edinburgh, my God, what an honour to be here, thank you so much for inviting me. Name is Jane Austen, I am Director of Design and User Experience at the very lovely MU, and I'm here to tell you about all the things you need when you need great design.
Actually, that's a lie. I'm going to tell you about some of the things you need when you great design, because I've only got thirty minutes and in fact that's still not entirely true. I'm going to tell you about some of the things you need when you need great design, specifically for design for brilliant digital products.
I want a cheer or a groan, you can give me a groan if you recognise any of these. Anyone doing upfront design with one round of research at the end? Yay. Anyone when a designer says to you I'm the expert? Anyone recognise this? Yay.
Designers delivering over complicated solutions to prove they are a genius? Anyone calling themselves a design genius? Designers disparaging other people's opinions because they are not designers? They just don't get it. Being unable to integrate MVT into design so you gradually get this Frankenstein site, it's what the business wants.
Has anyone ever said to you it's what the business wants? Hoards of marauding BA's giving the design team a list of requirements to colour in? Defensive documentation. And design team with no connection to data or KPIs. This one is a bit controversial. Product managers overly invested in metrics and experiments.
I know, what I mean by that is overly invested, you should be invested but not overly invested because if you only look at metrics then you are seeing the things that have already happened, they are lagging metrics, it is the past, you have already lost these users, and also it means you haven't got the why, so having qual earlier helps you lose less of these users.
Also the other problem with metrics is they don't help you understand unmet needs, and often experiments, just doing experiments at the end means you miss data from segments that you really need to learn from, such as non users. And last of all, designers that are unable to adequately understand the impact of the work, and it looks a bit like this, you have the design team, you have the dev team and the design team is throwing design at the dev team.
So what you really need is this lovely unified crew, because good agile design happens when we have a truly cross functional crew with research actually happening in the crew. So I think we all know that good development means fairly autonomous teams doing test driven continuous delivery, But what does continuous design for continuous delivery look like?
What is the role of the designer in a fairly autonomous agile team? I believe that to ship great products you need to move from the genius designer working alone, saving the world, then to the lone designer in the crew hanging on by their fingernails, feeding this great development beast doing continuous delivery, to someone who facilitates the team to make great decisions to support design.
In other words, you need a designer as a facilitator. So I don't mean facilitating workshops with clients, I mean a designer who works with the crew responsible for building the project, helping them understand their user and the problems that they are trying to solve for.
What I mean by a designer as a facilitator is someone who actually designs the problem space, someone who builds a shared understanding with the crew, someone who designs the research but brings the team with you and helps them participate in that research, someone who empowers the crew to solve the problem together, who supports the product manager to make good decisions and of course executing on the solution.
I'm going to show you what that looks like. This is our logo, when I worked at the telegraph we did a project called authoring, before that we had done a project for the world cup and delivered this tiny micro site for the world cup using Wordpress, it worked really well, but most interesting thing that happened is some journalists came to us and said dude that is the best CMS I have used in my life and we were but it's WordPress.
They were like no, trust us, it is the best CMS we have used in their life and this is why. This was the CMS they were using at the telegraph and all these red arrows point to all the things they had to do to get a news story with one picture live, it was hell.
So we quantified it, product managers love metrics, strategists love metrics, and we went out and did some ethnographic research and we looked at what it took to get a story live, we looked at different types of stories, different types of days, we summarised it and it took, for example, the picture of the day, it took nearly two hours for these superb Oxford educated graduates to manually put together the picture of the day.
If you had an article with an image, was just a very simple crime story, it took half an hour with nearly fifty eight steps. So we decided that we would fix this. We did all of these workshops with the journalists and asked them to map end to end how they wrote a story and put it online, but one of the challenges was from the CFO, he said we have all these tools already and the journalists don't use them, so what is your plan, how are you going to get the journalists to use your new product?
We built in a secret weapon, we built in happiness as a KPI, because we thought if we make the journalists happy, then they are going to use it. One sweet sorry about the terrible picture, this is the original picture and it was taken on a really crappy phone, but I thought I would show you the original one.
So we did this workshop with batches of journalists and asked them to map the story end to end, and we also asked them to say what makes them happy and what makes them sad. So you can see down at the bottom there is a whole cluster of stuff that made them really sad, down here.
That was just putting an image into a story, so we thought right, that's what we are going to fix first. And here's our very, very first roadmap, and can you see behind that's the Telegraph newsroom, which is pretty awe inspiring. So I was there the day of the Paris attacks and it's like this army just swinging into action, it's absolutely incredible, it's such a privilege to work there.
So this was us doing the first version of the roadmap, which was sorting out how to add an image, and then we tested, we measured, we iterated, we built a prototype, we moved from the prototype and then we started shipping and we made sure that we tested every two weeks as part of the sprint cycle with users and the users here were journalists, was actually pretty easy.
So this is the group of the people in the larger crew that were entrusted to make design decisions and as I said they were testing this every sprint and we called this testing Tuesday. It became part of the cadence of the sprint and of the newsroom and the results that the team came up with after reserving all this research is incredible.
So each one of them agreed that they could get to a better solution faster because they all took part in the research and they all understood what problem they were fixing and why. We had another secret weapon, we got the CEO involved, we got him to come and observe the research as well.
Actually, I read a great quote the other day, said that the more senior you get, the more people tell you everything is okay. By the time you get to be a CEO, you have no idea what is going on and you think everything is okay.
So tell your CEO that everything might not be okay, to get him to go and watch people using your product for him or herself. I don't know if you can remember how hideous it was, this is what it looks like now. There's the base, and I'm going to show you in action.
It's built on Adobe Experience Manager, because reasons, but it is fully portable. So you see it is so incredibly calm, you just show people what they need, when they need it. We had to create a digital asset management tool, so this meant we weren't able to duplicate images.
Now you could just go and simply add it in, easy as that. And then we also discovered that journalists like to write in Word, no matter what you did, so it's fine, let's work with that, so you could just cut and paste from Word into the CMS, then you could do some formatting directly into the CMS.
So you see it in action here, we had some issues with tags and actually who owned the story, it was really difficult to sort out, but again just doing lots of rounds of user testing we cracked it. I'll just show you, I'll move on once I've shown you it getting cut and pasted, there you are.
There you go. Pretty much in about two minutes you can publish your story, so remember before and after. So before we got to work on this, it took half an hour to publish an article with an image, once we finished it took four minutes, and look at these wonderful quotes, praise Jesus, I like the slightly kinky public school one, oh look it's telling me off, I like that.
It's the apple of CMS', that was lovely, very lovely. The one that did annoy me was even my mother can use this, I don't like mother's being used as a unit of stupidity. We learned here was using facilitation techniques explore the problem space with the team.
Everyone knew the same thing at the same time, which meant the team had a shared deep understanding. We had strong opinions lightly held, so you disagreed, commit, test and iterate. What I mean by this is you could argue for hours about anything, but eventually someone has to carry the day, so the rest of you go, okay, we disagree, we will commit, we will make that happen, we will see what happens, if it doesn't work we will try something else, if it does work then I have genuinely learned something.
Also, from zero to one, you need to bake in analytics from the start. For example, we had a button that said add all, and the editors were convinced all of the journalists were using this add all button and it was a big problem and they were going to be adding in too many things and it might be a disaster because they might be using some images that weren't actually copyrighted properly, we said well let's see, and it turned out that it wasn't being used at all,
and had we not had that analytics from the start we would have been in such a mess. The other problem was there was a concern that there might be too many people publishing at once, we thought right, let's ship and see, and actually that wasn't the case, it was fantastic.
So, I truly believe that you also need cross functional crews, these are a driver of good design. Personally, this is a bit controversial, I would add co located to this, and most importantly I would add fairly autonomous. I'm going to explain what I mean by this.
This is at Moo, this is our crew and tribe structure, it gives you a sense of how we are set up. You can see that the crew is mapped to the customer journey from browse to buy to purchase and then we have the team responsible for the platform where you can make your business card or your flyer and so on and we have one crew who deal with our business customers, are called MBS and our clients are Airbnb and other very big global tech companies and we have a very famous sportswear
brand and a challenger bank amongst others, but obviously I'm not allowed to say actually who they are, use your imagination. So the company's strategy and bets flow to these crews and these crews use OKRs to define their work and execute on their strategy.
First we will take a closer look at the crew and I will use Pixel here as an example. This is Pixel, and that is the very, is pixel TV where they broadcast who is in the team, what they are doing and I think very interestingly team health and happiness.
I think if a team is doing good work, if they are working on what they believe in, if they feel they are executing well or even excellently, it's likely what they are producing is going to be good. So I feel that the happiness of the crew can be used as a leading indicator of a quality product.
By the way, that's the pic of the very loved Nabil, yay! It was a decoration from a party thrown from him. This is the make up of the pixel crew, you see we have two designers, one tends to more strategy and research and one to visual design.
But our aim is to eventually grow everyone who wants to into a full stack designer doing UX, UI and summative research. I love this picture, this is from a Wee Wee, it's an installation called Bang and I'm using this to illustrate the concept of the three legged chair.
You may or you may not have read Alex Schleefer, he wrote a really interesting blog post, he's the VP of Air B and B and he wrote this blog post about the three legged stool and he said for a really good start up for a product company, product, tech and design need to be the three legs of the stool, you need to have them balanced and present from the start, otherwise the stool becomes wobbly.
In other words, you have trade offs in decisions that lead to a less than designed great product. Do you know what is better than a stool? A four legged chair and if you add wheels and make it super fast you get a quad!
This is what we have at MU. We have quads, which is product, design and tech and are supported by an agile coach to help them make great decisions and to support them in those difficult conversations. There is not really any defined ways of working, each crew maps us to themselves, you can see this is the pixel crew in action and they take all the things they have to do, all the different activities and they work out which one, which person should be doing which kind of activity.
But we do have some principles for how we see the quad working. Each discipline has kind of pool factors, force fields that attract certain types of work and responsibilities. The idea is that responsibilities are aligned and agreed based on the context and the people playing these roles.
In fact, if you didn't have a designer, that designer may be replaced by an architect. As trust develops between these roles, you should also be able to alternate attendance at certain sessions, which means that from having one or two people attending a meeting, you have the entire team's perspective covered.
Again, that's what I mean by consent, not consensus, you don't have to have everybody at every meeting for everyone to be actually represented. So what does this look like? Product is concerned with building the right thing, they shape the future of the product and they inspire the world with their product vision.
EXTs, that's us, they help validate the needs and value prop, and they're also concerned with which is build the thing right. And you see tech is concerned with building a great product and creating sustainable scalable products, and they are sitting between build the thing right and then we have the agile delivery coach, who supports us to facilitate team meetings and who enables a happy healthy team.
Between us all, we delight customers, yay! We build, run and own and iterate on great products and team hugs. So we need design at every step of this process, so I just mentioned there build the right thing and build the thing right, I'm going to illustrate this with the classic double diamond.
So build the right thing is when you are trying to work out what you should be doing, we use generative research to understand this, and build the thing right is summative research, we actually achieved this? But I propose there is more to this than the double diamond.
We also need to think about shaping the problem space. Before you start working on a product, you have to think why is it there, why should it exist in the world. As Donald Rumfield said, there is unknown unknowns, so we do contextual enquiry and anthropological research to uncover unmet needs and to inform strategy and we're very lucky that our head of research at MOO is a trained anthropologist.
And then after this, at the other end, we ship the way our designs exist in the world is that they are shipped. And it's likely that we might build and release several versions which allows us to do MVT. Sometimes we don't do this, sometimes we just ship, see what happens and roll back, whichever we do we get a direction and then we start shipping increments and building on this and it's our job as designers to work with the product manager and the tech lead to decide what is the smallest thing we can ship to
get value into the hands of our customers or to learn and then what should we do next in what order. Everything we do should be about giving maximum value to the customer or revenue the minimum effort. Don't say I'm lazy, but that's We do this so this is shippable.
So in other words, we need to break the design apart into shippable increments that the crew can deploy and we need to look and understand the data and signals from these increments so we can adjust course as necessary. I'm going to show you some of the tools and processes we use to make this work.
Shaping the problem space, as I said, this is really the exploration of unmet needs, of potential services and value propositions that don't yet exist, but which are modelled on observed but unarticulated needs allied with business strategy. This is a space where innovation happens.
Once we have a clear understanding of the problem space, need to operate in and we can move right across this. This is an example of a cultural probe, these are one of the tools we can use to explore the problem space. A cultural probe is like a diary study on steroids, we can send cameras, prompts to record things at particular times, a diary, and other ways where you can remotely take part in the participant's life and understand what problems they might be facing that you could never get from one hundred interviews.
At this stage, you are observing with no expectation, either in person or using something like the probe, and the aim is to uncover needs your customer has that no one else is meeting and that they themselves can't express or articulate. Another situation could be that there is a segment with specific needs you are simply not meeting, so you might consider some adjacent products or changes to an existing product, but if you are a start up finder, this is a way to go out and find a business.
Once you find them, need to interrogate them. Is this actually a business your problem should solve? Is there money there? If so, how? So this isn't qual alone, you need to weave quant and financial data into this to understand and unpack the problem space.
So next we move to build the right thing. This is the point as we work out what problem we are really solving, It is really important to be comfortable with ambiguity and to circle down into the right solution. During this phase, the designers work quite ahead of and largely independent to the crews, but still very closely with their product person, and they provide context and clarity to strategy.
Their job is to engage with business strategy and understand how to map this to user needs. One way to translate it is this, so this is a problem statement, so this is a way to translate business strategy, company briefs, company bets into this problem statement.
It might take several attempts to get that right, but that's fine, because it exposes differences of opinion and most importantly it surfaces opinions. This is another way that we surface opinions, we add these to a lean canvas, but most importantly we don't just surface our opinions, we don't just call them out, we assess them to see which are the most risky to the business or the project, and those assumptions are the ones we deal with first.
So before even thinking about the MVP, we do our riskiest assumption tests. I love this quote, that was from Naville as well, so among competing hypotheses, the one with the fewest assumptions to be selected, so we unpack our assumptions, then we work out hypotheses and we put these on a hypothesis backlog.
This is one from the telegraph, so I'm showing you an out of date one because these can be quite sensitive. So every crew has a hypothesis backlog and it's prioritised by the designer and the product manager and it's used to structure research and experiments, it's something we use across all phases of the design process and it's great, it captures things that people might mention just in passing so they're not lost, but it's important to know it's not a separate backlog.
When we started using these there was some concern that we had separate backlogs, but that's not the case. It is not development driven and it can record any form of opportunities and a place to log this. You prioritise and group it so you can investigate, and then it allows us to input into the roadmap and OKRs.
It took us about six months to get this up and running at Mo, but it is a way to formulate why you are doing the design, what problem you are solving and how you know you have solved it. I am going to show you this in action with the MBS guys.
This is Build the Right Thing phase in practice, and this is how we circled in on what the MVP really is. This is the MBS team in Providence. I mentioned earlier that MBS are a B2B team with all these unnamed big brands. This is the workshop that our sales guys and account managers were having with our design team, because they reported that we didn't have any approval flow functionality on the platform and if they had it, they were going to be able to close sales with bigger businesses.
Can see this right now, this is the team working out what the problem was with the sales guys and the account guys. By the way, guys and account guys are excellent customer proxies, if you can't get actual customers, go and talk to your sales guys.
I should pause at this point to explain what an approval flow is. In many businesses, the individual needing the print is not the same individual who is buying the print and is not the same individual who is actually using the print, so different people need to approve different things like cost, quantity, copy at different times and really big businesses were struggling with this.
Here is the output from the workshop, we also did some customer interviews to validate this and we ended up with what seemed to be a pretty well thought through solution and at this point theoretically we could have just started building, but it is actually really hard work to work out what your MVP is.
In fact, I have often heard tech teams say to marketing, when marketing basically knows that nothing ever gets iterated, marketing tries to shoehorn any kind of crap into it and the tech team goes no, it's not on the MVP. That's not an MVP, that's not when you push back on all these crazy requirements.
An MVP is a way to work out what is the smallest thing you can do to really get value into customers' hands and as many customers as possible. We reviewed our assumptions and realised that we didn't know that one approval flow would work for all businesses, we thought actually businesses aren't homogenous, will it really work?
It has worked for the ones we have talked to, but do they represent all businesses? This is the biggest and riskiest assumption of all. So what we did, we created this straw man, we sketched what the approval flow might look like, and it's quite good, you should show the thing, when you're interviewing people, if you show the thing, people really understand what you're talking about so much better, so we showed the thing, but we did it typically in sketches because people feel so much more comfortable critiquing something that feels thrown away.
Here the design was like a prop for conversations, it was a provocation. To be honest, we really hoped that our initial solution would work with some flex, but it didn't. That can be really disheartening at first, but I think this shows as a designer you need stamina, you need to be comfortable with failure and with ambiguity.
So what we discovered, different companies are different, yay! Even different departments are different. It's important to test your assumptions with real customers and potential customers as soon as possible. You can see each one here is different, we have got the flow between somebody ordering, somebody buying, somebody paying.
So we realised actually the best thing to do was just build an email, an email that told people to go and check something out, it was as simple as that. It was better rather to meet the needs of a small number of customers perfectly, or a partial solution that worked for everyone and it was easy, quick to build and we could learn from, it was a no brainer, we went for the email.
So even though what we knew our MVP was, we still had loads of unanswered questions and that's when we moved to build the thing right. So the email on the right is the straw man and the email on the left is what we have now.
How would we get there? So if the email acts as an alerting system as a way to prove, as well as a way to prove, who gets alerted when? How long do they have to approve? Should they actively or passively approve? So we needed lots of further research to execute on this sort of detail, as well as things like the positioning of buttons, the language, the detailed interactions and so on.
This is the point where it's really important to get your crew to take part in research, this is when we say research needs to be a team sport, because if the entire team observes the research together, discusses the findings and agrees on the solutions, that week you get these amazing conversations.
So we've had conversations where the dev said oh I can fix that, it's one line of code', and we were like we had no idea! It's absolutely brilliant, it means you can move really fast and at speed. It also means you lose the crazy defensive documentation and the devs know why they are building something which is really motivating.
So then we assess, sorry, went back one, there we go, so this is a post it note exercise where we have all observed the research and then everyone agrees what they saw, and then we work out how we prioritise our research findings. So we have a slide set up like this, with user valuerevenue on one side and technical difficulty on the other.
So top left, we should do it, it's easy and important, bottom, why should we even bother doing this, it's not really a problem and it's really difficult to execute. This is what it looks like in action. This is how we get shippable increments, so we decide what to build and then we work out what phases we should build in.
As I said, the MVP is not enough, it has to be broken up even more, so you need to bring your knowledge of the customer and work out with product what is next to build. Don't give the dev a file with loads of annotations and expect them to work out what to build in what order, that's your job as a designer.
You need to create small enough increments that the team can pick up and run, you are not feeding the beast, have clearly thought out what should be happening when. The tech team is continually deploying, you need to understand what is deployed when, and then you need to know what has changed so you can monitor the result.
This is also a really superb way to approach the NVT, because if you aren't certain which two solutions to ship, ship both and monitor, and because you have isolated the changes you get a really clear picture of what has caused the impact. I'm going to demonstrate how we did this here, this is shippable increments for Moo.
So, this is what we thought, this is us solving the problem, we have a drop down menu on our tool where you create your print products and it was absolutely crazy, it was filled with loads of fonts, some of them with strange names, this was an internal tool and some of the fonts actually had the names of our internal clients and we thought right, what we should do is highlight the name of the font so people could recognise it, this is a great idea, and then we discovered actually this wasn't solving the problem,
people just needed a nice simple list that they could access and search, what was the next thing we should do? Would it make sense to highlight which of the fonts they were searching? Actually that didn't really work out, we saw in the data that wasn't great.
So what we did then was we showed what they had recently used, and that worked really, really well. So you can see this way we are just building up and we are shipping small increments and each one is making the product gradually better, rather than starting with that one on the left, because we wouldn't have known what had worked and why.
I have a particular problem when I shop online, don't know if you do, does this ever happen to you? Or this? Or this? Or this? Our customers at Mood actually had the same problem, they were buying cards and being really surprised at the size of them, even though we tell them.
So we were finding from our customer feedback that loads of people were returning the cards because they didn't know, they were like why, I wasn't expecting this?' So there were lots of things we could do to solve the problem, we could have changed the page, we could have punched up the dimensions of the card, we could have done so many things, but we thought what is the absolute simple thing we can do to solve this problem?
Give a bit of scale. So you see that using these shippable increments doesn't just have to be around what you are doing with the tech teams, if you are a designer you can also think what is the simplest thing you can do to solve the problem?
So when you build, what I want you to think about is the design process needs to be collaborative and iterative, and you need to work with your team to iterate, to create solutions, and ideally once you are in the phase of building the thing right, the entire team should be looking at the research together.
You don't need huge amounts of research documentation, if everyone is looking at the research together, they have a shared understanding and you can just have a conversation. Sometimes you don't agree and that's okay, you just disagree and commit and you have to put your heart and soul into it once you commit.
Not everyone is going to be in every meeting or research session, so you have to have enough info and enough trust in the quad, you need consent not consensus. You have to plan your shippable increments ahead that deliver value and then you need to track the metrics and signals.
So being a designer here is so much more than just making something look good. But then I mentioned MVT, and you have lots of crews working fairly autonomously, well this could be a problem, so we also need to make sure that we ensure consistency.
The way that we do this, so this is based on our approach to Bradfoss's principles of atomic design, it's simple. So here we have a page, and we strip away all the detail of the category page, you're left with a template, and then when you break and isolate the page sections you have organisms, and then when you break the organisms down you have a molecule, and then when you break this tile apart you have the atoms.
So we take these patterns, they are in a master sketch file, also includes guidelines, which is here, and we also have a craft library, this is craft from Envision. So here's somebody using all our different templates, certain molecules to build a page. We have the equivalent in our tech department, which is a shared code base between engineers and all crews and a style guide accessible by the whole company.
You also need the right people with the right attitude, this is difficult. You have to be comfortable with ambiguity, you need to fail and get back up all the time, that means stamina and you mustn't take failure personally, you have to have emotional resilience, you need to see design not just about great execution but to bring your business along with you, you need to be a strong peer to tech and product, and you need to be comfortable with healthy and productive conflict, you need to know when to fight,
you need to be comfortable influencing strategy as well as executing on it, and it is really difficult. I would describe hiring as like human tetris, trying to find the right bricks of people, personalities and then gel them into a team. The added complexity is everyone sits in two teams, their design team and their crew, and that's pretty much all I have been doing for the last six months, we are still looking for a researcher if you are interested.
And there is the Moo crew, who are all here today, yay! And we also need an amazing VP of products, which is actually the second secret reason why I am here today, Moo is hiring for a VP of products, so if you like what you heard about our approach, our technique, our philosophy, come and see me and we can talk.
So thank you Edinburgh.