2014 Main Conference Talk
It’s the user who’s mobile, more so than the device, and users will turn to the best screen available when they want to get things done, whether that’s a mobile phone, tablet, or “desklap” machine.
Will your product work on that screen, whatever size, shape, or capabilities it offers?
These challenges demand a holistic approach to user experience design that must break out of the boundaries of a single particular device or even a single application, and embrace users where they are and when they want access to the service inside the product.
Holistic UX design starts with exploring and understanding user journeys in the larger ecosystem, and then works from back to the front, building a solid foundation in the platform layer before developing any user interface.
About the speaker(s)
Christian Crumlish has a decade’s experience leading product teams, with several decades of UX success behind that. He is currently building a product team at COVID Safe Paths, a volunteer open-source nonprofit privacy-first contract-tracing solution for Coronavirus. He consults on product and UX leadership at Design in Product, where he also hosts a community that explores the overlap between UX design and product management.
Formerly, he was head of product at 7 Cups, winner of the 2016 Stanford Medicine X Prize for health systems design and a 2019 World Economic Forum Pioneer. He has also co-chaired the monthly BayCHI program, was a director of product at CloudOn, was director of messaging products for AOL, was the last curator of the Yahoo design pattern library, and served two terms as a director of the late lamented Information Architecture Institute.
He is the author of the bestselling The Internet for Busy People (McGraw-Hill) and The Power of Many (Wiley), and co-author of Designing Social Interfaces (O’Reilly). Christian lives in Palo Alto with his wife, Briggs Nisbet, and an ever-growing collection of ukuleles.
Christian Crumlish: Let’s jump right into it. This is a talk about holistic UX and it’s also to really talk about IA.
You may have figured out by now that the IA Summit is not always about IA. It’s sometimes generalized UX Summit or something like that.
What I’ve been finding in my work these days is that trying to make a common user experience across a multiplicity of devices, like this phone here, and this phone here, and this tablet here, and this desk lap here, it turns out it requires information architecture. I’ll be getting into that a little bit.
I also really love saying holistic and ubiquitous, or holistical and ubiquital, spendifical, phenomenal, maybe not. That’s a little bit goofy.
Actually, holistic is one of the words that we say in my office a lot. We end up using it to mean lots of different things because we’re constantly trying to remind ourselves that these experiences have to work across all these different touch points, all these different scenarios, all these different devices.
At a certain point, it becomes like a crutch word and we’re constantly saying, “But what’s the holistic solution?” and, “How are we going to do this in a holistic way?” Every once in a while, I want to do this.
I’m as guilty of that as anybody else. I say it now as a buzzword. But it really does mean something. It means treating things as a whole. I don’t know where the “W” went, but it’s that kind of whole, not the other kind.
One other thing, just a technical note I want to make, is that I unconsciously plagiarized the title of this talk a while back. I booked Justin Maxwell, who’s an awesome UX designer, to speak at BayCHI a couple years ago. He did this amazing talk on holistic user experience. He’s got slides out there. He used it more in the sense of user experience as a common responsibility of the whole team, as opposed to just the design team.
I’m a great believer in that, too, that user experience is the responsibility of everybody involved in the effort and not just the people with design training. But I unconsciously stole his term and changed the meaning, so this is my penance is giving him a little shout-out here.
Let me get right into it. That’s enough disclaimer-y stuff.
First of all, I want to ask for a show of hands. Have you ever been in a situation where you’re in a meeting or your boss or somebody else came up to you and said, “We need a mobile website.” Yes? No? You’ve heard that one?
How about, “We need a mobile app”? Do you hear that one, too? Is there usually a good reason why, or is it just keeping up with the Joneses kind of stuff? We’ll get into that stuff.
My problem, and the origin of all this thinking for me is the problem of silos. If you’ve heard Lou Rosenfeld talk in the last couple of years, he often brings up this idea of silos. There are great pictures of silos out there on the Internet. I actually prefer this kind of silo image because it indicates that the teams are working separately in a huge anonymous industrial agricultural space or something like that.
The reason why I think like this is my background before I joined the start-up a couple years ago, if you go back through my previous job experience, I spent about three plus years at Yahoo.
One of the things I saw at Yahoo is that they had this concept back then called Yahoo connected life, which basically was the mobile team. It was this guy named Marco Berries, and he had this model of, in the future, how people are going to connect to the Internet through all kinds of different devices. Of course that vision is coming true. The problem with Yahoo connected life is that they created a silo.
If you worked at Flickr and you wanted to make a mobile Flickr app, their team said no, you can’t do that because we do the mobile apps. When a CEO came in and realized that Marco was blocking mobile progress all across the company, he was fired and there was much rejoicing.
When I left Yahoo, I went to AOL on my way to explore the depths of the Internet industry. I used to say the next job I was going to take after that was at CompuServe. Then, Prodigy and then Genie, I think. Then, BBS in Toledo was going to be my end-state.
The thing I mostly worked on there at least towards the end of my time was AIM. One of the things we tried to do with AOL Instant Messenger was make it a cross-device experience, make it work in the browser, make it work as a downloadable app, make it work on devices.
We came up with a common UX and all that, but at the same time, there was a mobile team and the mobile team owned the mobile version of AIM.
I was the director of product of the AIM team and then there was a product manager working on mobile AIM who didn’t report to me. She was super cool and we had meetings and we tried to coordinate. But if she wanted to ship a feature that I didn’t want to ship, she would ship that feature. In my mind, it wasn’t the best way to do this kind of mobile development.
There’s a history to this because mobile skills and aptitudes came along later. A lot of people who learned to develop for web browsers were not necessarily trained or adept at coming up with sites that work well on mobile devices, let alone apps that run natively on mobile devices.
The way that most companies have extended to mobile is to build a team that has a mobile expertise. Again, that’s completely understandable and it’s probably a normal phase to go through. But I would suggest that it’s not a good end state because it creates this idea that there are various products that are separate, the mobile product being something different from the product on the web.
I don’t think that creates a great experience. I believe in a holistic experience.
When I got the choice to actually go work at a start-up, one of the things that appealed to me was that the ground wasn’t really broken too much. It was a small team and there was no way we were going to have silos.
If I came in to run the product team, which is what I do now, I would be able to define what’s the mobile experience, what’s the browser experience, what’s the handheld experience, what’s the 10-foot experience, whatever.
It would all be singing off the same sheet music. In fact, CloudOn which is a mobile productivity company, Aaron mentioned that I’m going to talk about the company. I’m not going to pitch CloudOn to you. I’m not doing a sales pitch. It’s more that I’m just talking about my work there.
A couple years ago, Jesse James Garrett gave a great plenary at this event and mentioned that in the IA world, we often talk about process and tools and techniques and concepts and metaphors and great stuff. But we less often talk about the actual work that we’ve done and hold it up to scrutiny. I’m trying to do that and point to a process that’s actually in play right now.
One of the interesting things about CloudOn is that it launched on the tablet. It was a tablet-first product. It launched on the iPad.
When I joined the company two years ago, there was an Android version coming out on the tablet as well and then I spent a lot of the summer of two years ago trying to figure out what would make sense on a phone.
Ultimately, just last year in the fall, we came out with a web browser version. We’ve reversed the normal evolutionary cycle of the web, where most people make browser experiences and then mobile phones came along and they figured out is it time for a mobile site or do we actually need an app? Then tablets came along and they had to re-think that. Do we just scale up our phone or do we need a different layout, et cetera?
Walking it backwards from tablet to phone to the browser has been a very different experience. One of the things I realized when I came in is that having done a tablet first it wasn’t really a holistic design. It was a very highly tablet-tuned design and it didn’t naturally translate to the phone.
We ended up having to do mobile second and figure out the phone version. Then of course what happens is that feeds back. That makes you rethink your concept.
If you don’t want to build out completely separate silos then every time that you advance one of the versions of your product or service, you have to think through how’s this going to play out in all the other touch points.
I learned some very painful lessons doing that. I’m going to share my slides by the way. I hate slides with lots of text on them. Don’t feel like you have to read along or anything.
One of the hard things was when we started building the phone version, partway through we realized that the engineering team was actually building a completely separate app, so there’d be a tablet app in the store and a phone app in the store. We didn’t want that.
Late in the game, those two code bases had to be stitched together. At first it’s a front door where you come in and the code says, “Is this a tablet or a phone?” and then, it runs one code base or the other. Over time, we’ve been unifying the different layers, but it’s been painful refactoring the thing together.
I also discovered that getting apps through the Apple app store is a huge pain in the ass. It takes away almost all the fun of the web, where you could make stuff and ship it and notice a mistake and fix it and rolling updates and commits that go live, and things like that.
Instead, now we have this experience that Bill Scott once compared to 1980s-style making a golden master and then shipping it to a plant so it can get pressed on CDs and get sent out. It’s like we have that kind of a delay now.
It’s also taken us several years to get the instrumentation right. This is a huge thing that I’ve been realizing about apps, which is that anybody who says that you don’t need information architecture in an app has never tried to instrument an app.
Because there’s no way to make sense of what users are doing if you don’t have a taxonomy of all the different objects in the system and all the different events that can happen when people swipe them or touch them or click them or whatever.
If you don’t start off doing some IA, down the road when you start to wonder what your customers are doing, you’re going to have to do some information architecture.
The last thing I realized late in the game is what the lean people call get out of the building. If you’re building mobile experiences, you’ve got to take your build on your phone and go walk somewhere where the WiFi ain’t so good and the 3G ain’t so good and see if your app really is pretty cool under those circumstances.
Otherwise, it’s the equivalent of the beautiful visual design that looks awesome on a giant screen and doesn’t work so well on someone’s old monitor.
Just to mention Bill Scott again, he also mentioned that the install process is the worst on-boarding ever invented by man. Getting someone to download an app and install it is a huge, huge pain.
We’ve been sort of fortunate. We’ve had millions of people download and a very large fraction of them actually register, which is unheard of.
It’s so much nicer to just let people come touch a website and be in there right away without having to commit to downloading an app onto their device.
A couple high-level things I want to hit at and then I’ll go into more detail on what these mean, when I say holistic UX, these are the things I try to keep in mind as I do my work.
The first principle, and I say this almost every day, is that when we’re building a mobile experience, that doesn’t mean we’re building experiences for mobile phones. It includes that, but to me, mobile software, mobile web, mobile development has to do with the customer being mobile.
We’re designing an experience for people who work around, who have computers in their pockets. They have tablets on their lap while they’re riding CalTrain down the peninsula from San Francisco to their office in Mountain View.
They work on desktops, too. If you design for a mobile person, that doesn’t mean you design just a mobile phone experience. You have to design an experience that will work as the person is mobile, as they move from place to place, while they’re actually in transition.
Another thing that I realize is that they call me a product manager and we call the thing that we make a product, but it’s not really a product. It’s a service.
Products are in boxes on shelves. You have to tool machinery to crank them out so you can make tens of thousands of them, all exactly the same.
This is a digital product, and it’s got a service at the back end. It’s got a platform. When you think about it that way, then it’s a lot easier to say, “There’s only one service.” It’s not an iPhone service and an Android phone service. Actually, Abby Jones says this is a tablet. I say it’s a phone. Whatever. It’s not a desk lab service. It’s a service that you reach through all these different touch points.
Another thing that we’ve learned the hard way is that you can’t design in terms of pixels anymore. This is something that people are learning on browsers with responsive design. If you have to build downloadable apps written in Objective-C or Java, there actually aren’t as good responsive frameworks for that yet. It hasn’t caught up with the web, ironically.
If you want to make an interface that’s adaptive, that can run on an Android device you’ve never seen before with some weird proportions, and still work, then you have to do it in terms of rules. You have to say, “This panel always is attached to this other panel, and if there’s enough room, display it. If not, it can be swiped on, but it can never get less than this big.” Things like that.
There’s also the concept which I think I first heard from Luke W., called “best available screen,” which is not that people are dying to edit Microsoft Word documents on their telephones, I’m pretty sure. But they actually do that when the phone is what they have, and they need to do their work, and there’s nothing else nearby.
I actually collected, at one point, a Twitter conversation where some guy said, “I just wrote my term paper on my phone.” One of his friends was like, “Dude, how did you do that?” He said, “CloudOn.” I was like, “This is going to go in the ad someday.”
Christian: But I also thought that’s crazy. I would never write a 10-page paper in my app. On a phone, anyway. The last thing is this concept of peripheral vision, which I’ll come back to. It basically means you can’t really design for eight or nine touch points, or three touch points, at once, because design does require focus.
At some point, you have to say, “What’s on this screen? What’s the solution right now?” When I say peripheral vision, what I mean is keeping a little bit of your eye on the other forms.
If you’re designing a tablet screen, I like to tell my designers, “Keep a little corner of your paper where you doodle the phone version.” It doesn’t have to be as fully worked out, but every time you come up with a new idea for this tablet layout, think a little bit about, is that going to translate to the phone?
How’s that going to work on a big screen, too, where we have a mouse and tool tips and things like that? You can’t focus if you’re going to try to split your attention among three of four different formats, but you have to spend a little time on that.
It’s something I actually learned while painting a long time ago, which is that if you get really into one part of your painting, eventually, the other parts get stale and you have to come back and change them again. How do you do holistic UX? I said what it is, but how do you actually do it? Every time I think of this, I think of that Monty Python sketch called, “How To Do It.”
Here he explains that the way you play a flute is you hold it up to your mouth, you blow through the hole, and you jolly well move your fingers up and down along the buttons.
Christian: I’m hoping that my explanations don’t sound like that. There are a couple principles, or at least concepts, to keep in mind. I apologize, again, for bullet-ridden slides. This is a summary slide, so I’ll dig into it a little bit more.
One thing is the whole concept of what to do first. We’ve been stuck on this “mobile first” idea for a long time.
I had a very interesting Twitter thread with Whitney Hess, about a year or so ago, which got me thinking about some of this stuff. She was pointing out, “You can’t do mobile first, because you have to actually figure out if your users want or need a mobile experience.” I thought, “Of course, because you have to do your research first.” You have to make sure there’s a market first.
There are all these things that come first, and you keep going further and further up the chain. I actually think when people say, “Mobile first,” what they meant was, “Try out the experience. Try to design it for mobile first to see if it will work, if you’re going to have to be on mobile, which generally nowadays, you do.”
Another thing is to map out the whole ecosystem that you’re going to be playing in. Not just the flaws of the device or the experience that you’re building, but actually the world that you want your experience to fit into. What are people doing today? Some of this is stuff we already know from UX, like journey-mapping or doing ethnographic research.
I mean actually literally drawing diagrams, where you say, “Here’s a typical user. In the morning, they get up. They go buy a latte. They’ve got their phone in their pocket. They get on the train. Later on, they have a doctor’s appointment.” You make up a story to begin with. I’ll go a little bit more into that.
You look for when your customers are mobile. You think about what those touch points are and how to make them better. You do what I’ve been calling “Big IA,” which is that IA is the level of the meaning, the mapping, the relationships, the concepts that you want people to understand when they use your product.
You start sketching right away. We do 90 percent of our work in sketch form, as much as possible. You get to prototyping as quickly as possible. A lot of these are just general good practices, anyway, but they happen to be essential for the way that I’m trying to do holistic UX. I mentioned already all the things that you should do first.
You should research, of course. You should understand your customers. You should think about a holistic experience before you think about just a phone experience. Later on, you can worry about the actual, specific details of the devices or the end points.
Frankly, because, at least if you’re like me, and you’re designing a service, you probably, long before you design the interface, you’ve got to design the platform. You got to figure out what the APIs are going to be, because all of these interfaces are going to be talking to a back end. You want a common back end. You’re not going to build a separate platform for each one of your devices. No, you’re not.
How do you map the ecosystem? You do some concept modeling. If you’ve never done any concept modeling, please buy Dan Brown’s book, “Communicating Design,” and immediately read the chapter on concept modeling, and start doing it right away. It’s my favorite IA technique in the world.
It just involves thinking of concepts, words, nouns, generally speaking. Writing them up on the wall or sticking them on the wall, and then connecting them with lines that are typically verbs. You say, “This is part of this. This owns this. This needs one of these. This has some of those.”
I mentioned already sketching elaborate journeys. Think about an experience your user’s going to have that doesn’t always involve them buying your product and giving you money, but just doing what they do. You’re going to have to fit into their life, not the other way around. We do all kinds of storyboards. We try to keep it light, with stick figures and quick drawings.
I’ll show you a couple wall drawings a little bit later. The other thing is also to think a lot about, again, meeting your customers where they are. The web, when it first appeared, it was really about, “Come to my page. Come to my home page and see the content on my website.” Eventually, people figured out that people may just do a search and land on a random page at your site.
After a while, you realize they may not be at your site at all. They may be looking at an embedded tweet on some other page, or some other sort of thing. You’ve got to actually think about your experience not just happening in controlled devices and software and screens that you own, but leaking and trickling out in many other ways.
One of the critical ways, actually, is by email. Email is still the number one UI of the web, if you ask me. It’s the one app everybody’s using all day long. Most apps speak email in a sort of rude, broadcast-only way. They send you notifications and messages and try to get you to click through and come back.
A smart app also listens to email. Unless the users answered the email and don’t say, “Do not reply,” but takes that reply and understands what it’s about. At that point, you realize that the SMTP is actually one of your interfaces. Not just HTML, not just Objective-C, et cetera. This is what I think of as a journey map.
By the way, [inaudible 17:06] has changed since I was a kid. It did not look this psychedelic and weird.
This is the kind of thing I’m talking about. We have a lot of light board walls in our office. When we’re discussing stuff or we’re trying to figure out a model, a relationship, a flow, generally, the first thing we do is go find an empty space on the wall.
Actually, erase part of the wall, generally speaking, and spray that horrible stuff, because it’s all caked on. Then, we do quick drawings to communicate with each other. This is just like we’re working on the difference between a personal dashboard and a public profile. The person with the crown is the owner, the main person.
There’s a world out there. That’s what that globe is supposed to be. That’s a globe.
All the other people are people. That’s an eyeball. They’re seeing one side of the view. The person sees a different side. Down here, you get their view, where it’s the public profile. It’s just a quick drawing that illustrates that we’re going to have to build something that has a facet for the owner and a different way of looking for all the other users.
There’s a drawing elsewhere on the wall that shows, “How does the owner see what people are seeing of their public profile?”
Another quick drawing, at one point, that was part of this big, long storyboard on a wall. I drew it out and then I took photos of all the things and then I put them in a PowerPoint click and then I sent it out to my team and I said, “I think this speaks for itself.” They’re like, “What the hell is that?”
Christian: “I have no idea what you’re talking about.”
This is a person on an airplane, they are sitting on a seat. The person behind them has their tray table down. They’ve got a tablet on it running CloudOn. They’ve got crappy WiFi, so the image in the cloud is kind of crappy and then they’re using our product.
This person had more experiences, but this was just part of that drawing. There’s a person on a BART train, there’s a dude holding a phone in his hand. We do this all the time. Long before we’re in plan and drawing with pixels and stuff like that, we’re sketching all the time.
As I mentioned, if you get this journey the person’s going through, this life that they’re already having, that you’re a product to be part of, then you’ve got to think about, finally, where are the touch points? Where along the way are they going to actually want to know whether anybody has made any changes to that document that they sent out last night, which would be a scenario I would care about.
But you could think whatever your product is, what time of day, at what moment, when do they care, when are they going to be reminded? What are these interesting moments, another idea I stole from Bill Scott, where you can add value, where you can show them the value of what you do, where you can start to get them involved in what your service is?
What are those little micro interactions, those little moments where they are brought in, they have a great experience, and they think, “I’m going to do this again next time.” The other thing is when we’re mapping out the larger scenario and then looking for the touch points where we fit in.
We try to look at the stuff we’re scared of. There’s a lot of stuff you try to brush under the rug. You’re like, “Well, that part we’re going to do later. We’ll figure that out. We’re going to hire somebody. He’s going to figure that part out.” You’ve got to dig right in on that stuff right away, the hard stuff.
Because that’s some of the stuff you’re probably going to want to be prototyping and learning about faster, rather than shying away from. You want to, also, identify what are the make or break experiences. Because there are always a million choices about what you can offer the customer.
You can focus on a lot of different things and there are a lot of different ways to make a good experience. But you’ve got to think about which parts of what we’re building are going to make it if it’s great or break it if it’s bad? There’s a lot of other optional stuff you can pull out at the last minute, but there are certain things that if you don’t get that right, your product sucks and no one’s going to like it.
You’ve got to figure out what those things are if you possibly can. Once you figure out what those moments are, that’s when you start mapping the moments to devices. I don’t even want to think about what device I’m designing for until I figure out is there an opportunity, is there a moment, is there an experience that fits this, that makes sense for somebody using this device?
If it’s they’re walking down the street, then let’s give them an experience on the phone. If it’s they’re arriving on public transit, then we’re probably going to have to support the phone and the tablet for that experience.
If it’s something that people generally don’t do unless they have some time to focus and sit still for a while, then maybe it’s going to primarily be happening on their desktop. And trying to figure out the difference between whether to do a phone or tablet experience at any given moment, I think about the level of focus.
The shorthand for me is that on phones you typically do one thing at a time, one task, one big red button, you push it. Mainly because there’s not that much room on the screen. But also because people have limited attention and trying to show them six different things on the screen to do is not really generally very helpful for them.
I found that tablets have more room to display content. You can actually show a split screen, you can have an area for work and an area for tools. They’re not quite the same thing as the larger desktop type device, but they support other, more involved, more generative experiences and more complex experiences.
You do have to keep an eye on tablets. Tablets are growing super fast and have actually crashed the rate of growth of Smartphones, just in the last year or so.
Then I mentioned sketching, I sketch everything and I have my team sketch everything. We sketch the flows out from beginning to end, all the way through, whether those flows move through one device to another. We sketch, of course, screen elements, pieces of the design that are going to move around and show up in different formats and different places.
We do, at some point, have to say, “Hey, what are we coming out on first?” In this case we came out on tablet first. Or, I’m doing a redesign. I’ll show some things of the redesign a little bit later.
If you’re working on the tablet and in case of our product, then sure, at some point you’ve got to focus on that. A designer’s going to spend days just getting a couple screens right on the tablet. So there is a point where you can keep your eye on everything, I guess I mentioned peripheral vision already.
That’s what this was about. There’s also all these different parallel complexities, especially on mobile devices, that have to be thought about from the very beginning. When CloudOn first came out on tablets, it was landscape only. Our customers really wanted portrait, because you get more screen height there above your keyboard and we’re used for writing documents and things like that.
When we came out on the phone, we came out portrait only, because there was almost no room at all in a landscape view to type. But over time, people decided that they wanted both and they made that clear to us.
We also have to decide, are we coming out on a browser and also in a native app at the same time. Are we going to support all these different versions of this OS or just the most recent ones? What hardware are we going to support? Android is a nightmare, there’s so many versions of the OS, there are custom version, there are so many different devices, and you’ve got to figure out how much of that you’re going to cover.
There’s landscape and portrait. Just an example, this is an old screen from our product that’s about to be replaced, but it’s something we call FileSpace. It’s basically the metadata activity stream around the content that you’re working on. The upper left is just a wire frame, a quick and dirty patch together that shows a little metadata area with a thumbnail of the image and some facts about the file.
Then, an activity stream where a person can add a comment and you can see what’s happened. On the upper right is the way it looked on the tablet when we first shipped it. In the lower left is the way it looked in the browser when we first shipped it. In the lower right, it’s how it looked on the phone when we first shipped it.
You’ll notice that on the phone it was two different screens. Because to actuate the activity stream and then the metadata area that includes who else is on this file were really one at a time screens. So modularly they were two separate concepts that had a relationship with each other and when there was enough room, sure, put them both on the screen next to each other.
But conceptually, they each could stand alone on the screen. We had to think all that through. Here’s a close up of how it looked at the time on the tablet. Here’s how it looked in the browser. It’s all evolved since then.
Just to give you a preview, this is the way it’s going to look soon. This is a person in their file manager with the file space panel open to the left and then expanded fully. This is the landscape version of it and that one expanded fully as well.
Honestly, I had to repeatedly tell the designer, “What about the portrait view? What about the portrait view?” He’s like, “Oh, I’m going to do it at the end.” I’m like, “No, you’re not going to do that at the end, you need to do it now.”
Christian: As soon as he went into it he’s like, “Oh, I just realized something doesn’t work.”
Christian: Similarly, we had to figure out the phone part and yes, the phone was procrastinated a little bit and fell behind.
A good trick I learned, when we had the tablet design worked out but hadn’t figured out the phone design yet was take the code from the tablet and run it on the phone. Just ask the engineer to flip the switch that lets it run. Even though he’s like, “It’s not going to work. Don’t open any bugs.”
But the point was, the design actually, we had been trying to make it more based on rules and less based on pixels and some of the stuff actually laid out just fine. This is the file manager and it looks good. I don’t think you have to change any of that.
Actually, one thing we’re going to change is that the side navigation doesn’t need to be visible all the time on the phone, it takes up too much. The rule on the bigger devices, which was that you always peak out this little bit of the navigation, needs to be slightly different. We need to say when the screen was less than, blah, blah, blah. Let it close completely and use the hamburger to open it up and the hamburger is going to have to shift over.
Suddenly, they didn’t think that through fully, did they? Here’s the file space panel opening up. It doesn’t make sense to have a small file space panel that covers 90 percent of the screen and then have it expand a couple more pixels to a full view. There’s got to be a rule that says there’s only one size for the file space panel when you’re on these smaller devices. That was another thing that had to go from a fixed pixel design to a rule based design.
That’s the side navigation opening up. That’s not quite exactly how we want it to be either, so we’ll play with that. Probably the stuff on the right we’ll pitch further over to the right.
These are just some shots of how we redid the global nav and tried to think about all the different form factors at the same time. Including, even, Nexus 7, which is a fablet, horrible name for a seven-inch tablet.
Christian: Some modular stuff, it’s kind of cool. Once you have the navigation figured out on the tablet scale it had to be worked, so does it all make sense. When you say it’s one screen on this device, but it’s going to two screens on this device, that affects your navigation, because now there are some more places to go on the other device.
But conceptually it all has to work in the same way. More recently as the tablet redesign matured, I assigned one of our interns — this amazing UX apprentice Maya Wagoner — to map it out. Also, she was new and it was a great way to learn what we’d been doing. She built out this map, but also the maps were never perfect.
So I said, “Print it out on the wall, put a sticky on it, and ask people to correct it,” and people went around saying, “Shouldn’t there be this here? Doesn’t this one actually connect over there?” and that was pretty useful as well.
I love maps, maps are how we all communicate and agree on the model of what we’re doing. Of course, prototype, I’m probably not the first person to mention that we should be prototyping all the time. Prototype all day long. You can make prototypes based on sketches, you can make them based on just wireframes. You can make them based on really nice looking box.
You can prototype with your final design. I’d say do it at every stage along the way. You can definitely base it on sketches. I often draw on the wall, take photos, assemble them together into a quick little slideshow, on one of those apps like Pop or Protosketch.
Then you can at least decide, “Does this even work? Would I do this? Is my thumb covering that part of the screen right now? Does sliding left to right make sense?” Prototypes are great for testing at every level.
First, just like I said, just yourself. Make a prototype and try it, you’ll immediately say, “I’m not going to show this to anybody. I see a couple things that suck,” and you’ll change those things.
Then grab people who are on the team and run it buy them. Then go to people in the company who don’t work on design and show it to them. Then, finally, go down to the corner and go to the coffee shop or recruit people and do a serious user test when you’ve got something that you’re pretty solid about.
I just want to wrap up by saying that you don’t have a UX for each of the devices that you make. Your web or your app or your site or your product or your service has a single, holistic user experience, so please start acting like it.
Christian: I’m going to encourage questioners with a little bit of swag. “I get shit done,” is one of our mottos. I’ve got a small and a 2XL, so first person who asks a question and wants one of those sizes, let me know. I have stickers for people who don’t want a t-shirt, and one other.
Audience Member: One of the things that you had on one of your slides was you said, “Use your peripheral vision the whole time.” I’m kind of a newbie, so I get drilled in and focused, when you talk about peripheral vision, what are you talking about…?
Christian: I’m specifically talking about this idea that…By the way, do you have an iPad?
Audience Member: I do.
Christian: Would you like an iPad case?
Audience Member: Yeah. [laughs]
Christian: What I meant was just that idea of if you’re doing…let’s say you’re designing for one type of device or form factor, the tendency is to spend a hundred percent of your focus on that one thing. It’s sort of normal, because design and creative work involves focus and removing distractions and not letting people talk to you and stuff like that.
What I’m saying is that you can’t afford to be a hundred percent focused on that thing, you need to be something like 90 percent focused on that thing and take that 10 percent of time and use it to just occasionally say, “Is this going to work over there and over there?”
Peripheral vision is a metaphor, meaning I’m mainly looking at this, but if a baseball comes towards my head this way, I’m going to notice and do something about it. Make sense? Next.
Audience Member: Hi. You talked about being focused on the back end and considering that as part of the experience. I’m very happy to hear you say that. But I was wondering if you could talk a little bit more about some of the techniques you use to make sure that you are designing and thinking about…
Christian: Yeah, one of my techniques was to become a product manager so that I could tell engineers what to do. I’m kidding. I love engineers. Without them, I would never make anything. This could be a whole other conversation. I’ll touch on it as best as I can.
Part of my model of all this stuff is that the UI is on the surface. It’s literally the interface, it’s where things touch each other, that’s what interface means. The UX is not on the surface to me. The UX runs from the core of the planet out to the crust. You can’t change the UX if the database, if the queuing model, if the architecture of the app is a certain way.
You can, you can do surface things, but it gets harder and harder and harder, because you’re basically torturing a model that wasn’t built to do that stuff. Sometimes that happens and then you refactor and you rebuild it.
But what it really comes down to is that I meet once a week with the head of our platform and I talk about the roadmap and I tell him that we’re building out an activity stream and we want to keep track of what everybody does in the whole system. He’s like, “That’s going to be a lot of database fields.” I’m like, “Yes, yes it is.”
We’re building on a graph. There’s going to be people and objects and people are going to have relations to objects and we have to know all that stuff. I can’t give our customers a great UI, a great experience, around that if we’re not keeping track of that data and how it’s related and cashing it well and all these different things.
I’m not an engineer. I can’t tell them how to do it. But I can give them a very good idea of what we need the system to be able to do today, tomorrow, six months from now, a year from now so that they don’t just build incremental little hacks to extend one feature at a time, but they think architecturally.
It also means that the UX designer, in my case I’m a project manager, but whoever is trying to ensure that the UX comes up from inside the system well, has to be somewhat comfortable with technical concepts. How does the system actually worked, and how expensive is it going to be for certain things, and how important is that?
I see it as part of the responsibility of real UX. You can’t just be designing pretty screens and things like that.
Audience Member: Hi. Where I am, there’s a lot of talk about holistic UX or ubiquitous UX. There’s a lot of talk about features parity, and that’s them getting…I actually think they’re getting farther away. But I wonder how you would discuss feature parity within all of yours.
Christian: Feature parity is just one of those things that’s a little bit like a holy grail, or an idealized ideal. In a perfect world, every way to reach your service should enable you to do everything. It’s a little frustrating when you’re on your phone and you’re trying to change your TiVo schedule or whatever, and they’re like, “Go to the website to do this” or something.
On the other hand, you do have to focus on, what are the primary experiences that are most likely to be used on that device, and make sure that those are perfect. In fact, up front, I would recommend burying the long tail of your features a little bit, depending on the interface that you’re building at the moment.
So that yeah, the super motivated person who’s willing to click through, zoom in and do all the stuff can still accomplish the task that they’re trying, but that may be a lower priority. You might not successfully ship that in time, and you don’t want to compromise the critical make-or-break experience on that device in the interest of some sort of principle that you have to have feature parity. Feature parity is an aspirational goal, and you will get criticized.
Users want to do everything. When we worked on the phone version of this app, we started with some hypotheses. We said, “People aren’t going to want to do a lot of editing on their phones, maybe we should just give them preview and reading. They probably won’t make new files very often on their phone, they would just get the ones they already have and look at them.”
We were just totally wrong about all of that stuff. As soon as we started prototyping and playing with it, first of all we saw this would work, then we showed it to people and they said, “Yeah, I guess I would do that.” Then we shipped it and looked at our data, and 30 percent of our sessions someone makes an edit in a file and doesn’t just read it. On tablets, on phones, 30 percent. Same number.
Now, do they edit as much? Probably not, they probably do later editing. That’s another hypothesis that I would have to check. You have assumptions that people aren’t going to need this feature on this device. You have to start somewhere, and assume those things, but you have to check all those assumptions, too. Because based on best available screen, people will do some crazy ass shit to just get stuff done.
Audience Member: You mentioned early on in the presentation, the fact that the way you structure the UI forces you to go back, or iterates a change in the ecology, basically. Now you mentioned the fact that so much of what you do is actually with the UX throughout the process, from the core the surface. The next logical step would be for me to ask you, are you finding yourself at any time in a position that we would usually find ourselves in when working on these logic projects.
Finding yourself in a position to change, impact or modify in any way the business strategy over the product or service. So, do you get to change this?
Christian: Yeah. But again, because I reframed myself as a project manager, and project managers are allowed to talk about business strategy and are involved in that planning. I own the roadmap, so sure.
Audience Member: Do you find yourself in a position where you can define IA the starting point for the change?
Christian: If I can defend it?
Audience Member: Yeah. Use IA as the reason for the changes.
Christian: Yeah. To be honest, I probably don’t sell it or communicate that it is IA while I’m doing it, but yes. To me, I’m not necessarily using the most sophisticated concept of IA. To me it means, I draw maps and diagrams to communicate relationships and ideas, and meaning, and we use it as a common reference point so that the engineer sitting across the table and the biz dev guy, and the marketing person and one of my designers all agree that this is the battlefield, that’s the high ground.
We’re going this way, or we argue about it and go, “I don’t think it’s this, I think it’s this.” To me, the mapping process and the communicating around map like artifacts is the way I am using IA to build out a products strategy, that way. Sure. Yes?
Audience Member: How do you manage the decision about what hardware to support? What are you using to make that decision, what kinds of data, what kinds of conversations are you having? And, have you considered supporting television, large screens?
Christian: Good question. Based on the second part of your question, you mean hardware in the larger sense? Out of the whole world of devices that we might support.
Audience Member: Yeah, future cases.
Christian: Sure. I’d say that the way we do it, again, CloudOn launch, before I joined the company, was an iPad only product. There was business strategy there that said we think that on tablets, people would do “productivity” tasks like editing files and revising them and commenting on them, but there is no good way to do that now. If we give a tool like that, we will get uptake and make a business out of it.
The beginning of that seems to be true. People have liked it and have downloaded it and everything. Then we have a strategy called ubiquity. When I came in, I was asked, “What are some of the things you think we should focus on?”
I said “Well, you don’t have a phone version. I don’t take a nap seriously if I can’t also do it on my phone, so you’ve got to do that.” They’re like, “Are you sure?” I’m like, “No, I don’t know. We’ll check, but I’m pretty sure.” But then which kind of phone? We were in iOS, we were clearly going to support iPhones. We had come out on Android tablets, so Android phones were likely to follow, which they did.
But then the question is which ones? Do you support the Nexus 7, do you support the Asus whatever, do you support the Google blah-blah? There’s an infinite list of them.
At first, with the Android store, we were whitelisting them. Because we didn’t want somebody to run in on a device and find out it didn’t work, but more and more come out all the time, and you fall behind on whitelisting them, and people are unable to download it who might want it. So we flipped the other way around, and now we let anybody bring it up, then if we get crashes or bug reports we might blacklist of the device so that people can’t use them.
That’s just in that one area of Android, which is itself a big, big space. We haven’t actually thought seriously yet about the 10-foot interface, the large TV screen. There’s some potential there eventually, for people who want to work and see their work, maybe type on the tablet and see something, see the content up on the screen.
I don’t think it’s out of bounds for us, but we haven’t seriously grappled with that. We definitely look at our data. The other part of our question is, when do you stop supporting a device?
Because often, at a certain point the OS has advanced and earlier versions of the hardware don’t support the new OS. You have to refactor your code to run well on that or take advantage of new features, so you have to make these tough decisions at some point of are we going to deprecate or stop supporting a device that were used to support? When we do that, we definitely look at the data.
We are about to drop support for iOS 6 with our late April launch. Right now, only 2.5 percent of our customers are using that, and it’s trending downwards. We think in another month it will be even smaller.
Our head of growth also looked to see, but was there growth potential in that iOS 6 and the devices that still run it? Because outside the US, there tends to be a ripple effect and people tend to be on older hardware and older OSes and things like that. But he did some research and saw it’s not growing worldwide, either.
Really, people are shifting over. People don’t upgrade their OSes as quickly on Android as they tend to on the iOS side, but we do try to make data based, or data informed decisions about what hardware to support, what operating systems to support. There’s probably more that can be said about that, but that’s about what I have to say. Yeah, sure.
Audience Member: Follow-up question on that, how important is it to launch simultaneously on different OSes and different devices, versus staggering a release.
Christian: That’s a great question. We almost killed ourselves trying to launch simultaneously across many different platforms at once. It was becoming really hard, because for one thing, that makes so many more blockers. One thing’s ready to go, but the other one isn’t, so you hold the first one back. That doesn’t really make sense. The other thing is that you then have to do all of your development in parallel, so we had iOS client engineers and Android client engineers solving the same logical problems in parallel, and then executing them in their own code bases differently because you have to do that because the layout models are different and things like that.
Clearly at some point, we realized that you have to stagger it. You have to push features out on one of our device platforms or OS platforms, and have all the generic hard work of figuring out the logic of how to implement it. Currently, we ship on iOS first. Typically we do, and there’s more to that. So then, when the Android team is working out the same feature, they meet with the iOS team and go “Well, where were the bodies buried? What was hard here, what did you figure out, are there any tips and tricks?”
So they move a little bit faster, and that helps. The staggering seems to be the best way for us to do it. It also helps, for instance, we used to load up our QA people with everything all at once, and two weeks later they would be doing nothing. If you stagger it, they can be doing a week or two checking the iOS release, and then the next week or two checking the Android release, and then we’re back to another stint on iOS.
That rolling process is another thing that works well for us, also.
One thing is that we been doing this redesign. I hate redesigns, because they stop everything. It is like we constipated the whole product, because nothing can change until this redesign is finished. We started it last fall, so I’m killing myself here. Right now, we’re not shipping any iOS updates until this design is finished.
Right now, we’ve made Android the leading platform for the moment, because you can drop stuff in the store anytime you want. You can make one little change, embed a tracking API or something like that, ship it again, fix a bug, ship it again, tweak the login screen to see if you can get more people to complete, ship it again.
In that way, Android is currently our leading platform. Actually when our web browsing platform matures enough, which it isn’t yet, probably that’s the place where we’ll pioneer new features because the web is the web, you can ship anytime you want.
So, that’s how we think about that. I think that may have been the last question. I’m sorry, we’re out of time. I am here all week, though. I’m here all weekend, so if you have other questions that you didn’t get to ask, then just come find me outside.