Ideation And Prototyping: Think Bigger, Fail Quicker

Jackie Scherer at UXDX Europe. Video: https://youtu.be/oyPZiaCxkPA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why ideation and prototyping belong to the whole team

[00:00:00] Thank you so much for having me. My name is Jackie Scherer, and 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 they both fit into the agile design and development process.

[00:00:23] 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 really is about how, in the spirit of this conference, together we build more innovative products. I am really passionate about this topic of how we build the right thing in product design and development.

[00:00:58] My interpretation of the spirit of this conference, and why I'm really excited to be here, is that 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.

[00:01:18] I'm so passionate about this topic that I came all the way from San Francisco, California. At Ripple, as mentioned, I'm working on starting an entirely new product design function. Formerly our product was just a back-end product of APIs that integrate with financial institutions' software, and now we're creating a user interface to visualize a whole network of financial institutions. It's an entirely novel product, so the topic of how we innovate and how we also reduce risk is really pertinent to what we do every day.

[00:02:06] My background: I've gotten the 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 they get a lot of hype, but it's not just buzzwords. I have seen how these technologies can really impact people's working life and improve their lives, and obviously they're affecting our working lives and personal lives every day. These are just a few of the companies that I've worked for, and currently at Ripple I'm working on blockchain technology and other innovative technology.

[00:02:51] 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's me. I also get a chance to work with brand designers in the marketing department. We have one centralized design team at the size of 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, so we took this picture. It's just been a great opportunity to start a new function, a product design function, in this company.

[00:03:56] In the spirit of this talk: you can't really see this slide, I had to export it into PDF, but this says "designers only." It's okay that you can't see what the sign says, because prototyping and ideation is for the whole team, and that's the spirit of what we're doing here: shared learning and understanding.

Building before code in agile planning

[00:04:11] Again, the 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 up front in our agile product development, and how we build and experiment cheaply before any code is written. We do a lot of planning activities in 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.

[00:04:50] The principle, which I very much believe and have been a big advocate for for quite some time, and the way that design fits into it, is that we start with something that's really fuzzy and we defer decision-making until it becomes higher in our priority list, and then we start getting down to 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 building and working together to ideate and prototype throughout the entire process.

[00:05:34] When we think about these three parts, or phases you might say, 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 we make this useful. 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?

[00:06:15] Sometimes you might think of these different functions as responsibilities of one team or one person. Maybe the product manager is in charge of deciding how to build a useful thing, then the designer designs it, and then the engineers implement it. But if we start thinking about every phase as the whole team's responsibility, it really changes things. We start to really talk amongst each other to understand whether we are 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.

Build a useful thing: upfront ideation

[00:07:08] Starting with "build a useful thing," the suggestion here is to add upfront ideation and prototyping to your planning processes. Start experimenting and building early in the requirements space. Hopefully in the requirements 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 along those lines. The more you know about your user the better, 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.

[00:07:49] Then in agile we jump right to define, prioritize, estimate, and 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: make sure we're spending an equal amount of time deciding what it is that is going to deliver value, and how we can validate that this thing that we're building is in fact viable.

[00:08:19] Instead of a detailed requirements document up front, that frankly a lot of people may not fully read or comprehend, part of your requirements might be starting to do some rough prototyping, starting to do some building before you even get into the scoped design. You can start with loose requirements, say 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.

[00:08:54] There are some group activities that are part of this process: ideating. In terms of innovating, we 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. There are many group activities that we can do in a group, not just looking at a requirements doc, but rather let's sketch together. At 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. Sometimes when I come into 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.

[00:09:56] One of the activities that was 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: 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 write on Post-it notes as many ideas as you can come up with. It's amazing, once you start going for speed, how your mind stretches, and you start to think about what a user might actually want to do. You start really putting yourself in the shoes of the user, which I think is a really important part.

Ten tips for group ideation sessions

[00:10:46] I don't have time to get into all of these tips, but here are ten tips for your group ideation sessions, which are 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; hopefully maybe you have a dedicated research person. Push back and 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.

[00:11:34] Be audacious in asking for engineers' 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, and how do we get "ready ready" for the next scheduled sprint? It's difficult. But I think there's actually risk in not spending the time to make sure we're ready ready: are we building something viable?

[00:12:05] 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 Ripple at our company, so we might pull in somebody from the finance department into these ideation sessions. That's very valuable.

[00:12:30] Then I like to encourage people in the ideation discussions to sketch what's top of mind. It really helps me understand what each individual cares about and where maybe the differences of opinion are, so I can help us either debate different ideas and what we each think is important, and then align on the vision. As I mentioned, for "how might we" questions, you can plant the sessions with "how might we solve this problem."

[00:13:02] This is a really important one to me, which is enable space for independent thought, to avoid groupthink. What happens in group dynamics is you might 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. That's why Post-it notes are really valuable. If you encourage people to spend time ideating their ideas on Post-it notes, you allow for that independent thought, and 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.

[00:13:56] Obviously we work with remote teams, I do, 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 try facilitating and not participating, and see what happens. When you're not thinking about how you might solve a problem, you can get really valuable information by really listening to the team.

Rough prototypes in the requirements phase

[00:14:40] Also in the requirements phase, we can start to make quick, rough prototypes, and I think 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: creating alignment on vision quickly, improving understanding of user workflow, mitigating risk, and then better estimating time. This will improve your estimation process significantly. Maybe you spend less time debating estimation, and rather you know exactly what the estimate is going to be.

[00:15:30] If 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 InVision or a Keynote presentation. You can do a paper prototype, go to work with paper and scissors, or you can code up a quick content wireframe to understand, say, responsive behavior.

Design it well: prototyping features

[00:15:54] Imagine at this point we're talking about getting into the agile process, where you want to start designing something that is a scoped design. At this phase, obviously, there's a lot we can do with prototyping features and designing the interaction, or starting modeling the interaction that we're going to design. Does this look familiar to anyone, where we might wireframe or mock up something, and then we finalize and polish it, and then we hand it over to the developers?

[00:16:37] Mock-ups only vaguely resemble a real interactive product. The reason it's called a mock-up is that in graphic design, graphic designers took an X-Acto knife and actually mocked up a design, and then we moved to Photoshop because it was more accurate to what the real end result was going to be. Now, what's the analogy for products that we use every day? A mock-up really doesn't simulate what the product is going to look like.

[00:17:15] 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. It's something live, you're experimenting with something, and it naturally lends itself to testing with your team and with real users.

[00:17:50] At the phase where you've 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. We think of innovation as all in the upfront ideation process, but there's a lot of innovation that can happen in the details, and you end up working through design problems more thoroughly when you do this prototyping process. That's one of the big advantages of prototyping: working through the problems, and you'll discover problems as you go along.

Tips for feature prototypes

[00:18:43] 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 use whatever tools you find work for you, but at the same time make sure that it's still collaborative in nature 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.

[00:19:31] Also in that nature, socialize 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 unveil, but get feedback even in the early stages when it's not complete yet. Joint working sessions are really great for talking about what's working and what's not and testing what you're working on.

[00:20:01] You can use this prototype as part of your engineering spec. If a picture speaks a thousand words, a prototype can speak many more. You can also experiment with new, risky design interactions that really stretch the team, and you can get feedback from actual users. You can encourage the 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 empathize with each other, the better our products will be.

[00:20:34] 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 paying off. My suspicion is once you get started and actually start doing it, you will find that there is a payoff there.

Implement it right: walkthroughs at the feature level

[00:20:58] Last step. At this point we're trying to execute efficiently at implementing the product. 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 built was in fact useful and viable. Better to catch mistakes, or catch something that isn't hitting the mark, before it goes out to users than after.

[00:21:38] My suggestion here is implementation planning and walkthroughs on a feature level. What happens a lot of times is, when you're thinking 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. We need to make sure that features, I should really say experiences, are implemented in such a way that we're providing value in use in the real world. We want to plan design implementation across multiple user stories, or even multiple epics, that make up an experience. Then we want to walk through the feature before it goes out into the world, from a user's perspective. These are sometimes called cognitive walkthroughs. Let's just make sure that what we build is going to provide the value that we set out to provide.

Two case studies

[00:22:41] 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 was the combination of two products, so this was a very risky thing that we needed to do a lot of testing for. Firstly, we hosted a "how might we" ideation session and conducted a loose prioritization exercise, to make sure that we were spending the time on the things that were the most important, because it was a huge project. From there we started to get some testing done early, with just some sketches, with some end users, about whether this new product was going to meet their needs.

[00:23:35] Then we worked through these sketches more. This was just pen and paper, with designers and developers, to really validate the design and to work through the solution and the problem that we were solving. From there we did more formal usability testing. We took two wireframe prototypes with slightly different workflows and tested them with users to see what their response would be, and we did that with InVision.

[00:24:15] Unfortunately I don't have the interactive version here, but in order to test the interaction design we tested a rough content wireframe, 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 and higher fidelity. We didn't in fact do high-fidelity prototyping here, but we very well could have, and I think I would have, going back.

[00:24:55] Secondly is the product that I'm working on currently, which was an information architecture reorganization and also an aesthetic transformation. We started with affinity mapping and used Miro, which is an online tool for collaborative ideation. Then we did usability testing with Treejack, which is just looking at information architecture, went to low-fidelity wireframes, and then did a high-fidelity prototype in InVision. Because this was a broader project, we did a pretty wide horizontal prototype. When you're working on projects that are much more granular, as many are, you can prototype individual pieces and then glue it all together and see how it goes.

[00:25:57] From this we had lots of shared learning to draw from, and that's really the goal here: it's shared learning with your team. You can all experiment together, build together and learn. And that's my presentation.