About this talk
In this talk Sam shares how teams are structured at Made by Many. He’ll talk about the journey teams go through together—from the unknown to the Emerald City—and how you can ensure you’re better equipped to make critical product decisions
- My name is Sam Small and I'm a designer here at Made By Many, which made it incredibly easy to get this gig speaking to you tonight. For those of you who don't know Made By Many, as well as being the host to Front-End London we also help clients transform their business by creating new digital products. And so I'm gonna talk about the teams and the journey they go on to creating those products and why we believe the teams that join in together make better products. But first since I'm first on I'd like to do a bit of a warm-up exercise, Hannah's already got you to raise your hand, I'm gonna ask you to do more of that awkward audience participation. So everyone in the room can you raise your hand if you're a developer or an engineer or you write code. That makes sense considering it's Front-End London. Okay so keep your hand raised if in your current project you were involved in the very first meeting about that project. So that's the pitch or the kick off meeting, things like that. Okay, great. And keep your raised if in your current project you were involved in the use of research. So stakeholder interviews, user interviews, things like that. Okay great, thank you. So I wanna start with a story. Day breaks, the sun peers from above the horizon, a soft breeze carries grains over an endless sea of dunes. A golden glow fills the inside of a car. The three passengers begin to stir. A product manager's stop was first, opening her eyes to an unfamiliar setting. She stumbles out of the car, her legs still sleeping, she spins in circles desperately thinking a sign from which to get her bearings, anything that might tell her where she and her team are and how they got there. Nothing, for miles and miles, there's nothing. And this is what it feels like to embark upon a new project. You don't know where you are, what direction you need to head, or even where you should end up. Back to our story. Designer and developer emerge from the baking car in search of answers. They too find no clues as to their position. "We're doomed," the designer cries in despair. "Do not fear," the developer reassures, we have the car. For the team there's hope, the car can offer salvation, the car can help them travel, cross the vast unknown. But no one person in the team is able to continue the journey on their own. The car wouldn't drive itself, decisions need to be made, a direction chosen, and problems fixed along the way. They need to rely on their individual talents, the strategic mind of the product manager, the creative imagination of the designer, and the pragmatic mentality of the developer. The car is our process, and our process is a vehicle that we rely on to help us journey from barren lands to an oasis. And just as our lost travellers must combine their skills to drive the car to the destination, in our work we too must utilise the individual talents and unique insight that each team member brings to the project. And so a team of three travel together. Each playing their crucial role to ensure they end up in the right destination. And this idea of the whole team, designer, developer, and product manager travelling together on a shared journey is how we work at Made By Many. We believe working in this way leads to better products. We believe that teams that join in together make better products. And we have a process or rather a set of processes that help us get from A to B, from nothing to success, from not knowing to insights, from an idea to a prototype, to a sketch and beyond. We see it as a journey, and on that journey we utilise the unique talents of each team member every step along the way. A product manager, designer, and developer are all involved in the kick off meeting, the sketch workshops, the stakeholder interviews, the user interviews, the synthesis of the research, the list goes on. And this can seem quite wasteful. Why would you have everyone on the team doing exactly the same thing? Surely developers can be getting on writing code while the rest of the guys do all of that research stuff. Well it's true, lots of code could be written, but we believe having everyone on that shared journey is important for two reasons. Inputs and insights. Think inputs, this is about what each team member brings to the process. Each team member has their own history of unique insights and unique experience and they can argue from a different world view. Just because you're not a developer doesn't mean you don't have valuable ideas to put forward in a sketching workshop. We value the input of each team member throughout the entire process. And the insights, well this is about what each team member learns on the journey in regards to the product they're building. It's the insights that help them make decisions about a product. It's that first time experience of being in the room when the client confessed their failed attempts to ship something or maybe hearing the user's delight when you show them a sketch that, that it can solve all of their problems. And why do we care, why do we care about what the team members bring to the process and why do we care about what they individually learn through that process? Well with the inputs this is important because it creates that vital all important clash of mind. It ensures we have all bases covered. The technical, the dreaming, the rational, the practical are all different states of mind. And a single team member may wish to juggle these states of mind throughout the process, but it's impossible for any one person to be all of those things at the same time. Designers known for dreaming all too often, developers accused of being too rational, we need both for the ideas to become a reality. To ensure we don't dream ourselves into the unrealistic or restrict ourselves to the known these minds in different states challenging each other, sometimes arguing, sometimes playing is only made possible by having everyone on a shared journey. And with the insights why is it important that people learn stuff along that process? Why is it important that they hear what the users have to say? Why can't they just read the writer of the research? Well to answer this it might help to explain made by many stance on user experience designers. We don't have user experience designers at Made By Many and this could be viewed as a purely semantic issue, but what it does really is it reinforces our belief that user experience should never be a single team member's domain. We believe that everyone on the team is responsible for user experience. Whether a user realises it or not every page load, every image, every colour, every word effects the experience. And as we begin to build our products each team member begins to make decisions about these elements. And since each decision effects the experience each team member needs to be equally qualified to make those decisions. So we ask what's the best way to be qualified to make crucial product decisions. Well we believe that it's empathy. If you have empathy for those you are designing for, and that's both the user and the client, then you're able to make better more informed decisions about the product you're building. At Made By Many we believe there's no shortcut to reviving an empathy, you need to have lived the research, you need to be in the room when the user vented their frustration or when the client told you that if this product doesn't get results they're likely to lose their job. The empathy gains from having gone through these processes, the user research, the stakeholder interviews is far greater than you can get from reading documentation from research reports. Therefore we could probably say that experience in the research firsthand is the best way to help us make better more informed decisions about the product we're building. And so a product manager, designer, and developer go on a shared journey. We've covered some of the reasons why this is good, it's about what each team member brings to the process and what they individually learn through the process. And as I've said we believe that working in this way leads to better products. Teams that journey together make better products. But not everyone works this way and not every company structure and process provides the opportunity to do so. And it probably helps to understand some of the way Made By Many works to see whether it could work for you as well. At Made By Many we're in the business of client services, this often means we're starting from scratch knowing nothing, figuring out as much as we can about the client and their users before knowing what we need to build. And there are two factors that make this shared journey possible at Made By Many. That's the type of projects we work on and the size of the teams. With the projects we work on we're often seeking opportunities to build a new product rather than making improvements to existing ones. Practically speaking this means that there is a whole load of research that needs to happen first before we know what we need to build. Another agency might delay the involvement of the developer until after the research has been done. As I've already said we value the input from developers from day one on the project. The second factor is the size of the teams. In the office at the moment I think the biggest team is about six people and even then they're working on two separate tracks of work for that client. More often than not it's just three people, a designer, developer, and product manager. We believe this has just enough diversity in the team and by that I mean different ways of thinking whilst keeping waste to a minimum. For people working in house on an existing product chances are there's a never ending back log of things to be done, code to be written, bugs to be fixed, features to be tested, which can give you more than enough reason for not working in this way. But even at Made By Many there have been times when we haven't been able to afford the luxury of having every single person on that shared journey the entire way. Not too long ago I embarked on a project where from day one we were up against it, we had a lot of work lingering on from previous phase. So I cracked on with the research while the developer Ali continued drawing code, working on features from the previous phase. Two weeks into the project and I finally got to sit down with Ali to discuss the design direction, I needed his help to understand the technical feasibility of the approach. I had a wealth of research and I shared it with him, and when we began to discuss the design direction I could sense that I was able to draw from memory, form the research, empathising with the user, putting myself in their shoes. And as we talked I found that Ali kept making assumptions and I guess he had only read notes from my research and he was probably feeling a little in the dark. But he kept arguing for things that just didn't align to what I had heard from the users. It made that conversation quite arduous and time consuming in a way that I hadn't experienced before. And it really highlighted to me that there's nothing quite like hearing it from the horse's mouth, and it was doubly hard in the case of that project to create a shared vision between myself and Ali. We made it clear that when the team don't journey together the ones who do the research need to work much harder to create that shared understanding amongst the team. So there are always excuses we can make for not getting involved in those project processes that are not typically your domain. Perhaps the user interview is in Helsinki and you can't be there. Perhaps you need to work from home on that day. Or even in those times it's still possible to include everyone on the shared journey. In a recent project I set up a round of user interviews and when I realised that one of the team members couldn't be there I just invited them to join in on Skype. It was a really simple solution using the tools that we have every day causing, well enabling them to join in with the research, causing a lot less disruption to their day. Of course it's a less than ideal scenario, but from that previous project I'd learned that not hearing what the users have to say and the tone of their voice is well, you know, it's much more powerful to hear them say that than have a designer quote it to you from a Post It note. So there are always excuses for not having enough time, but it's just the case of how much we value the involvement of all the team members and some extra effort required to make it a priority. So as well as the issue of time there's also the issue of duty. There's duty to make the right product and the best product possible. Duty to delight users and get results for our client. And rest assured the client is gonna be feeling like they need some control over how they're gonna get those results. At least that's what they're thinking when they send those change requests. It comes from a place of worry, urgency, and uncertainty. What we see is an email like this. This is one of those typical requests you might be familiar with. Some people in the back can't, I'll just quickly read you it. Just got off the phone with Roger, he said we should definitely add share buttons to that page, we want customers to share as much as possible. So maybe you're at the end of your project and then this comes up and you just don't know where it's come from at all. And it's a seemingly harmless request, add some social sharing buttons to a webpage, but if you weren't involved in the research then it throws up loads of questions that are really hard to answer. Such as who the fuck is Roger? Is he a stakeholder? What is, is his opinion important in this project? Do we even know if share buttons even work? Has anyone looked into that? Why would users even want to share this? Had people tested that? Do we need to do more testing? Again, it's a really harmless, seemingly harmless request, but within it is a lot of wasted effort based on a few assumptions by the client. And these requests that come in like this, and there could be many on your project, is a potential threat to the success of what you're building. Everything like this that doesn't come as an add part of your process has a potential to dilute the hard work that the team has done. So how do we combat requests like this? Well firstly we need to understand where it's coming from. What did the business said I have to achieve in this project? What were the original aims and does this request speak to that? Well the obviously way to know that is through being involved in those really early stage meetings where some of this stuff would have been defined. Well what have we learned from users? Did we learn they would not use a feature like that? Is more testing required? Without all of this knowledge we're powerless. If you weren't involved in the research then how are you to know that adding something like social share buttons is the right thing to do? Without the research we're unarmed, we're powerless. And saying no to the client can feel like just an opinion, you have nothing to back it up. And so we ended up backed into a corner blindly following orders. And every new request that comes in like this has a potential to undermine the hard work that the team has done and weaken the user experience. If we experience the research first hand then we can be armed with the necessary understanding for combating client requests like this. We might be able to say with confidence that we saw no evidence that users want to share that content, for example. So if we experience the research firsthand we're better equipped to deal with these requests, we can make better decisions, and more successful products. So maybe you already worked this way and you've accepted it as norm but haven't thought about why taking everyone on a shared journey is so important. Or perhaps this way of working will be new to you and you've been dying to get involved in those early stage processes, the research and the kick off meetings, but haven't thought about how you could do that. Perhaps you've been struggling to get a shared vision amongst the team, wondering how you can get everyone to stop making assumptions. Or maybe it's just dealing with those classic client requests, figuring how it's best to combat those. Whatever it is I believe that the best way to solve all of those things is to have everyone on the entire team start together, stranded in the middle of nowhere before they chart a course toward their destination and journey together as one. Thank you.