Ideation And Prototyping: Think Bigger, Fail Quicker

Ideation and Prototyping Think Bigger Fail Quicker
Speaker: Jackie Scherer

Thank you so much for having me. My name is Jackie Scherer, thank you for the great introduction. I'm super happy to be here. Today we're talking about ideation and prototyping and both of these topics are very meaty topics and I only have 30 minutes but I'm very passionate about how both fit into the agile design and development process. So this talk isn't about how to build prototypes in terms of the tools that you use. My suggestion for prototyping and ideating is just to start doing it, start experimenting with tools, start learning. But this was really about, in the spirit of this conference, how together do we build more innovative products? I am passionate about the topic of how do we build the right thing in product design and development. So my interpretation of the spirit of this conference and why I'm really excited to be here is we all have shared goals here.
We all are looking to do the same thing. We all want to build better products. So we need to increase our shared understanding of what it is that we're building together so that we can have shared success along the journey. I'm so passionate about this topic that I came all the way from San Francisco, California at Ripple and as mentioned, I'm working on actually starting an entirely new product design function at Ripple. Formerly our product was just a backend product of APIs that integrate with financial institutions’ software and now we are actually creating a user interface to visualise a whole network of financial institutions and it's an entirely novel product actually. So the topic of how do we innovate and how do we also reduce risk is really pertinent to what we do every day.
In my background, I've gotten a chance to design for a very broad array of different types of products and touch a lot of cutting-edge technology. We hear a lot of these types of technology and get a lot of hype but it's not just buzzwords. I actually have seen how these technologies can really impact people's working lives and improve their lives and obviously, they're affecting our working lives and personal lives every day. So these are just a few of the companies that I've worked for and currently at Ripple, working on blockchain technology and other innovative technology. So, these are some members of my scrum team at Ripple, a cross-functional group of folks, engineers, me as a designer and a product manager. And there is me.
I also get a chance to work with brand designers in the marketing department. We have one centralised design team [because of] the size of a startup that we're at. This was a photo taken on International Women's Day with some of my other women designers and it was a bit ironic because for whatever reason on International Women's Day all the men happened to be coincidentally out of the office and so we took this picture. But it's just been a great opportunity to start a new function, a product design in this company. And I think the spirit of this talk, you can't really see this slide. I had to export it into PDF but this says ‘designers only’. And it's okay that you can't see what the sign says because prototyping and ideation are for the whole team.
And that's the spirit of what we're doing here is shared learning and understanding. So again, question, how do we design and build innovative products while reducing risk? I think the key for this is really the types of planning that we do upfront in our agile product development and how do we build and experiment cheaply before any code is written? So we do a lot of planning activities and agile and a lot of these involve lists. We look at a lot of lists and we look at a lot of words. We look at requirements, documents and the principle. Something which I very much believe in: I've been a big agile advocate for quite some time and the way that design fits into it. So we start with something that's really fuzzy and we defer decision making until it becomes higher on our priority list. And then we start getting down into the details.
But I'd like to encourage us in the initial requirements phase and throughout to add experimentation and increase shared learning throughout the process. So we're not just sitting, looking at lists and looking at words but we're actually building and working together to ideate and prototype throughout the entire process. When we think about these three parts or phases of how we design and develop a product at a very basic level. We are trying to build a useful thing: that's the requirements phase. We're trying to figure out how to make it useful. I actually wouldn't say it's just the requirements phase: throughout the process. We're still working on how do we make this thing useful? So the assumption is we're all trying to make something that people are going to want to use. Then how do we design it well and then how do we implement it right such that we're actually achieving our goals?
Sometimes you might think of these different functions as responsibilities of one team or one person. So maybe the product manager is in charge of deciding how to build a useful thing and then the designer designs it and then the engineers implement it. But if we start thinking about this as the whole team's responsibility, every phase is the whole team's responsibility, it really changes things. We start to talk amongst each other to understand: are we actually building something that users are going to want to use? As engineers, I really encourage you to challenge your designers to make sure that you agree that what we're building is useful and if you don't know or don't understand something, ask and advocate for research.
Starting with building a useful thing. The suggestion here is to add upfront ideation and prototyping to your planning processes: start experimenting and building early in the requirement phase. So hopefully in the requirement phase, there's some sort of research and empathy going on from your team, whether it's talking to customers on the phone, or something on those lines, but the more that, obviously you know about your user, but the whole team needs to know about what it is that you're building and who it is that you're building for. So the more that you can gain shared understanding in that phase, the better.
And then in agile we jump right to define, prioritse, estimate. We start to really get into the efficiency of how we're going to build this. What I'm advocating for is to spend at least as much time talking about the what, not just how we're going to deliver this but make sure we're spending an equal amount of time deciding what it is that is going to deliver value and how we can actually validate that this thing that we're building is in fact viable? So instead of detailed requirements document upfront, which frankly a lot of people may not fully read or comprehend, part of your requirements might be actually starting to do some rough prototyping, starting to do some building before you even get into the scope of design.
So you can start with loose requirements, we call it a one-pager. And at that point, you're off to the races. You can start building and prototyping an idea, even if it's not fully defined yet. So there are some group activities: part of this process is ideating. We also, in terms of innovating, want to make sure that we're stretching ourselves. We want to be constantly pushing the envelope for what it is that we're building. So there are many group activities that we can do in a group, not just looking at requirements documents but rather let's sketch together. In my company currently, we're working on products for the financial industry. So there's a level of seriousness to what we do and there's a level of intensity to it. So sometimes it feels like when I come to a room with some Sharpie pens and post-it notes, people are like, ‘What are you doing?’ But it's really important to bring, play to this whole experimentation and building process.
So, one of the activities that are on that slide previously is called ‘How might we? Ideation. The idea here is that you seed a session with a series of ‘how might we?’ questions and the idea is how might we solve a problem? It's good to be as thoughtful as possible in what those ‘how might we?’ questions are and then you just, on post-it notes, write as many ideas that you can come up with. It's kind of amazing once you start going for speed, how your mind kind of stretches and you start to think about what users might actually want to do and you start really putting yourself in the shoes of the user, which I think is a really important part. So, I don't have time to get into all of these tips but here are 10 tips for your group ideation sessions, which is a very important part, I believe, of the requirements process.
Firstly, as I mentioned, know your user, if you don't know your user and you have questions, ask the questions as engineers, ask the questions: who are we designing for exactly what is it that they want to do? If you're struggling with some of those questions then advocate, we need to get more research, encourage your designers to research. Maybe you have a dedicated research person, push back, say we really need to have a better understanding of what it is that we're doing here making sure that this is actually useful. Be audacious in asking for engineer’s time, if you're a designer or product manager. I know it's tough because we're spending time getting to ‘done done’ in our agile sprints. How do we get ready? The next agile sprint, it's kind of difficult, right? I think there's actually a risk there in not spending the time to make sure we're ready. Are we building something viable?
There might be subject matter experts inside your company that you can tap for information. For example, we work in the financial industry and we in fact have a finance department that works for a Ripple at our company. So we might pull in somebody from the finance department in these ideation sessions that's very valuable. And then I like to encourage people in these ideation sessions to sketch what's top of mind. It really helps me understand what each individual cares about and kind of where the differences of opinion are. So it can kind of help us either debate different ideas and what we each think is important and then align on the vision. As I mentioned, the ‘how might we?’ questions, you can seed the sessions with: ‘how might we solve this problem?’
This is a really important one to me, which is to enable space for independent thought to avoid groupthink. What happens in group dynamics, as you may have some very vocal people in the room that might steer the conversation in a particular way. Obviously in innovation, minority opinion is really important. What happens with groupthink is we end up with something that's pretty safe sometimes. So make sure that the outlier opinion is brought into the room. So, that's why post-it notes are really valuable. If you encourage people to spend time ideating their ideas of post-it notes. Then you basically allow for that independent thought then you let them present afterwards. It gives an equal amount of time for each person to present their ideas after they jot them down.
Obviously, we work with remote teams. So there are online tools out there for ideation. MURAL is a great one. So take a look at what kinds of tools you can use for ideating with your remote teams. Go for speed and quantity, not necessarily looking at the details and try to steer away from talking about feasibility until the end of your ideation sessions. One thing you can try as a designer or a product manager is to try facilitating and not participating and see what happens. You can actually when you're not thinking about how you might solve a problem, you can get really valuable information by really listening to the team.
Also in the requirements phase, we can start to make quick rough prototypes. I think that actually doing that together is a really valuable exercise because you're challenging this problem space with each other and learning about this potential product together. There are a lot of reasons we might prototype roughly at the beginning but creating alignment on vision quickly improves understanding of user workflow, mitigating risk and then better estimating time. This will improve your estimation process significantly. So maybe you spend less time debating estimation and rather you know exactly what the estimate is going to be. At this stage, you really want to aim for speed and fluidity. You can start getting a prototype going just by scanning some sketches and throwing them into like InVision or a Keynote presentation. You can do a paper prototype, go to work with paper and scissors and or you can code up a quick content wireframe to understand for example responsive behaviour. So imagine at this point we're talking about actually getting into the agile process where you want to start designing something that is a scoped design.
So at this phase obviously there's a lot we can do with prototyping features and modelling the interaction that we're going to design. So does this look familiar to anyone where we might frame or mock-up something and then we finalise and polish it. Then we hand it over to the developers. Mockups only vaguely resemble a real interactive product. The reason it is called mockups is in graphic design. Graphic designers took an exacto knife and mocked up a design. Then we moved to Photoshop because it was more accurate of what the real result was going to be. Now, what's the analogy for products that we use every day? A mockup doesn't simulate what the product is going to look like.
So my suggestion here is to plan out how you're going to design the thing that you're going to design. What is it that you need to learn? How is this thing that you're working on going to simulate product usage? And prototype and test as much as you can, if you build a prototype, naturally you end up wanting to test it, right? It's something live, you're experimenting with something and it naturally lends itself to testing with your team and with real users. Once you've actually scoped your design and you have a more concrete idea of what it is that you're building. I do advocate for high-fidelity prototyping. There are several benefits to this. Again, it really simulates product usage. But take small chunks, prototype something at high fidelity, maybe something smaller so that you can really get into the details with it. There's a lot of actual innovation. We think of innovation as all at the kind of upfront ideation process but there's a lot of innovation that can happen at the details. And you actually end up working through design problems more thoroughly when you do this prototyping process.
So that's one of the big advantages of prototyping is actually working through the problems and you'll discover problems as you go along. So here are tips for your feature prototypes. Start with what it is that you want to test and make sure that you're getting your biggest return on investment. That means spending the most time in the places where there are the most unknowns, where you really need data and information. My suggestion is to use whatever tools that you find that work for you but at the same time make sure that it's still collaborative and adaptive in nature. So you're not going off into the woods and then coming back and unveiling: that's not the idea here, right?
In that nature socialises early and as often as possible, even if it's not complete yet. There might be a tendency to want to have a very complete prototype that you can kind of unveil but get feedback even in the early stages when it's not complete yet. Joint working sessions are great for talking about what's working and what's not and testing what you're working on. You can use this prototype as part of your engineering specifications, if a picture speaks a thousand words, a prototype can speak many more. And then you can also experiment with new risky design interactions that really stretch the team. You can get feedback from actual users and you can encourage your developers that you work with or if you're a developer, prototype in code. And if you're a designer, maybe learn to prototype in code, I think the more that we can empathise with each other, the better our products will be.
And then at the end of a sprint or at the end of maybe a release, do a retro and figure out what prototype tools worked and what didn't and whether you're in fact getting the return on investment. Whether the amount of investment in prototyping is actually paying off and my suspicion is once you get started and actually start doing it, you will find that there is a payoff there. The last step, at this point we're trying to execute officially in implementing the product. So my suggestion here, again we are trying to validate throughout the process that what we're building is useful and viable.
So we need to make sure that what we actually built was useful and viable. Better to catch mistakes or catch something that isn't hitting the mark before it actually goes out to users than after. So my suggestion here is implementation planning and walkthrough at a feature level. So what happens often is when you're seeing through the lens of user stories, you get a lot of user stories that you're working on and you lose sight of the big picture. So we need to make sure that features, I should really say, experiences, are implemented in such a way that we're actually providing value and use in the real world.
So we want to plan design implementation across multiple user stories or even maybe multiple epics that make up an experience and then we want to walk through the feature before it goes out into the world from a user's perspective. So, these are sometimes called cognitive walkthroughs but let's just make sure that what we built is actually going to provide the value that we set out to provide. So I have a few case studies. These are former products that I've worked on. The first is a product that was a major architectural change and actually was the combination of two products. So this is a very risky thing that we needed to do a lot of testing for.
So firstly, we hosted a how might we ideation session and conducted a loose prioritisation exercise to make sure that we were spending the time on the things that were the most important because it was a huge project and from there we started to get some testing done early with just some sketches with some end-users about whether this was actually going to meet their needs, this new product. Then we worked through these sketches more and this was just pen and paper with designers and developers to really validate the design and to really just work through the solution and the problem that we are solving. From there, we did more formal usability testing. We took two wireframe prototypes and they were slightly different workflows and tested them with users to see what their response would be. And we did that with InVision.
Then unfortunately I don't have the interactive version here but in order to just test the interaction design, we tested a rough content wireframe and just to test these panel interactions that we were working on because it was quite a complex arrangement of panels. Then we tested the interactive prototype at a feature level with higher fidelity. We didn't do high fidelity prototyping here but we very well could have.
Secondly is the product that I'm working on currently, which is information architecture reorganisation and also an aesthetic transformation. So we started with affinity mapping and use a Miro, which is an online tool for collaborative ideation. Then we did usability testing with Treejack, which is just looking at information architecture, and went to low fidelity wireframes. And then did a high fidelity prototype in InVision and because this was a broader project we did do a pretty wide horizontal prototype. When you're working on projects that are much more granular as many are, then you can prototype individual pieces and then glue it all together and see how it goes. So we had from this lots of shared learning to draw from and that's really the goal here is shared learning with your team. You can all experiment together, build and learn.
And that's my presentation.