Episode #199 Kelly Goto - Prototyping for Mobile Designs
Building a prototype is a great way to test your design early on with users. Whether you choose to go for a high-fidelity representation, or go lo-fi with paper, you can learn a lot about the usability of your site. Often, teams are concerned with which technique or tool to use because of the litany that are available.
Kelly Goto, founder of Gotomedia, suggests that the importance of the tool lies more with when you use it than why. Like a great chef preparing a meal, they use the right tool at the right time to arrive at the finished state. Use the appropriate tool and you're sure to cut down on difficulties you might encounter.
Part of having a mobile strategy in the first place is understanding exactly why you’re “going mobile”. Once you’ve determined what the value is to a mobile experience, Kelly says even something like paper prototyping can help validate the concept quickly.
Jared Spool: Well good day, everybody. We have another episode of the SpoolCast here. I am Jared Spool. I am the guy who talks to people. Today, one of the people I want to talk to is Kelly Goto, and I am very, very happy to have her.
For those of you who don't know Kelly, she runs Gotomedia, has been around in this industry since day one. She wrote a fabulous book years ago called "Web ReDesign 2.0: Workflow that Works," and she's going to be speaking at the UX Immersion Conference in Seattle, April 22nd through 24th, giving a session on prototyping for mobile designs, a full-day workshop on it.
Kelly, welcome. How are you?
Kelly Goto: I'm great. Thank you so much. I love that we've been here since day one. We don't have to talk about our actual age, but yes, we have been here since the beginning of digital time.
Jared: Since the beginning of digital time. Before that, we did not exist.
Jared: Right, there is no record of us.
Jared: You're going to be talking at the UX Immersion Conference. You're going to be talking about prototyping for mobile designs, which is a topic that I hounded you into giving because, frankly, I know that you guys at Gotomedia do such a fabulous job with your design work. We wanted to learn all of the techniques and tools that your team has at their disposal to actually get ideas out in front of people, try out things, see if it makes sense, and then use that as the way to guide their development process.
Just curious. Over the years, what tools have you been using, and which ones are still the most effective for mobile? Have things changed, or is it basically the same?
Kelly: I think I want to back up just slightly. The reason why I think prototyping is important, and the reason why I allowed you to force me into that whole session, is because I think that prototyping is actually the communication tool between businesses, between teams, between designers and developers, and obviously between the end users.
The prototype is a codeword for the best communication tool that we can create between all these groups, so that's why I think prototyping is so important. To answer the question, we have been using multiple tools, and yes, it has shifted and changed over the years, but one of the things that I'll be talking about and that I cover in the workshop is what tools are appropriate for your team, your toolkit, and what tools are appropriate at the different stages.
For instance, in the conceptual stage, it's going to be different people that are creating this concept, this prototype, and its different end users--potentially board members, potentially C-levels, potentially people that are funding this, potentially end users--to begin to understand if this is something that really works.
That might be one set of tools. Another set of tools might be from a design and conceptual standpoint. And then, finally, as we move into this communication between design and development, we have to have a whole another set of tools that actually help create or replicate the specification process. There is no one tool or set of tools that I want to actually put on the table right at this moment.
Jared: That's interesting. I really love this idea. It's almost like the way a chef cooks in the kitchen. They don't have one tool that they make the whole meal with. They have all these tools that are hanging around or in drawers or things, and they grab the right one at the moment they need it. That shifts the conversation from "Which tool should I master?" to "How do I master picking the right tool at the right time?"
Kelly: Yes. I won't get into pies, but I was just typing out how this session is a piece of the pie, whereas some of the conversation we're going to be having at the conference itself is not only a whole pie but it's potentially something completely different from pie itself. I was thinking about this cooking metaphor, actually.
And yes, these are tools. Toolkits. We're really big on creating a process that's flexible for people and then inserting concepts and ideas for the toolkit that will be appropriate to that team in the right time and the right place. You do want to pull out what makes sense.
There's a ton of new prototyping tools that have been launched in the last few years that actually supplement what we used to do with Flash or PDF prototyping, or even Axure or Balsamiq. There's a number of new tools that I guess fit into different pieces of that cooking structure, depending on what you're trying to accomplish.
Jared: Now, as people are moving to mobile, how important is it that they start to think about what their whole mobile strategy is before they start prototyping? Or should they just roll up their sleeves and start sketching or banging out some design and just get their head around it? I guess my question is, is it more about thinking about the strategy in your mind, or is it more about understanding the medium?
Kelly: For me, I guess, I hate to say it's twofold, but when we start off, one of the things that we've seen...Obviously, the mobile space has shifted so much in the last decade. You and I've been around a while, so we've seen it shift and change. It used to be really focused on what handset you're using and what OS and what type of language you're coding in.
People were so heads-down that they weren't really taking a look at the big picture. The concept of mobile user experience was not even a term before you and I started talking about it, before I started blogging about it. Mobile user experience was really limited until recently.
What I see happening is a lot of companies saying, "Oh, we need to get on mobile." They're using it as a really broad term, kind of like, "We have to deal with our branding." I've found that the first thing that we need to do is to help companies understand why they're going mobile, what that means. Is it a mobile device, is it platform-specific, or is it mobile in terms of allowing people to deal with their service or their product in whatever context or situation that they happen to be in? That's really how we define mobile in this day and age.
Instead of saying, "Oh, we need to build an app," we need to understand what is the core experience that they're actually trying to create, with potentially a streamlined experience, on a mobile device. We want to look at the value, the features, the usefulness, and the intent behind what mobile means to that company. Does that make sense as a starting point?
Jared: Yeah, it does. I'm wondering now, if I'm trying to figure out what value does mobile bring to the experience, is that before I start prototyping? Are there actually prototyping tools in my toolbox that help me visualize that process?
Kelly: Coming off of a number of, I guess, client relationships, and also some workshops, I think that prototyping, even paper prototyping, can be a really quick sort of validation of what that concept is, and then you need to pass it around and evangelize it within your organization.
I think that getting to the concept, there's a number of steps. From a mobile perspective, when you, quote, "go mobile," does that mean that you are taking your website and putting it onto a phone? Does that mean that you're recreating that experience for the phone specifically? Or are you taking a service or a product within your company or your company's experience and then creating an app for the phone specific to a function or a type of thing that people were used to doing online before?
Just understanding exactly what the experience is and then understanding the platform, the context, is it a complex or a simple kind of interaction, I find that to be really important.
There's something that came out of the lean startup space which is called MVP, which is the minimum viable product, and we'll be talking about that a lot in the session, in the workshop. Minimum viable product is actually quite interesting, because there's a tendency for companies to want to go feature-crazy and say, "We're doing all of these things and this is what we're capable of doing," instead of focusing on what are the minimum elements that need to be absolutely perfected before we launch, and what are those elements and how can we make them the best possible.
Focusing on that MVP, the minimum viable product, is actually a great way to start prototyping.
Jared: The interesting thing, I think, about this minimum-viable-product stuff is that a lot of the business people are learning about this now and reading about this, and it's a common phrase we hear about that. That's a great way, I would think, for a designer to get the interest of the stakeholders and to say, "Look, this is a way for us to test the minimum viable product," and to put together a prototyping strategy based on those business needs.
Kelly: Yeah, absolutely. If you look at that methodology, I like to use the term "lean" a little bit more than "agile." I feel like Agile's also one of those terms that just sort of came out and it's overused. But if we think about a process that allows this sort of streamlined communication between stakeholders to concept, and then moving from there into rapid deployment and iteration, that's really what we're trying to do, and that's what that process is about.
It's not about doing something so fast that you can't think about it, and it's not about providing less documentation or trying to approach it haphazardly. It's actually about focusing on what really matters, making sure there's buy-off and understanding at all levels from a business standpoint, and then continuing to iterate within both an organization and also with your end user.
We want to create something that's streamlined so that we can get through the most important pieces in a rapid way. I really believe that this does not mean that it has to be haphazard or that anything really needs to be lost in terms of the quality that's being put out.
Jared: I do know that that phrase, "minimum viable product," sends shivers up the spine of people who tend to have a perfectionist streak to them.
Kelly: But the other thing that is really helpful to think about from an organizational standpoint is prototyping bits and pieces. For instance, in one of the products that we're working with now, we have prototyping for a lot of pieces that we have questions about. Because touch is newer and different than what you can do online and there's a lot of space issues that we need to deal with, constraints, there's questions that we have about nuanced interactions that we want to test.
One of the things that I'll get into in the workshop is breaking it up into segments of interaction. You don't have to prototype everything. There are tools that are potentially better for testing out those snippets of interaction that can help you create a whole picture in the end, but you don't have to test everything. You can just test pieces that you have questions about and make sure that in a 10-minute test with someone that it's working for them.
Jared: Now to be able to do these 10-minute tests you need to have some fluency with the tools. How do you recommend people get to know a tool? Is there a way that you guys like to practice when a new tool comes your way? Do you just play with it for a while or do you just tackle the project with it? Or how do you suggest people get to know some of these prototyping tools?
Kelly: Well, I think everyone has their prototyping tool of choice, and so if you just run a little poll within your organization everyone's used different things from Keynote to Balsamiq to Axure or Paper Prototyping. People have their own tools of choice.
I think it's unwise to force people away from something that works for them, especially when they're working in a quick fashion. They're used to something, and they can execute it.
However, I have found that introducing a series of tools or one at a time with an organization and then having a training session...We've been really lucky to have some of the founders of some of the tools that we're looking at come in, because they're local and they want to get feedback and actually walkthrough their tool with us and how they think it's different.
That's been really helpful. You can take a look at podcasts and screencasts together and understand how easy, for instance, it is for a tool. I think for a tool to work across an organization it needs to be useable by the non-technical people. It needs to resonate with the people that have a technical bent, and in the end, if it is working towards requirements. It has to have really documentation abilities and output.
Now, we haven't one tool that fits all those pieces, but we are experimenting with a few of them that say that they do that, and really I think you just need to actually dive in and use it. So, yeah, jumping on a project and starting to use it right away, that's really going to be probably the best way to approach it.
Jared: Do you do any crosspollination stuff where like if you have someone on your team who's really good with Balsamiq do you have them do workshops to help other team members learn enough Balsamiq so that they can do a decent job pretty quick?
Kelly: We've been doing that with a couple products. One of the tools that one of our designers likes to use is Axure RP. It's actually a tool that's come up in almost every workshop that I've done over the last decade, because I've actually been looking at prototyping for a long time and how it fits into the overall process.
It's not that I recommend this tool for every organization, but there are a lot of people that use it because it has really robust capabilities, and it can do things at a higher level. There's some super easy to use newer tools like Proto.io, and I guess FieldTest is another one that a lot of people like to use. I mean there are so many out there. Easel is a new one that we've actually been working on in-house, and we've actually like it a lot.
I think that the newer tools, although they're slick and clean and they get your site looking really mobile ready, fast, and it's a great kind of wow factor, unfortunately some of those tools don't allow the level of detail necessarily for some of the interaction that I was talking about earlier that needs to be tested out in snippets, like new ways of doing gestures or swipes or pull down menus or just a little more detail that you need in order to get into the nuances of the interface.
But for concepting, it's fantastic. Once again it will differ where you're at and what tool that you use, and we'll definitely be getting into the pros and cons of that at the workshop.
Jared: I want to go back to this idea that there are different tools for different stages, and maybe you can help me understand like a tool that's really good upfront in the design process but not so good...what makes a tool be less than desirable in one stage, but really awesome in another?
Kelly: Well, I think that if you think about the stages from a really basic standpoint, you have brainstorming in concept exploration so you have that at the first stages. Then you actually have the concept development moving into UI creation, and then as you continue to the right we have specification development and moving into communication with the development team. So that's kind of, I guess, the basic outline of the stages.
Then you have states. So you have low-fidelity, the high-fidelity. In the years that I've been thinking about prototyping and prototyping in our group and testing, generally, low-fidelity to medium-fidelity is really excellent to get validation from early concepts to, like I said, the snippets moving into getting feedback.
Even the earlier that you test--we will always, always get into this--the more feedback you get early on it's always going to be better. Sometimes low-fi is really a fantastic strategy for every company to be able to engage in because they're going to get feedback early on.
People who look at it are going to feel that their feedback is something that's being accepted because it's in early stages. They're not going to offend anyone. It's a really good way to get continuous feedback in a really quick manner.
As we move into concept UI and the UI itself and then specification it kind of moves up that ladder from low-fi to high-fi, and we get into high-fidelity, we get into tools that work easily or merge with Twitter Bootstrap, and one of those is Easel. That's why we're playing with it, because we're trying to consolidate our libraries and all the different toolsets that we're using in our organization.
Then moving into what I had mentioned earlier, which is something like Axure RP, which is super high-fidelity and really leads into specification development, and it's a little bit more tricky to learn. It has a higher learning curve.
Jared: The low-fi tools, those are the sort of rough sketch tools that are just really fast, and because they don't have much fidelity you can just get the idea out there. There's an advantage to low-fi tools because they don't look finished, and because they don't look finished, people don't comment on things like, "That's not the shade of red you're going to use," or, "That's not the font you're going to use," and stuff like that.
You get to change the conversation from that level of inspection to, "Gee, is this the right functionality? Are we even solving the problem in a meaningful way," right?
Kelly: I think that's why people love Balsamiq and why Paper Prototyping UXPin has some really great paper prototyping tools. I think that's the reason why Balsamiq is so popular because it's saying, "Hey, I'm not finished, but can you comment?"
There are some low-fi products that maybe get a little bit into the medium category like Fluid UI or what's another one? Mockups I think is another one. There's Just in Time or Just in Mind--I can't remember-- that actually look professional, look finished, but they're super easy to get something up and running quickly.
There's a lot of drag-and-drop and in-browser interfaces, and then the shareability is pretty quick.
I think low-fi doesn't necessarily have to be rough in order to be shown. I do think that when people see things early on and they know that they're not offending anyone, they are more likely to comment from an honest standpoint and not try and please you and say, "Oh, that's beautiful! That's great! I love it!" I think that's why it is nice to do the paper prototyping and use Balsamiq from time to time.
Jared: The high-fidelity, when you're there, the conversation changes, right, from what you have when you're in low-fidelity. What are the things you notice that people talk about differently when you're working with a high-fidelity version of a prototype than a low-fidelity version?
Kelly: Well, high-fidelity means it's going to be more complicated. You're going to have to look at how you're actually creating the pieces. For instance, with Easel, if you want to build a responsive site and look at that from a design perspective, you need to build it a certain way, you need to import in Twitter Bootstrap library, and you need to know code in order to really execute it properly.
There's a larger learning curve, a longer time to actually create the prototype, and if you want to export it in any way that's usable, then it just takes a lot longer.
I think the other factor is the time to get your thought out. The beauty of some of these easy tools is that you can get your thought out quickly. As we move into easy tools that have a robust export feature, the idea there is that you can get your ideas out easily for non-coding types, and then the coding types can take that as a hand-off and then create specifications out of that and even move into an actual code environment.
I haven't seen that, personally, run as smoothly as the proposed service might think it might run. But for teams that are working, small teams, in-house, moving fast, I do think that some of these tools could cross the gambit and fulfill all those needs. It is tricky, and it needs to have the right resources.
Jared: It does make sense, on some theoretical level, that if you've got this thing looking right on the screen and it's interactive, that somehow or other developers could use that as a specification. Where does that tend to break down, though, in reality?
Kelly: Well, usually, the code is throwaway code, and so the time that it would take to actually structure something correctly in one of these environments isn't really going to yield the code that you need because, in the end, it's more complicated than what a machine output can create.
The reality is that we usually hand off something. In the old days, we would hand off a Flash prototype and put it into a specification use case and sort of create the desired movement, the desired behavior, within the animation and use that to help developers understand what they should do. In today's world, you can mock that up pretty successfully using a lot of these prototyping tools, and then you can actually test that live. Some of the interaction will work.
But like with any tool, it's really whatever the best fit is for that individual person. You have to take into consideration what their skill set is and what their goals are and what they're trying to do. I really do believe that it's quite a diverse tool set, for each company, each team, and each individual, and you need to look at a lot of different features.
There's so many versions of tools out there that it really is boggling my brain, doing all this looking and research, so I have to stick with my toolkit mentality, where you pull it out when you need it, at the right time.
Jared: I'm interested in the relationship with the developers. Do you find yourself bringing the developers in earlier into the process than you might have otherwise? And if so, are you working with them side-by-side on the prototypes, or are you basically handing this prototype off to developers and saying, "This is the spec. Code from this"?
Kelly: What we've been doing is working within more lean-UX principles. I don't want to say "Agile," again, because I think that's loaded. But it works best when the teams can work closely together, when they have daily meetings, when they have access to each other, even if it's one day a week, where they can actually work on a white board and sketch things out and show things in person. I find that the designers and developers truly need to establish whatever means of communication that they need that works for them.
Prototyping is a great tool, but I guess I would prefer that the prototype mimics a concept and shows a behavior rather than it becomes a full spec, because I believe that if you have the right level of communication between the design and development team, that you can translate that fairly easily using wireframes and screenshots and call outs, along with a prototype mimicking behavior, to get that specification across.
When we're in a Lean environment and we need to work quickly, then we need to use whatever communication means is viable, while still maintaining some level of process so it's not completely haphazardly done.
Jared: It feels to me like prototypes give you this opportunity to speed your process in a way that you don't get when you're either doing some sort of large Word document specification or the ritual of drawing things on the white board and hoping the thing you imagine in your head is the thing they imagine in their head.
Kelly: Exactly, yeah. There's some great tools for just sketching something out, taking a picture of it, putting it on your phone and testing it right away, and there's some tools that actually allow you to stack these things and create interactivity on the fly.
I think that getting your idea out and getting feedback is really the gist of what we're trying to do, and whether you're getting feedback from the stakeholders or the business leaders or your development team, and most importantly your end users, you want to get that feedback quickly, you want to iterate, and then re-put out that prototype or even build it into the process of the development cycle, and get continuous feedback throughout.
Jared: You had mentioned earlier about responsive design, and this is something that I've had conversations with, and I guess I'm not clear on the answer. Which is, if I'm starting to think about responsive stuff, so I've got what my design looks like on a high-resolution desktop, or I have what it might look like on a small-screen-size phone --though some of those can be really high-resolution now-- or on some middle-size tablet type thing, what do I do with my prototypes?
Do I come up with three different prototypes of what the interaction might be like in each of those sizes, or do I primarily pick one and then just focus on that to start with? What's your practice there?
Kelly: That's why we've been using Easel and we've been playing with it, because Easel allows you to build these containers, and then you populate the containers, either through drag-and-drop or through code. The containers scale, so there's output for Web, tablet, and mobile. We've been playing with this. It's only been out for six months, and it's still in development.
We've been really impressed so far. But we do need to show our clients, usually wireframes with breakpoints, and if we're able to wireframe and do prototyping, using something that automates this process, it's so much more helpful and streamlined for us.
We've found this to be working and to be highly successful, and we're also trying to integrate changes with the product itself that would even help it streamline that process in a more efficient manner. So it's been a continuous, I guess, moving through this. We used to spend so much time creating three different versions or two different versions to show different breakpoints, and now we're finding that we can use tools like this to mimic it real-time.
Jared: That's fabulous. I'm really excited about the workshop. I think that people are really interested in learning how to make sure that prototyping is part of their design process. It was something I was really glad that we were able to snag you for this and have you, because I think people are going to really love it. I'm really looking forward to your workshop at the UX Immersion Conference in April.
Kelly: Yeah, absolutely. I really think that prototyping and the level of communication that's needed just constantly comes up. In every organization that I see, they're asking the question, "What should we be using? What should we be using?" Because this is such a topic, combined with a more streamlined process that we all know that we're trying to achieve, I think it is a perfect addition to what you're proposing for a curriculum for the UX Immersion Conference.
Jared: Fabulous. Kelly, thanks for taking the time to talk with us today.
Kelly: You're welcome, and I'm looking forward to April as well.
Jared: I want to thank everybody. You can learn more about Kelly at gotomedia.com. She'll be at the UX Immersion Conference, April 22nd through 24th, doing her full-day workshop, "Prototyping for Mobile Designs." It's going to be a lot of fun, and a whole bunch of people have already signed up and seats are going, so you want to make sure you get your seat.
If you listen to us on iTunes, it would be awesome if you were to go and just check out the ratings for our session and put in your opinion, because people are listening to us and they're looking for new stuff, and if you thought this was great, it would be wonderful if you could put that there. We look at the ratings and would love to know what you think.
Thanks again for spending the time to listen to us. We'll catch you at a later time. Thanks for encouraging our behavior. Talk to you soon.