The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #262 Theresa Neil - Designing Native Apps

March 3, 2015  ·  28 minutes

Listen Now

Download the MP3

Offering a mobile design is essential in today’s web. Having an app, however, can be a hotly contested issue. The cries of, “we need to be in the app store!” are heard coming from corner offices. While having a presence there can be beneficial, you have to determine how to best serve your users, and whether a native app or a web based product is the ideal.

Show Notes

Theresa Neil has been working in mobile since before the emergence of smartphones. Originally part of the team at Sabre, she’s had experience designing for all manner of portable and non-traditional devices. One of the major advantages of native apps is the ability to use them offline. You also get full access to the sensors within the device, enabling you to provide a richer experience.

Advances in CSS and HTML have made some of the sensors and cameras available for use through web apps. We're seeing hybridization; web-based apps within their native wrapper. Fixing or updating now becomes much easier since it all lives in code and you don’t have to rely on point releases and the users upgrading the app on their own.

Full Transcript

Jared Spool: Hello, everyone. Welcome to yet another episode of the SpoolCast. Today I have with me the amazing, wonderful Theresa Neil. She is going to be teaching a workshop, our first one ever really, on designing for the brave new world of native apps. It was wonderful to get Theresa on the program because she and her team have been doing some amazing work on building out some really sophisticated and wonderful, delightful native applications. She knows a lot about what that takes. We're going to talk about that today, and talk about what it takes to make a great native application. Theresa, how are you?
Theresa Neil: I'm good. Thanks, Jared.
Jared: You've had some pretty awesome clients working in your little firm. How big is your firm now?
Theresa: There are about 20 of us, about 12 of us full time and then we have a support team that jumps in as needed for prototyping and creative visual design and UI development. But our core team of UX designers is 12.
Jared: You're primarily working on native mobile apps these days. Is that true? Are a lot of your work is in that space?
Theresa: Well, we take a combination of software, software as a service, B2B projects, B2C, and a number of those companies already have existing either software or web applications and they've turned to us to either design those or design those with a mobile counterpart. It's not unusual for us to have projects where we're designing across five or six platforms, most of those being mobile. But there's usually also a web component, as well.
Jared: Has this been pretty much since you've started? Or did you move into mobile over time? How has the balance shifted?
Theresa: Yeah, well, I started 14 years ago at Sabre, the airline company.
Jared: Yeah, so we're not talking mobile then.
Theresa: Well, no, actually, we were.
Jared: Oh, oh, wow.
Theresa: I was really lucky in the early days of mobile. Before we had smartphones, I was doing a lot of work in the airline industry for figuring out how people within the airline were using mobile devices to make their job more efficient. We worked on projects called CurbSide, where the man or woman for the airline would actually have a device on their hip that allowed them to check in customers, instead of having to make them go through the check in line. Think of it as kind of a roving agent that would come up to you and help you check in and get your bags loaded up and you wouldn't have to wait in line in the airport. That was some of the early mobile work. Then there was also a lot of investigation around, how do you display bar codes or boarding passes on the old flip phones, so that you could just wave your flip phone in front of a reader and get on the plane instead of having to print out a boarding pass. I also had the opportunity to work on all types of different platforms that I don't touch much today, like Kiosk and Wall UI, as well as, of course, your desktop software for managing planes and personnel. Then, after doing that for about five years, I ended up becoming a consultant, and since then I've worked in all types of verticals. I guess since, 2008, when the iPhone came out, there's been a definite push towards creating a mobile experience in addition to, say, maybe an enterprise tool or a software as a service product. We do have a lot more mobile work today than we did in 2008.
Jared: Yeah, I mean, when I think of people doing amazing mobile work, you always come top of mind. Part of that is because your team has done a fabulous job of really understanding how to think these problems through. Look at, what is it we're trying to do and then how do we make that happen on whatever devices we need to make them happen on. Then what makes the most sense in terms of, should this be a website, should this be an app. Those conversations with clients, have they shifted over the years? Do people come to you telling you what they want and then you say, "Well, no, that's not really what you want"?
Theresa: We have a lot of that. When the iPhone came out, everybody came to us and they're like, "We want an app." If you were in design in 2008, you heard the same thing. It was like, "I want an app for the App Store." Our first question back is, "What are you trying to achieve?" A lot of times, an app wasn't the right solution. A mobile optimized site may have been the right solution, a responsive web design may have been the right solution, or some type of cross platform experience that could include an iPhone app was the right solution. It really just depended on the customer. I think the most interesting one that, in the early years of the iPhone that we came across, was a company came to us and we had designed their product as a pervasive data integration. This is a really, really complex web application for mapping out processing in order to do data transformation. Very heavy UI in terms of dragging and dropping and charting and graphing flows. They came and they're like, "We want an iPhone app." I was like, "Oh, my gosh. We'd never be able to do what we just did for a web application on an iPhone. That would be completely impractical and it doesn't make any sense in terms of, your users would never sit down and try to map out these complex flows on their mobile device." They said, "No, no, no, no, no. We know that. What we want is a marketing tool. We think that we can create this little ROI calculator and put it out there. Nobody else in our field has anything in the App Store like this. If people pull up our ROI calculator and see how much money they can save using our product or a product like it, then it's a really good sales channel for us... I was like, well, that's exactly right. That's exactly how you need to be thinking about coming up and creating an app and putting it out there for your customers or for your prospective customers. It's very rarely, do we want to create a mobile solution that maps one to one to an existing piece of software. But it could either enhance it, support it, or act as a sales channel for it. I was pretty pleased with their thought process around how to leverage the App Store.
Jared: There's a lot of tools and things now because of the sort of explosion of discussion around responsive design and building responsive websites for how to build something that's a web-based solution that's going to be used across all different devices. But one of the things that I've noticed, at least as I've been trying to answer questions for our clients and put together programs for our conferences, is that the number of people talking about and providing tools and support for cross device native applications is really limited. You can find some great resources for Android, you can find some great resources for iOS. But it's very hard to find people who talk about both. Then you add Windows phone into that and the occasional stillborn Nokia Symbian user. All of those things are still not, it's hard to find people who talk across all these different platforms. I've been wondering why that is. Is it, you don't really need to have that conversation? Or is it just that it's too complicated? Or is it that nobody's actually, they either do one or the other and they don't know enough to be able to talk about the other thing?
Theresa: Well, I'm not sure why. I guess my answer would be, I think it's very similar to years ago when everyone was a web designer. If you had FrontPage or Dreamweaver, you were a web designer. In fact, most of the people that were in the field were doing website design, a very content centric, sharing information, low amount of transaction, so very focused on the content. Responsive is all about that. Right? It's about how do you get this content across any device at any time to any audience. But there is a small group of us and it's a growing group, who are focused on software. When you talk about mobile software, that typically falls into the realm of native applications. That's not to say that you can't ever make a responsive web application that handles transactions well. However, when you're getting down into software like a project we did recently for Johns Hopkins, it's a tool for birthing attendants and midwives in Third World countries to help make sure that more moms and babies live through using the software tool that identifies whether a birth is obstructed. That's not a responsive web solution. These tablets go offline, there's a lot of heavy charting and processing going on in the application. That type of software lends itself towards a native application, one that can be installed on a device and has offline capabilities as well as the capabilities to use other information from the phone that you would not have available in a mobile web solution.
Jared: There are things that the native platforms can do, that even if you had good connectivity through the web, are still hard to do on the website. Is that a shifting space? Is it the case that there are now easier things to do than there used to be in terms of having a web-based platform? Or is it, there will always be a certain number of things that the native world will have to account for?
Theresa: I think it's shifting. A couple years ago, the only way that you could take a photo and use it within your mobile experience is if you were utilizing a native application or maybe a hybrid app that was wrapped and able to use the camera capabilities. But now, with iOS 8, if you're on a mobile site for, say, a retailer that you like to use and you're going to check out, there's the ability to integrate it right into the Safari browser for you to snap a picture of your credit card. It's definitely shifting. The thing is, our clients that come to us, they need this functionality today, so I can't say, "Well, that might be in the web a couple years down the road." If it's not available now, we have to come up with a solution that can capture that ambient data or integrate with a sensor or integrate with other applications. If that's a requirement for the product, then we need to go ahead and build it natively.
Jared: When a client comes to you and say, "We have this idea of something we'd like to put in the hands of our users." How do you start to draw the line between whether something that you should definitely go down the road of a native app or it's definitely something that would be best served through some sort of cross device mobile experience, or something that could go either way, but you're not quite sure yet?
Theresa: Usually we start off with some round of either market research and UX research or simply the UX research to inform how people are going to be, or how we think people are going to be using these experiences. For example, we're working with a company today that has a health care provider application. Even without an extensive amount of research, if you've been to your doctor and your dentist and maybe a chiropractor or an eye doctor, you'll notice that all of those different health care providers are using different types of devices. Some of them might be on their laptop, some of them might be on a smartphone. They might be on a Windows tablet or an Android tablet or some unidentifiable tablet. They're all using different types of devices. A lot of that is because what's being dictated by their hospital or the organization that they're working within. To say, well, let's create a native application for them to see, let's say, I don't know, patient data, then that seems to me like that would be overkill. We don't actually need to design and develop discrete native applications for all of the different possible platforms of these health care providers might have. A responsive web solution would be ideal, because they can simply go into their browser and consume this content that's being generated for them, so, these read only views of all the information about their patients. Responsive's a great solution for that. Going native would be very costly and overkill. However, if you were talking about creating a solution for maybe their patients to log information about their medical issues. If you start looking at that and you're able to see, well OK, most of the people out there in the US are using iPhone and Android. A native application would be able to take advantage of, say, like, some of the notification capabilities on a smartphone. Then we start leaning towards, oh, well, the patient solution may be better suited to be a native app, right? So that people could be maybe reminded on a daily basis, or say, be able to chat directly with their health care provider. All that would, at this point in time, work better as a native application. That research helps inform which direction we should go, technology wise.
Jared: Part of the challenge with all this is really sort of understanding what the use cases are going to be and whether the hardware and the software and the connectivity issues are going to push you in one direction or the other.
Theresa: Definitely.
Jared: Now, when you're looking at this stuff, do you guys approach projects by trying to build out one design that's going to work on every platform and then tailor for the idiosyncrasies of the platform? Or do you say, "OK, we're going to do the iPhone version first and then we're going to do the Android Lollipop version then we're going to go to..." How do you decide how to tackle the design detail?
Theresa: The way that we start, after we've done our UX research, is we map out the customer experience and the workflows within the overarching experience. We may have a number of different types of users. Like I was talking about, you might have a health care provider versus, say, somebody who has maybe a disease or a medical issue that they're having treated. We look at those different individuals as personas and what they're trying to accomplish. In our experience map, we start to see, well, at what point would these different users need a mobile device versus maybe in front of, say, their desktop or their laptop? A perfect example of this that, you don't see it that often when you're looking at building out, say, a website, an information or content heavy website, would be creating some type of transactional app. For example, one that we were working on that was for a solar plant. In this application, we have somebody who is in charge of a solar plant and he has hundreds and thousands of solar panels that he needs to manage. As we got into developing the personas and the workflows for this, we realize, well, this guy who's in charge, he's almost always in front of his computer. He's in his office, and he's working in both a proactive and reactive mode and he's got a big monitor in front of him. This is how he's managing and monitoring everything. But when something goes wrong, he has to dispatch a guy out there to go fix the panel. That guy's not in front of a computer. In fact, he's almost never in front of a computer. We know that when we map out this experience that we've got the manager in a normal desk work environment and we have a guy on dispatch who's in a truck. He's going to need a mobile experience. Whereas the manager user is completely fine with, say, web experience that works well on a desktop or laptop screen. Once we identify the areas where a mobile solution would add a lot of value or may, in fact, be the only way we want to create an interface, then we start looking at, well, how do we design for these specific platforms for mobile?
Jared: This is interesting. Right? Because I thought, what you were going to tell me was, well, we figure out what the requirements are from the business owners and we go off and we build the iPhone app first and we build the Android. But what you're saying here is, you're taking a step back and you're saying, OK, let's talk about the entire experience of use. Let's talk about the different users and the different things. Different people are going to need to interact with this functionality in different ways with different technology. We're going to approach it in a more holistic form, instead of just assuming that there's an iPhone app followed by an Android app followed by a Windows phone app.
Theresa: Exactly, yeah. That's one reason that when you asked earlier, like, do you guys just do mobile apps? Well, no, because then we wouldn't be doing our job. Because very rarely is an experience consumed solely on a mobile device, at least in my field, right, of working with these companies that they're looking for a software solution. It frequently starts on one device or the person's experience starts on one device and then they finish it or continue with it on another device. It's rarely just mobile. It might be on the wall and then on the phone. It might be on the phone and then in the car, like in the example of a project that we did with Silvercar, which was one of my favorite projects ever. We set it up so that you could...
Jared: Who's Silvercar?
Theresa: Silvercar is a startup in Austin, Texas, and they decided they wanted to re-imagine car rental for business travelers.
Jared: Oh, cool.
Theresa: They started with a fleet of all silver Audi A4s. They wanted to remove all the pain points from business travel, like waiting in lines, all that extra paperwork.
Jared: So they're called Silvercar and then they went out and got silver cars?
Theresa: Yes.
Jared: That's quite a coincidence.
Theresa: [laughs] It is. You know what, it makes their marketing and advertising really easy to do, too.
Jared: I bet it does, I bet. Because if they had gotten red cars and they were called Silvercar, people go, "What the...?" Now I get that.
Theresa: This is really fun. When we did the research for them, we found out that there are a number of different types of business travelers. You've got kind of that hard core business traveler, kind of the grumpy one that you see. They're in a suit and they're kind of grumbly and they give you the evil eye if you're like cutting up and having fun, pushing around a baby carriage or something. Those folks typically, when they start off, booking their business travel, they're typically at their desk at work and they're using the system that their company provides. That's almost always starting with the desktop experience. However, they then quickly move into using a mobile device during their actual travel time. But then, following travel, after they've picked up their car, they've been on their business trip, they've returned their car and they're back at their desk, now they're going into the expense phase. Right? They need their receipt. All of that's done back on the desktop. For that type of persona, they're actually going desktop, mobile, desktop.
Jared: You're thinking all these things through. This has all sorts of implications in that it's not so much that the UI that we create on the iPhone, for say, has to feel like an iPhone. It has to feel similar to what I just did on the desktop yesterday. Right? Because if it's like two different experiences, then it's like two different companies and I'm lost.
Theresa: Right, and so our motto is that the UX should be the same across platform, meaning, the flow should be consistent and efficient for that customer experience that we mapped up. However, the UI is different per platform. How we actually lay out the content in the screens and the interactions and the controls are all specific to the device that we're designing for. For Silvercar, when we created the booking flow, when we did it on the web, it was like booking on the web. When we designed it for iPhone, we used native iPhone controls and experiences and gestures and interaction patterns. When we designed it for the Android, we used the Android design guidelines. So those interactions, those UI controls, and those patterns, as well as their guidelines around the aesthetics. The Silvercar iPhone UI and the Silvercar Android UI act the same, but are unique to the platform they were designed for. If we had done a Windows one, it would have been unique to the Windows navigation paradigms and gestures and UI controls.
Jared: That makes a lot of sense. I've got a question for you. Google's just come out with this new Material design language. Have you guys played with that at all?
Theresa: Yeah, we're currently working on a project for a company in California called Grokker. They're an expert video network. This is actually something we're going to incorporate in your workshop in the Spring, where we're going to take a look at Grokker, who has a responsive web experience, and then look at how to design that to be a native mobile experience. There's a lot of different things that we're going to do around that other than just port it one for one from responsive to mobile. Then after we get that design for the iPhone, we're actually going to learn a little bit about the Material design guidelines and see how we can design it for Android. That's something that my team and I are working on now, is creating their Material design for the Grokker application.
Jared: That's really cool.
Theresa: Oh, it is so cool, especially with this client. Solar panels, like if we were doing that Material design for Android, you could still make it OK, you could make it interesting. But when you're doing a video network and you get to apply these really, I think, well designed guidelines around the transitions and animation, it's a lot more fun. This is a great client to be able to explore Material with.
Jared: I'm curious, when you get to work in Material, because it's so interestingly thought out and you move to other platforms, do you feel like you've stepped back into the past? We come from the future, now we have to go back into the past and do this stuff. Or is everything now in parity, almost?
Theresa: No, I see what you're saying. I was working on something today and I had to go back and look at the University of Texas iPhone app that I designed in 2009. I had to pull up all the deliverables for it. They're just, it's wireframed. There's like an app map and then there's wireframes and then there's all these flat files. The direction that we've gone now is delivering interactive prototypes that embed the animation and the transitions.
Jared: Oh, so your design process has changed over the years.
Theresa: Completely. Completely. Handing off a stack of flat wireframes or a PDF -- this is what the folks over in the responsive side of things have been saying for the past couple of years -- that just doesn't cut it anymore. It doesn't communicate what our developers need to implement a good design. We're trying out a bunch of different tools for animation. Like, Keynote has the magic shapes or magic spots -- I can't remember what they call it -- that lets you put in animation through Keynote. There's a bunch of other tools out today that are really set up to allow you to add animation and transitions to your native prototypes.
Jared: Are you finding in the sort of native installed app world that designers who are afraid of coding are going to run into the same sort of problems that web designers who are afraid of coding are running into? Which is that, you have to have some basic prototyping and coding skills to be able just to communicate your intent, otherwise you're going to be left behind?
Theresa: Well, I don't know. I have a number of people on my team who are not developers and there is a large group of tools that have come out recently that are geared for designers who are not developers that give them the flexibility and the features that they need to simulate the animations. I don't think it's quite as detrimental as not understanding Bootstrap would be to a responsive web designer. Like, there's this program out there called Pixate, P-I-X-A-T-E, and if you can use Photoshop or anything in Creative Suite, then you can use Pixate to plug in these animations. I think it's actually easier for folks who are designing native apps, because the control set for iOS and the control set and animations for Android are, well, they're established and it's a discrete set. Whereas for mobile web, you could do anything. Right? The sky is the limit. Whereas, with Apple and Android, there's a good base to start with. It doesn't say that you can't ever create anything novel, but if you have these base controls and their interactions, it's a good playground to start working with.
Jared: Wow. OK. Well, I'm really looking forward to your workshop. I mean, it's going to be so interesting. I have really not spent much time looking at designing for the native applications and so I'm really excited about having the opportunity to dive deep and spend the time doing this. It sounds like you guys are putting together something really, really awesome.
Theresa: Yeah, I'm really excited about it. I'm going to start off and do, as you know, I'm doing the four part workshop with you. To make sure that I've got all of the kinks worked out of it, I'm going to start giving little dry runs of it at the local incubators around town over the next couple of months.
Jared: Oh, fabulous. That's a great way to do it.
Theresa: Yeah.
Jared: Well, cool. Well, Theresa, thank you so much for spending time talking to me today.
Theresa: Well, thanks for having me. It was great.
Jared: Yeah, and if you guys who are listening would like to learn more about this, I highly recommend you go over to the UX Immersion website at uxim.co, and you read all about her full day workshop, designing for the brave new world of native apps, which she'll be giving in Salt Lake City April 13-15th is when the conference will be. She'll be doing an entire day on designing for native apps. It's going to be so much fun. Of course, check out her website at strategyplusdesign.com. That's three words, strategy plus design dot com. Also, if you haven't gotten your copy of the "Mobile Design Pattern Gallery," book from O'Reilly, it's a must have book. I'll give you a secret, if you go look at her website, there's like a code that saves you some money at the bottom of the page. Anyways, I love that book and I love the work that you're doing, Theresa. Thank you so much for talking to me today.,
Theresa: Thanks, Jared.
Jared: Thanks to everyone for listening, and as always, thank you for encouraging our behavior. We'll talk to you soon. Take care.