Design And Prototyping

David Hoang at UXDX Europe. Video: https://youtu.be/Y9TOkMWKu7U

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.

Introduction and what we'll cover

[00:00:06] Okay, can everyone hear me? Okay, all right, great. Thank you so much. My name is David. Before we start, they say know your users, so I'd like to know the audience a bit. How many UX designers do we have? Okay, great. Product managers? Engineers? Okay, awesome. This is such a unique conference, I've never been in a place where you bring them all together, so I'm really excited to be here. Thank you to the UXDX panel for having me.

[00:00:41] So my talk is called Prototyping to the North Star. The goal of this is to be kind of a bridge between the execution track and the vision track, so it's a combination of how do you fill those gaps between, how do you think about going through the execution and make sure you're still aligned with the strategy.

[00:01:05] I like to be upfront and go over what we'll cover. So first of all, why prototyping. How many of you work at a company that does prototyping frequently? Okay, that's great, so about half and half. We're going to talk about nurturing the prototype culture, what does that mean to build that sort of capability and that habit. The many faces of different prototyping tools: we are in the golden age of design tools, design systems and heaps of things you can use, so it's a really exciting time, but it causes a lot of thrash as well. And then finally I'm going to end with the framework I like to use called now, next and future. It's how you set expectations of the roadmap moving forward.

[00:01:50] So a little bit about me. I've been doing design for more than a decade, have had the privilege of working in a lot of different industries. I'm currently the head of product design at a health tech company in San Francisco called One Medical. I'll share a little bit more about that later. Previously I was director of design[?] at a company called Black Pixel, where I led a prototyping team, so we did a lot of product discovery and need finding for clients varying from Fortune 500 companies to smaller startups.

[00:02:29] I was really pleased to hear there are so many people who have an arts background, because I did too. So my background is in drawing and painting, and if there's one thing I really learned from my experience in studying art, it was learning how to learn, and learning how to subvert tools and find a different purpose for them. I love science fiction, it's a big inspiration for me. And then I have two images on the bottom right that maybe some of you may recognize. This is a software called HyperCard from the old days of the Macintosh, so I put this up as a source of inspiration and also probably the first time I had that feeling of building a prototype. HyperCard is essentially a visual programming app that helps you put together a couple of different elements and actually build websites, build interactions. So for me it was that moment of being able to see an idea become tangible.

Principles

[00:02:57] This is Bret Victor. He is probably most well known for leading a design prototyping group at Apple. He has this talk called Inventing on Principle. This really resonated with me because the talk covers setting personal principles of how you approach building products. So I would like to share some of my principles. These are not necessarily the team's design principles, but some that I like to take and bring with me everywhere I go.

[00:03:55] So the first principle is to set your personal bar high. I tell everyone on my design team, I don't expect you to be a unicorn, but I expect you to try. I had a designer in an interview tell me once, I'm not sure if I want to be a designer, product manager or an engineer, and I'm like, that's great, you're going to be a perfect fit for product design, because we're going to do a little bit of everything. The intent is not to be a specialist at everything, because everyone's inherently bad at something and really good at something, but the more experience and context you have will help you move faster with your teams.

[00:04:30] I like to ask my team members, what's the next executable step? Building products is hard and it can cause a lot of confusion, and I like to keep it simple. So what's the very next thing you're going to do to move things forward?

[00:04:45] I get a lot of looks about this one with my team. Anytime someone says magic, everyone just kind of looks over at me as if to go, what's David going to say? But my belief is that design isn't magic, not magic but a method. So it's a rigorous process of hard work and iteration, but in the end, for the user, it feels magical.

One Medical and the design team

[00:05:10] So One Medical is a healthcare startup based in San Francisco. I got here last night, it was a 10-hour flight, so I'm very glad to be here. We are a pretty unique place where I like to say we own the entire experience stack, which means we have our own electronic health record, the clinical tools that the doctors use, we build our own consumer apps, and we have our own network of doctors and buildings. As anyone who's a UX designer, being able to have full control over your own destiny is a very unique opportunity to be in.

[00:05:48] This is my favorite part of the job, this is my design team. I get to work with them on a daily basis. All product designers do their own ideation, they run workshops, they do interface design and they're embedded on their teams. They also do user testing and research. And for me, and the culture of the team, I like to say that we don't take ourselves very seriously, but we do take our work very seriously.

[00:06:11] There's this concept called kaizen, it's a Japanese word, to improve, and this is a mantra that our entire company takes, not just product but operations and clinical. And this is really much, I think, the spirit of UXDX: continuous improvement and excellent execution. So we really believe in a culture of constant feedback and improvement, not just long-term but on a daily basis as well.

Execution versus vision, and what a good prototype is

[00:06:39] So when I was putting this talk together I was trying to think of a visual that would really resonate, and it always comes back to this one. How many of you have felt this way when you've been working on products? So, execution, vision. Building products is hard, and the one thing that I would say is when you build products you need to set time to explore and to learn.

[00:07:11] Some of you would know who this man is. It's Pablo Picasso. So one of his most famous works, this piece is called Guernica, and the one thing I'm most fascinated about it is the statement that it makes, but also the process which he took to develop and build it. So he did multiple, multiple iterations. If you've ever been to the Picasso Museum, there's multiple studies and drawings of the bull's head and certain elements of it. From there he takes those learnings and puts it together almost like a wireframe, and then puts together the final piece. So I think for us, whether you're a designer, engineer, product manager, this is the approach we need to take.

[00:07:52] So when you combine prototyping with the product vision roadmap, I think you have a very powerful process. We often talk about tactical and strategic. I like to live in this area that I call high tactical, it's a combination of both. And if anyone knows Herb Kelleher, who's the co-founder of Southwest Airlines, he has this famous saying: we have a strategic plan, it's called doing things. And that's very much true for us. I believe prototyping enables pathways for product visions, and it's dynamic. So as you prototype, you learn. When you take a journey somewhere you don't go from point A to point Z, but in fact you're continuing to pave the way and find new opportunities to navigate through.

[00:08:38] The other myth I want to debunk is that prototyping is to prove all your ideas wrong until it's right. I hear the term validate a lot, and user testing, and I would encourage you to think about it as testing and learning. Validation confirms what you want to hear, but the reality is user testing is about learning and insight. I like the saying from Pixar's 22 rules of storytelling, it's about the idea and notion of putting ideas on paper, because if it's in your mind it's perfect. It's like that drawing of the owl, it's perfect in your mind, but you don't know how to navigate.

The alien queen, and Inspirato

[00:09:17] Film is one of my passions and I like to use this as an example. If you're familiar with the film Aliens — I think this goes without saying, there's a spoiler coming up, so if you haven't seen this movie in 32 years you deserve to get spoiled. So I'll give you an example. In the third act there's this reveal of the alien queen, and this is one of the most iconic moments in film history. I believe the budget at the time was eighteen point five million. It's not the biggest budget ever compared to nowadays, but it's also not a lump of change.

[00:09:58] So Stan Winston, who headed the effects team, wanted to build a prototype of this alien queen, and the process that they took would surprise you. These are a couple of stills that I found. Here you see two guys being held up on a crane to be able to move this object, and this image here on the right is what's known now as the garbage bag test. And let's see it in action. So a lot of times we think it takes a lot to be able to learn or convey something, but this is probably less than 200 euro to build something that then became one of the most memorable moments not just in film history but popular culture. So imagine what you can do to your products with less. This is the final iteration, so from then they were able to learn and affirm that yes, this could work in practicality, and then implemented it.

[00:10:57] I got the opportunity to do something like that at a company that I worked with when I was at Black Pixel, called Inspirato. So the elevator pitch for Inspirato was a luxury travel startup, and they wanted to do something a little bit more aspirational and a little more narrative based in how they thought about search for travel. So they had this wild idea and we took a similar process.

[00:11:19] Anyone who's worked in agencies knows that showing low fidelity to clients can sometimes be a death wish. This is what we showed the client. This was myself and a couple of our engineers putting together a prototype in Xcode that's just a series of collection views that conveys the idea of this, and this took a couple of hours, and it was based on this whiteboarding session that we did on-site with the customer. Fortunately for us it really resonated, because they didn't need to see more, they saw the idea in action. This is what the final result looked like.

[00:12:06] So instead of going in with fancy visuals we started at the core of the functionality. So people often ask me, what makes a good prototype? And I think it's as simple as this: you want low cost and high insight. The intention of prototyping is to learn and save your money for production and implementation. So when you get a chance, do this all the time. Find those moments of being able to build things fast and in low resources, and a lot of that's going to come with your team's capabilities.

Nurturing a prototyping culture

[00:12:43] So let's talk about culture. The reason I start with culture is that I believe a great culture supersedes everything else and overrides everything else. So if you have a good culture around something it's going to cover a lot of bases that you ordinarily wouldn't have. So for me prototyping is not a task you check off, but it's a living and breathing culture.

[00:13:05] For example, one of our design team's principles is that we like to say we do evidence-based design. When you work with clinicians this is something that really resonates. So we're looking for the source of truth through objective and data-informed user testing and prototyping. So from the start we build in that prototyping is something that we constantly do as designers at One Medical.

[00:13:30] There's this framework I really love that Apple showed at WWDC a couple of years ago. It's called 60-second prototyping, and it's a simple framework of just how you go about doing designs: make, show, learn, rinse and repeat. This could be 10 hours or 10 minutes.

[00:13:47] I talked a little bit about continuous improvement, and this is something that we take at the core in terms of giving feedback. We try to avoid saying things like this isn't good, or this doesn't work, but spin it in a positive way and ask ourselves, how do we make this even better? And just continuing to ask that until it becomes better.

[00:14:08] For us prototyping is not just for makers and builders, everyone participates. We have product managers prototype and run these sessions with us. We work with people in the field, QA will look at our prototypes and give us feedback and participate as well.

[00:14:26] I often tell my team, you don't want to practice your chords while you're playing in the concert. So there's this concept of deliberate practice where you're actually setting a time for play and exploration. For us we do that on Fridays. We use a design tool called Figma, so we have Figma Fridays, which our team members get together and just do a jam session and share learnings. And we deliberately set time that's non-bookable for people, so it's our sacred time. It's a great way to end the week after a sprint cycle, to be able to share inspiration and get ideas.

[00:15:03] And I call that the builder's high. This is something that Michael Lopp, who's the VP of engineering at Slack, says. It's that sort of feeling after you've built something and have it come to life, that it becomes addictive in a way, because we constantly want to keep building and building and get that feeling again. So that's why we try to end with the builder's high at the end of each week.

[00:15:25] You want to build prototyping into your DNA. And if any of you are like me, I have to do a lot of recruiting, so we often get the question of, what's our DNA, or how do we hire people? So for me, we try to find people who are good prototypers, and it's people who are very detached from the solution, they're trying to learn. So it's not about validating if their design is right, it's about getting the right design. It's people who move fast and have that knack and that curiosity to be able to explore in building.

The many faces of prototyping tools

[00:16:04] Let's talk about the many faces of prototyping tools, because there's a lot. I'm not going to go through all, but share a couple of examples of when we might use them. I like the saying, it's not about what prototyping tool is the best, but which prototyping tool is the best for your current objective. So if you ever ask me what prototyping tool should I use, I will say it depends, depends what you're trying to do.

[00:16:28] For us we always start with paper, good old physical paper, something that everyone can use. Physical paper also means physical objects too. So for example, in January of, I believe, 2016, Apple announced that the watch was coming out, but it was only for pre-orders, so we couldn't get it until a couple of months later. So instead of waiting we just 3D printed one and started using it and doing paper prototyping. So a lot of pros and cons to paper: it moves very fast, but again sometimes the fidelity and testing on paper prototypes, it's just not enough, so you want to be able to go a little bit higher fidelity.

[00:17:11] Keynote and PowerPoint, what I'm using to present, are great ways to prototype. They have built-in animations that are really powerful, you can preview on device. And as I mentioned we're using Figma right now. It's really great because for us our doctors don't use Macs, they have PCs, but since Figma is a web-based tool we're able to share across all platforms and give people visibility on everything that we build.

[00:17:39] There's node-based prototyping, which I'll admit is my personal favorite, so I'll show an example as I'm talking about it. The one thing about node-based prototyping is you can tap into a lot of device functionality. So in this example I'm showing up here, we're actually tapping into the real device camera and being able to prototype using the hardware functionality. It's really, really powerful. The trade-off is a little bit of a learning curve.

[00:18:08] Then there's Xcode. We do a lot of user testing, we try to do it every two weeks, and this is just an example of building out three different variations that we can test with patients. The thing that's great is that it's a native tool, so our iOS team loves it when we use Xcode to prototype. The trade-off though, as you can imagine, our Android developers don't love it. So again, you can build things in high fidelity, but there's certainly a time and place for it.

[00:18:40] Then there's HTML and CSS. I really do very much believe that designers should know how to code. It doesn't mean you want to write production code, but being able to understand the ins and outs of things. As someone who studied art, I needed to learn how to paint and draw, but the knowledge of anatomy helped me really learn how to convey some of my ideas, and that's the same with code. So this is an example of a prototype that we built using Firebase, where we populated dummy data into a live prototype to test. It's extremely powerful. There is a tendency to be a little bit liberal with the code and sometimes that gets misinterpreted, so you've got to be careful there.

Now, next and future

[00:19:24] I will spend the rest of the time talking about this framework that I like to use. This is just for our team to calibrate with how we're talking about things. So I break it down into three areas. There's now, which is the current state of the product, what can we get done in the current sprint cycle. Next, what's on the horizon, what are those elements that are great for the opportunity backlog that need a little bit more clarity. And in future we talk a lot about our strategic operating plan and where we want to be in five years, and how do you tether that to what you do today.

[00:20:02] So let's talk about now. This is essentially integrated UX. Like many product teams, our design team works directly with the product teams they're on, so they join the sprint meetings, they join the retros and stand-ups.

[00:20:19] My former colleague Izzy has this great saying and I truly believe in this, is that the number one thing you can do to be productive is to reduce the iteration cycle. So how do you get more design cycles in? And that includes user testing in the cadence. User testing should be synonymous with retros and sprint planning, it should be done every sprint.

[00:20:39] I'll show an example of a project that we did user testing on, where we wanted to think about how we approach proactive care. So in this sense it's what happens between the office appointments for a patient and their doctor. So this is a patient who came in to give us feedback on a prototype that we built.

[00:21:26] Participant: Okay, cool. I like how you can see their progress for every day and it kind of fills up the hearts, that's really nice too. That's like where you pick your goals. Maybe if there was a way to view this month over month.

[00:21:42] So this is something that we were able to grab insights and nuggets of information on that wasn't too late. You heard the talk this morning about the waterfall method, where it's like, oh, you didn't ask for that yet. But we're able to share these insights on a frequent basis. So our job on the product design team is to bring those findings, but also involve our team in that, so you can continuously deliver and continuously improve.

[00:22:11] I recommend rapid prototyping here, and this is a little controversial for engineers in here, but I like to actually build in the real app. So what our designers do is build prototypes just from a branch of the actual app. It forces some great creative constraints, because you have to think about what you have now. Often designers will come and deliver solutions that have new button styles and new UI improvements, and engineers are like, ah, that's a bunch of new things. But it forces a good constraint.

[00:22:43] So I'll show an example of one where we wanted to test a way for patients to be able to see their other health information. So in this prototype here you'll see the real app using real data that's on staging, but here it's a static screen that we're able to just put in and get feedback from users on. It's really great because they can log in to their own accounts and look at it too, and it conveys the idea.

[00:23:08] Product discovery is what we were calling earlier the dual track scrum, so it's how do you continuously prototype and learn as you go along. So as you mentioned, I think there's probably an opportunity to improve on this and unify it a bit, but this is the same team that's iterating within the cycle. So you want to take those learnings and continually test, and then add that to the release cycle.

[00:23:34] That's what happened with patient tasks[?], one of our most popular features in the app. We did this about a year ago, and we were just constantly brainstorming and prototyping and showing this in front of users to be able to sell the idea that this is really important. So with the help of our product leadership we were able to get this prioritized, and now there's a proactive care team that's just focused and dedicated on this.

Setting the vision

[00:24:01] And the last thing I want to talk about is setting the vision. This is a little bit more abstract, this is where the horizon is a little bit blurry but you can see it. I can't tell you how many times I've worked at places where a question comes up in the sprint planning, it's like, what's our five-year roadmap, what's our vision, where are we heading with this? So when we create stories we like to think about now, next and future, to be able to convey the idea of what we want to do now and where we're heading. So for me it's how do we tether what we're doing now with our strategic initiatives and goals.

[00:24:38] We do a lot of workshopping. So this is a workshop with some of our product leadership but also some of our top individual contributors who have the best ideas, and we want their voices heard too, so it's an inclusive process for everyone to contribute to the vision. We then put together a book called technology opportunities that we then shared with the rest of the team, and of course people have the opportunity to give feedback and to contribute as well.

[00:25:07] So where do we go from there? We created a lot of high fidelity prototypes to be able to build the excitement on the vision of where we're heading, to see if it even resonates. We also use a tool that I love called experience prototypes. So at One Medical we're a digital product that has a service component to it too, so this is essentially prototyping different services to see how it works.

[00:25:35] I'll share two examples. This one was conducted by Sin[?], one of my designers who came from IDEO, so she is a master of workshopping. So she put together this big event around how do we think about the future of billing for medicine, and this project is around building electronic service tickets. So she invited people from all over the country — we're in nine markets in the United States — so people flew in to be able to walk through this experience prototype and give feedback.

[00:26:09] We had another project too that was around the future of the check-in experience. So right now at One Medical you walk in to the front desk and you verify with two bits of information, and part of the technology opportunities that we were talking about is how do we do more of an automating check-in, something that has that sense of delight. How do we think about the future of the office space, where there might not be even a desk there, but for us there will probably always be a human being welcoming someone in?

[00:26:36] So, how the illusion was made. We used Xcode and just built a little static prototype and I'd love to share it with you. So this was imagining if the check-in experience was on an iPad app. So what you'll see here is the first person checking in at the conventional front desk, and these are just our employees playing the roles of patient, and Jake, who's the one with the mustache here, will be checking in the patient on the iPad.

[00:27:29] So let me talk about what's under the hood. We essentially have a QR code that's like a unique identifier for a patient, and what I did was hard-coded every participant I knew that was coming, to be able to test that moment. So we wanted to learn if that moment was going to work, if there is any friction. The verdict's still out, we're still testing this, but this is an example of a multitude of different approaches we take to continue to prototype some of the more visionary aspects, and we bring those findings back to our sprint planning.

Recap

[00:28:01] I'll close with this. One of our sayings and other design principles is evolutionary till revolutionary. We really believe that constant iteration is the way to go. It's not from A to Z, it's not how do you get to the owl, but it's constantly working together with your teams in a great integrated way to continue to drive them.

[00:28:25] So to conclude, to recap: go for high value and high learnings, high insights and low costs for your prototypes. Prototyping is a living and breathing culture, so it's something that has to be nurtured and tended to, otherwise it's not going to spread throughout the company. No prototyping tool is perfect. Use user testing every sprint to get nuggets, findings and learnings. And use prototyping to convey the future state to get your team engaged with what's to come.

[00:28:54] So thank you for your time. I have the slides up here if you want to check them out, and if you have any feedback please send them my way. But I appreciate your time and thank you for listening.