Design And Prototyping

DESIGN AND PROTOTYPING

SPEAKER 1
Okay, can everyone hear me okay? All right. Great. Thank you so much. My name is David. Before we start, they say they know your users. So, I'd like to know the audience a bit. So 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. So, thank you, for the UXDX panel for having me. 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 like, how do you think about going through the execution and make sure you're still aligned with the strategy?

So, 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 on what does that mean to kind of build that sort of capability in that habit, the many faces of different prototyping tools, we are in the golden age of design tools, design systems, and like 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 that I like to use called: Now, next and future, it's how you set expectations of the roadmap moving forward. So, a little bit about me. I've been doing design for more than a decade and have had the privilege of working in a lot of different industries. So, 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, before I was director design at a company called Black Pixel, I led a prototyping team.

So, we did a lot of product discovery, in need of finding clients, varying from Fortune 500 companies to smaller start-ups. I was really pleased to hear there's so many people who have an arts background, because I did too. So, my backgrounds in drawing and painting. So, if there was one thing, I really learned from my experience in studying art, it was learning how to learn and learn 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. So, 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. So, HyperCard is essentially an app. It's a visual programming app that helps you put together a couple different elements and build websites and interactions. So, for me, it was that moment of being able to see an idea become tangible. This is Brett Victor, he is probably 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.

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 expect you to try. I had a designer interview, tell me once I'm not sure if I want to be a designer, product manager and 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. So, you can tend not to be a specialist to everything because everyone is 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. I asked my team members what the next executable step was.

SPEAKER 1
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? I get a lot of looks about this one with my team. So anytime someone says magic. Everyone just kind of looks over at me. He's like, oh, what's David going to say? But you know my belief is that design is not magic, but a magic method. So, it's a rigorous process of hard work and iteration. But in the end for the user, it feels magical. So, one medical is a healthcare start-up based in San Francisco. So, I got here last night, it was a 10 hour flight. So I'm very glad to be here.

So, we are a pretty unique place, where I like to say we own the entire experience deck, which means we have our own electronic health record, the clinical tools that the doctors used, 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. This is my favourite 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, in the culture of the team, I have to say that we don't take ourselves very seriously. But we do take our work very seriously. 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 dx is continuous improvement and an excellent execution.

So, we really believe in a culture of constant feedback and improvement, not just one term, but on a daily basis as well. 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, right. So, building products is hard. So you know, the one thing that I would say is, when you build products, you need to set time to explore, and to learn. So, does anyone know who this man is? Pablo Picasso. So, one of his most famous works is his piece called Guernica. And the one thing I'm most fascinated about is the statement that it makes, but also the process in which he took to develop and build it.

So, he did 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 them together, almost like a wireframe. And then put together the final piece. So, I think for us, whether you're a designer, engineer, product manager, this is the approach that we need to take. So, when you combine prototyping with the product vision roadmap, I think you have a very powerful process. We often talk about tactical, in 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. That's very much true for us. I believe prototyping enables pathways for product visions and keeps it dynamic.
So, as you prototype it, you learn that 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. The other myth I want to debunk is that prototyping is to prove all your ideas wrong. Until it's right. I hear that term validates a lot in 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. An insight I like to sing from Pixar's 22 rules of storytelling is 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.

SPEAKER 1
Film is one of my passions, and I like to use this as an example. So, 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 18 point 5 million. It's not the biggest budget ever compared to nowadays but it's also not a lump of change. So, Stan Winston who headed the effects team wanted to build a prototype of this alien queen, in the process that they took would surprise you. These are a couple of skills 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 in popular culture.
So, imagine what you can do with your products with less, this is the final iteration. So, from then they're able to learn and affirm that yes, this could work in practicality and then implement it. I got the opportunity to do something like that at a company that I worked with. It was a black pixel called inspirado. So, the elevator pitch for inspirado. It's a luxury travel start-up. And they wanted to do something a little bit more aspirational and a little more narrative based on how they thought about searching for travel. So, they had this wild idea. And we took a similar process. Anyone who's worked in agencies knows that showing low fidelity to clients can sometimes be a Deathwish. This is what we showed the client, this is 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 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. 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 costs 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 low resources, and a lot of that's going to come with your team's capabilities. 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 some, it's going to cover a lot of bases that you're not narrow-minded. So, for me, prototyping is not a task we check off. But it's a living and breathing culture. For example, one of our design team's principles is that we like to say we do evidence based designs, 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, that one medical, there's this framework I really love that Apple showed in at WWDC, a couple years ago. It's called 62nd prototyping. And it's a simple framework of just how you go about doing designs, make shows, learn, rinse and repeat. This could be 10 hours, or 10 minutes.

SPEAKER 1
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 in a positive way and ask ourselves, how do we make this even better, and just continue to ask that until it becomes better. For us. Prototyping is not just for makers and builders, everyone participates. We have product managers who 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. I often tell my team, you don't want to practise 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 playing an exploration. For us. We do that on Fridays, we use a design tool called Figma. So, we have Figma Fridays, where team members get together into a jam session and share learnings and we deliberately set time that's not bookable for people.
So, it's our sacred time. It's a great way to end the week after a sprint cycle to share inspiration and good ideas, and I call that the builders 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 builders high. At the end of each week, you want to build prototyping in 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 like, what's our DNA? Or like, 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 and learn. So, it's not about validating if their designs are 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 and build. 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. So, I like the same. It's not about what prototyping tools are the best. But which prototyping tool is the best for your current objective? So, if you ever asked me what prototyping tool I should use, I would say it depends. Depends on what you're trying to achieve. 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 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 is just not enough. So, you want to be able to go a little bit higher fidelity, Keynote, and PowerPoint, what I'm using the 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 MAC's, 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. There's node based prototyping, which I will admit is my personal favourite.

So, I'll show an example, as I'm talking about it, the one thing about note based prototyping is you can tap 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 hardware functionality, it's a really, really powerful trade-off that is a little bit of a learning curve. Then there's X code, 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 patience. The thing that's great is that it's native tool. So, our iOS team loves it when we use Xcode to prototype. The only trade off though, as you can imagine, our Android developers don't quite love it.

SPEAKER 1
So again, you can build things in high fidelity, but there's certainly a time and place for it. Then there's HTML and CSS, I really do very much believe that. Designers should know how to code 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 populate dummy data into a live prototype to test. It's extremely powerful, there is a tendency to kind of be a little bit liberal with the code. And sometimes that gets misinterpreted. So, you have to be careful there. I will spend the rest of 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. What 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 the future, we talk a lot about our strategic operating plan and where we want to be in Five years. How do you tether that to what you do today? So, let's talk about now this essentially integrated UX. Like many product teams, our design team works directly with the product teams they're on. So, they joined the sprint meetings, the retros, and stand ups. My former colleague has this great saying, and I truly believe 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 within a sprint, include user testing in the cadence user testing should be synonymous with retros, and sprint planning, it should be done every sprint, I'll show an example of a project that we did user testing, where we want to think about how we approach proactive care. So, in this sense, is 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. So, I'm going to play it real quick.

SPEAKER 2
every day to kind of feel better. Touch this outdoor walk and take a leisurely walk. Maybe. So, we're going to select that. Okay, cool. Um, see, it said, I'm doing a hamstring stretch. And then meditate, we'll do it all the easiest. Okay, cool. I like how you can see your progress every day. And it kind of fills up the hearts. That's really nice to kind of see like, where you hit your goals. Maybe if there was a way for you this month over month. So, if this is something that I like...

SPEAKER 1
We were able to grab insights and nuggets of information 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 kind of 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. I recommend rapid prototyping here. And this is a little controversial for engineers 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 other improvements. And engineers are like, ah, that's like a bunch of new things. But it feels like a good constraint. So, I'll show an example of one where we want 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 it in and get feedback from, from users on, it's really great because they can log into their own accounts and look at it too. It conveys the idea. Product discovery is, you know, what we were calling earlier, the dual tracks Chrome. So, it's like how do you continuously prototype and learn as you go along. So as 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 it within the cycle. So, you want to take those learnings and continually test and then add that to the release cycle. That's what happened with patient tests, one of our most popular features in the app. We did this about a year ago. And we're 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're able to get this prioritised. And now there's a proactive care team that's just focused, dedicated to this. And the last thing I want to talk about is setting the vision. This is a little bit more abstract. This is where the horizons are 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 a sprint planning. It's like, what's our five year roadmap? What's our vision? Like, where are we heading with this? So, when we create stories, we like to think about the 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 do what we're doing now with our strategic initiatives and goals? 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 contribute as well. So where do we go from there? We created a lot of high fidelity prototypes to be able to just 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. I'll share two examples. This one was conducted by sin, one of my designers who came from IDEO, so she's 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 buildings like 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, we had another project that was around the future of the checking experience. So right now, one medical, you walked in front desk, and you verified with two bits of information. And part of the technology opportunities that we were talking about is how do we do more of an automated check in something that has that sense of delight? How do we think about the future of the office space where there might not even be a desk there, but for us, there will probably always be a human being welcoming someone in. 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.

SPEAKER 1
So, this was imagining if the check and experience was on an iPad app. So, what you'll see here is the first person checking in the conventional front desk, and these are just our employees playing the roles of patients. And Jake, who's the one with the moustache here, will be checking in the patient on the iPad. Okay. So let me kind of talk about what's under the hood. So, 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 want to learn if that moment was going to work, if there is any friction, the verdicts 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. I'll close with this. One of our sayings, and other design principles is evolutionary till it’s revolutionary. We really believe that constant iteration is the way to go. It's not from A to Z. It's not how you get to the Al but it's constantly working together with your teams in a great way to continue to drive that sort of conclusion, like to recap, go for high value, and 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. 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. 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.