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.
[00:00:04] Hello Edinbugh! My God, what an honor to be here! Thank you so much for inviting me. So my name is Jane, Jane Austin. I'm director of design and user experience at the very lovely MOO, 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 gonna tell you about some of the things you need to integrate when you need great design because I've only got 30 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.
[00:00:39] So I want a cheer, or a groan, you can give me a groan, if you recognize any of these. Anyone doing upfront design with one round of research at the end? Yeah. Anyone where the designer says to you "I am the expert." Anyone recognise this? Designers delivering awful complicated solutions to prove that they're a genius? Anyone calling themselves a design genius? Designers disparaging other people's opinions because they're not designers? "They just don't get it." Been unable to integrate MVT into holistic design so you gradually get this Frankenstein site? "It's what the business wants." Has anyone ever said to you that's what the business wants? Hordes of marauding BAs giving the design team a list of requirements to colour in? Defensive documentation? And design team with no connection to data or KPIs.
[00:01:45] This was a bit controversial: product managers overly invested in metrics and experiments? Oh, I know. What I mean by that is over, overly invested. You should be invested but not overly invested because if you do it, if you only look at metrics, then you are seeing things that already happened. They're lagging metrics. It's the past. You've already lost its users, and also means you haven't got the why. So having all earlier helps you lose less of these users, and also the other problem with other 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.
[00:02:26] And last of all designers that are unable to adequately understand the impact of the work, and it looks a bit like this: So you have the design team, you have the Dev Team, and the design team just kind of throwing design at the dev team. So what you really need is this lovely unified crew because good agile design happens when you 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 and 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? So I believe that to ship great products you need to move from a 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 of clients.
[00:03:33] I mean a designer who works with the crew responsible for building the project, helping them understand the 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 a product manager to make good decisions, and of course executing on the solution.
[00:04:03] So I'm going to show you what that looks like — this is our logo, when I worked at the Telegraph, we did a little project called Authoring. Before that we'd done a project for the World Cup and we delivered just like tiny little microsite for the World Cup using WordPress. It worked really well but most interesting thing that happened to some journalist came to us and said "Dude. That is the best CMS I've used in my life!" And we were like "but it's WordPress." And they were like, "No, no. Really, really trust us. It is the best CMS we have used in your life and this is why." This was the CMS that they were using at the Telegraph, and all these red arrows point to all the things we had to do to get news story with one picture live. It was hell.
[00:04:46] So we quantified it. You know, product managers love metrics. Strategists love metrics. And we went out: we did some ethnographic research, and we looked at what it took to get a story live. So we looked at different text stories at different types of days, summarized it, and it took, for example, the picture of the day, it took nearly two hours for these like superb Oxford-educated graduates to manually put together the picture of the day. If you had an article with an image, which was just a very simple crime story, it took half an hour with nearly 58 steps.
[00:05:19] So we decided that we would fix this. So we did all of these workshops with the journalists and we asked them to mark, end to end, how they could write 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 journalist don't use them. What's your roll-out plan? How are we going to get the journalists to use your new product?" And we built in a secret weapon. We built in happiness as a KPI, because we thought if we make the journalists happy then they're going to use it. So once a week, the sorry about the terrible picture, this is the original picture and it was taken on a really crappy phone, but I thought I'd show you the original one. So we did this workshop with batches of journalists, and asked them to mark the story end to end, and we also asked to see what makes them happy, and what makes them sad. So you can see down at the bottom there's a whole cluster of stuff that made them really sad ... and that's actually, that was just putting an image into a story, so we thought, "right, that's what we're going to fix first!" And there's our very, very first road.
[00:06:17] And 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 is absolutely incredible. Such a privilege to work there. So yeah, this was us doing the... We did 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 it was a com, and the users here were journalits. It was actually pretty easy. So this is the group of the people who, in the larger crew, were entrusted to make design decisions. And as I said, they were testing this every sprint, and we called this Testing Tuesday, and it became part of the cadence of the Sprint, and of the newsroom, and the results that the team came up with after observing all this research is incredible. So each one of them agreed that they could got to a better solution faster, because they all took part in the research, and they all understood what problem they were fixing and why.
[00:07:18] We had another secret weapon. We got the CEO involved. We got him to come and observe the research as well. And actually, I read a great quote the other day which said, it was to the effect, "that the more senior you get, the more people tell you everything is okay. And By the time you get to being a CEO, you have no idea of what's going on and you think everything is okay."
[00:07:38] So tell your CEO to... that everything might not be okay, to get him to go and watch people using your product for him or herself. So I don't know if you can remember how hideous it was. This is what it looks like now. It's the base, and I'm going to show you an action. So it's built on Adobe Experience Manager, because reasons, but it is fairly portable. So you see, it's 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 that's fine. Let's, let's work with that. You could just cut and paste from Word into the CMS, and then some formatting directly into the CMS. So you see it in action here. 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. So I'll just show you. I'll move on once I've shown you it getting cutted and pasted... There you are... Here you go... And pretty much, in about two minutes, you can publish your story. So remember before and after. So before we got to work on this, took half an hour to publish an article with an image. Once we'd finished it took 4 minutes, and look at these wonderful quotes.
[00:09:26] I love that one: "Praise Jesus."
[00:09:29] I like the slightly kinky public school one: "Oh look it's telling me off, I like that!"
[00:09:35] "It's the Apple of CMSes." That was lovely, very lovely.
[00:09:39] The one that did annoy me was: "Even my mother can use this." I don't like mothers being used as a kind of unit of stupidity.
[00:09:47] So what we learnt here, was using facilitation techniques to 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, and we had strong opinions lightly held. So you disagreed. Commit to test and iterate. What I mean by this is you could argue for hours about anything, but eventually someone has to carry the days. So the rest, we go, okay we disagree but commit will make that happen. We'll see what happens; if it doesn't work we'll try something else. If it does work then I've genuinely learned something. And then also from 0 to 1: you need to begin analytics from the start. So 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, "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.
[00:10:47] The other problem was we were concerned that maybe too many people publishing at once, so we thought "Lets 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 colocated to this, and I'm going to, and most importantly I would add fairly autonomous. I'm going to explain what I mean by this. So this is it, MOO. This is our crew and tribe structure. It gives you a sense of how we're set up, and you can see that the crew is up to the customer journey from browse to buy to purchase, and then we have the team responsible for the platform, where you can put your business card and your flyer or so on, and we have one crew to deal with. Our business customers, they're called MBS, and their clients are AirBnB and other very big global tech companies, and we have a very famous sportswear brand, and a challenger bag amongst others, but obviously I'm not alone to say actually who they are. Use your imagination. So the company's strategy and bets floated these crews, and these crews use all hours to define their work and execute on their strategy. So first were going to take a closer look at the crew and I'm going to use Pixel here as an example.
[00:11:58] This is Pixel, and that's the very — this is Pixel TV where they broadcast who is on the team, what they're doing — and I think very interestingly, team health and happiness, I think if a team is doing good work, if they're working on what they believe in, if they feel they're executing well or even excellently, then that's likely what they're producing is going to be good.
[00:12:18] So I feel that the happiness of the crew can be used as a leading indicator of a quality product — and by the way that's the pic of the very loved Nabeel, it was a decoration from a party thrown from him. And 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 into to full stack designer doing UX, UI, and summative research.
[00:12:48] So I love this picture. This is from Ai Weiwei. 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 Schleifer: he wrote a really interesting blog post. He's the VP of Airbnb, 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, and you do have them balanced and to have them present from the start, otherwise the stool becomes wobbly. In other words you have tradeoffs and decisions that lead to a less than design, great product. But you know what's better than a stool? A four legged chair — and if you add wheels and you make it super fast you get a quad. And this is what we have at MOO, so we have quadsm which is product, design, tech and are supported by an agile coach to help them make great decisions and to support them in those difficult conversations.
[00:13:44] So there's not really any defined ways of working. Each crew maps this themselves — as you can see, this was the Pixel crew in action and they take all the things that they have to do all the different activities then they work out which which one and which person should be doing which kind of activity. But we do have some principles for how we see the quad working for each discipline has kind of pull factors, force fields, that attract certain types of work and responsibilities, and 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. And then, 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. And 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.
[00:14:41] So what does this look like? Product is concerned with building the right thing; they shape the future of the product and they iunspire the world with their product vision. EXDs — that's us — they help validate the needs and the value prop, and they're also concerned with the execution, which is 'build the thing right.' And you see, tech is concerned with building a great product, and creating sustainable, scalable products, and they're 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. And between us all, we delight customers; we build, run, and own, and iterate on great products; and team hugs.
[00:15:25] So we need design at every step of this process. So I just mentioned there 'build the right thing', and 'build the thing right', so I'm going to illustrate this with a classic double diamond. So 'build the right thing' is when you're trying to work out what you should be doing, and we use generative research to understand this, and build the thing right iss summative research: have we actually achieved this?
[00:15:47] But I propose there's more to this than the double diamond. We also need to think about actually shaping the problem space. We have to — before you start working on a product, you have to think why is it there? Why should it exist in the world? As Donald Rumsfeld said, "there's unknown unknowns", so we do contextual inquiry and anthropological — I can't say that — anthropological research to uncover unmet needs and to inforum strategy, and we're very lucky that our head of research at MOO is a trained anthropologist.
[00:16:19] And then after this, at the other end, we ship. The way our designs exist in the world is that they're shipped, and it's likely that we might build and release several versions which allows us to do MVT. But 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 be done next in what order, and everything we do should be about giving maximum value to the customer, or revenue for the minimum effort — don't say I'm lazy!
[00:17:03] So in other words we need to break the design apart into shippable increments that the crew can deploy. 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. So shipping 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 modeled 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 we need to operate in, we can move right across this, and this is an example of a cultural probe. These are one of the tools we can use to explore the problem space.
[00:17:48] So a cultural probe is like a diary study on steroids. You can send cameras, prompts to record things at a particular time. You have a diary you have all sorts of other ways where you can remotely take part in the participants life and understand what problems they might be facing that you could never get from a hundred interviews. At this stage you're observing with no expectation, either in person or using something like the cultural probe, and the aim is to uncover needs your customer has no one else is meeting and they themselves can't express or articulate.
[00:18:21] Another situation could be that there is a segment with specific needs you're simply not meeting and so you might consider some adjacent products, or changes to an existing product, but if you're a startup founder this is a way to go out and find a business. And once you find them you 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.
[00:18:48] So next we moved to 'build the right thing'. This is the point, as we work out what problem we're really solving, and it's really important to become comfortable with ambiguity, and to circle down into the right solution. So during this phase the designers were quite ahead of and largely independent to the crews, but still very closely with our 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.
[00:19:16] So 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, and it takes several attempts to get that right, but that's fine because it exposes differences of opinion, and most importantly 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 of the project, and those assumptions are the ones we deal with first. So before even thinking about the MVP we do a risk-use assumption tests.
[00:19:56] I love this quote, that was from Nabeel as well, so: "among competing hypotheses, the one with the fewest assumptions is 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 at MOO, every crew has a hypothesis backlog, and it's prioritized 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 this design process, and it's great. It captures things that people might have mentioned, 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. That's not the case. It's not development-driven, and it can record any form of opportunities, and a place to log this, and you prioritize and group it so you can investigate and then it allows us to input into the roadmap and OKRs. And it took us about six months to get this up and running it, but it's a way to let formulate why you're doing the design, what problem you're solving, and how will you know that you've solved it. I'm going to show you this in action with the MBS guys. So this is 'build the right thing' phase and practice, and this is how we circled in on what the MVP really is.
[00:21:07] So this is the MBS team in Providence. I mentioned earlier that MBS are our kind of B2B team with all these kind of unnamed big brands. This is a 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 they had it, they were going to be able to close sales with bigger businesses. So you can hear and see these right now: this is the team working out what the problem was with the sales guys in there, and the account guys. By the way — sales guys and account guys, are really excellent customer proxies! So if you can't get actual customers, go and talk to your sales guys.
[00:21:43] And I should probably pause at this point to explain what an approval flow is. So in many businesses the individual needing the print is not the same individual who's buying the print, and it's not the same individual who's 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. So here's the output from the workshop, and we also did some customer interviews to validate this, and we ended up what seemed to be a pretty well thought through solution.
[00:22:10] And at this point theoretically we could have just started building but it's actually really hard work to work out what your MVP is. In fact I've often heard tech teams say to marketing, when marketing basically knows that nothing ever gets iterated, and 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 what an MVP is — that's not when you sort of 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 a value into customers hands and as many customers as possible.
[00:22:49] So we reviewed our assumptions, and we realized 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's worked for the ones we've 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're 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 throw away. So here the design was like a prop for conversations. It was a provocation, and to be honest we really really hope that our initial solution would work with some flex, but it didn't. And you know that can be really disheartening at first, but I think this shows as a designer you need stamina. You need to be comfortable with your feel your ambiguity. So what we discovered is different companies are different. Even different departments are different. It's important to test your assumptions with real customers and potential customers as soon as possible. So you can see each one here is different. So we've got to put the flow between somebody ordering, somebody buying, somebody paying.
[00:24:05] 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 what our MVP was we still had loads of unanswered questions, and that's when we moved to build the thing right. So that email on the right is a strawman, and the e-mail on the left is what we have now. How would we get there. So if the e-mail act as an alerting system as a way to prove as well as a way to approve 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 this sort of detail. That's why things like the positioning of buttons, the language, the detailed interactions, and so on, and this is the point where it's really important to get a crew to take part in research. This is when we see research needs to be a team sport, because if the entire team observes the research together discusses the findings, agrees and on solutions, that we get these amazing conversations. So we've had conversations with the devs said "Oh I can fix that; that's one line of code" and we were like "we had no idea." It's absolutely brilliant!
[00:25:24] It means you can move really fast, and at speed, and it also means that you lose the crazy defense of documentation, and the devs know why they're building something, which is really motivating. So then reassess. So this is a post-it note exercise where we've all observed research, and then everyone agrees what they saw, and then we work out how we prioritize our research findings. So we have a slight set up like this with user value slash revenue on one side and technical difficulty on the other. So top left: we should do it; it's easy, important. Bottom: why should we even bother doing this? It's not really a problem and it's really difficult to execute. And this is what it looks like in action. And this is how we get shippable increments. So we decide what to build and then we work out what phases we should build in.
[00:26:14] 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 workout with product what's next to build. Don't give the day of a file with loads of annotations and expect them to work out what to build and what order. That's your job. As a designer you need to create small enough increments that the team can just pick up and run. So you're not feeding the beast, you're really clearly thought-out what should be happening when, because the tech team is continually deploying. You need to understand what's deployed when, and then you need to know what's changed so you can monitor the result.
[00:26:47] And this is also really superb way to approach MVT, because if you aren't certain which two solutions to ship, ship both and monitor, because you've isolated the changes you get a really clear picture of what's 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 too, 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 with 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 that they were searching? Actually, that didn't really work out, we saw on 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're just building up, and we're shipping like small increments, and each one is making the product gradually better, rather than starting that one on the left, because we wouldn't have known what had worked and why.
[00:28:01] So I'm going to ask you — by the way, I have a particular problem when I shop online, I don't know if you do — does this never happen to you?
[00:28:11] Or this?
[00:28:15] Or this?
[00:28:20] Or this?
[00:28:25] Our customers at MOO 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 was not expecting this." So there was 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, you know, 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're doing with the tech teams. If you're a designer you can also think what's the simplest thing you can do to solve the problem. So when you build, what I want you to now 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're in the face of building the thing right, the entire team should be looking at the research together.
[00:29:21] You don't need huge amounts of research documentation if everyone's 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, and 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.
[00:29:44] And 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. This could be a problem, so we also needed to make sure that we ensure consistency, and the way that we do this... So, this is based on our approach to Brad Frost'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 put organisms down you have a molecule, and then you break this tile apart you have the atoms. So we take these patterns, and they're in a master sketch file, which also includes guide lines, which is here. We also have a Craft library, this is Craft from InVision. Here is somebody using all our different templates and molecules to build a page... And 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.
[00:31:27] And 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 fail your personally. You have to have a emotional resilience. You need to see design just as not about great execution but to bringing 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 conflicts. You must, you know, you must know when to fight, and you need to be comfortable influencing strategy as well as executing on it. And it's really difficult! I describe hiring is like human Tetris; trying to find that right mix of people, personalities, and then gel them into a team. And the added complexity is that everyone sits in two teams: their design team, and their crew, and that's pretty much all I've been doing for the last six months and we're still looking for a researcher, if you're interested, and there is the MOO crew who are all here today. Yay! We also need an amazing VP of products which is actually the second secret reason why I'm here today — MOO is hiring for a VP of product, 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!
Jane is an award-winning designer and has spoken and given keynotes at conferences all over the world (she once flew to Chile for the weekend to do a talk – ask her about the earthquake...) She currently works as Director of Product Design at Babylon Health.
She was previously Director of Design and UX at MOO, the online print business that is passionate about great design and the difference it can make to its customers and the world.
Jane loves building high performing design teams and leading digital transformations. Prior to MOO she grew the team at The Telegraph from one to twenty, and led the redesign of the website and several apps, worked at the Government Digital Service (home of GOV.UK), in an online trading firm, in startups and in agencies.