Prototyping for Hosts

Design is a process of trial and error. To find something that really works, you have to try many solutions that flat-out don’t. Over the years, I’ve come to rely on prototyping as an effective method for testing design solutions. I’ve also found that prototypes are great for storytelling. They can reveal how you want the world to be, and act as a north star for the whole team. For these reasons, when we set out to redesign the mobile experience for hosts, I knew prototyping would be more essential than ever to my process.

Our research and development plan spanned months. A key component was regular, often weekly, research sessions with hosts. In the early stages, we would use these sessions to generate ideas and set broad direction. Later, we would use them to refine and test usability.

To put this plan into action, we were going to need a prototype, or more accurately, many prototypes. They would need to be easy to create and update, as our sessions were often only a week apart. They would also need to be robust and perform well on a mobile device, as we wanted our hosts to really believe them.

Choosing a tool

We’re in a Cambrian explosion of prototyping tools. A new tool seems to emerge each week. I think collectively, the Airbnb design team has probably tried all of them. Two of my favorites are Framer and Flinto, but for this task I wasn’t confident that either was the perfect fit.

As it happens, I had just completed a Codepath course that teaches designers the basics of iOS development using Swift and Xcode. I was keen to put my new skills to good use and thought that this might be a perfect way to create the large-scale, robust, mobile prototype that we needed. Luckily, the other designer on my team had also completed the course and was eager to practice his skills too.

Collaboration

Managing large prototypes is difficult. Most design prototyping tools out there today are not designed for creating large-scale app experiences, and few support proper version control. Using Xcode allowed us to rely on Git for version control of the project. This meant that we could both work on the same project simultaneously or asynchronously with little coordination.

This was the first time I’d used Git for a project of this complexity so it wasn’t without hiccups. Resolving merge conflicts was sometimes confusing and had unintended consequences, but we got used to it eventually. You can avoid a lot of issues by using branches correctly and preemptively checking that other contributors have pushed their latest work to the server.  

Distribution

As with many prototype projects, one of our goals was to build awareness and excitement about the project within the immediate team and among company leaders. To do that, we needed to be able to easily distribute and update the prototype. This isn’t easy with many of the design prototyping tools out there today. Often a special viewing app needs to be installed or a link needs to be distributed and accessed each time.

By using Xcode, our prototype was a real app. No special viewing app was required. At first, we exported the app on our own machines as a test app, and then distributed it over email. As we started distributing it more widely among the team, we quickly ran up against Apple’s hundred-device limit for test apps.

A good designer should know their materials intimately. By using the tools that engineers use when building apps, you can become more familiar with the constraints and opportunities available to you.

To get around this, we worked with an iOS engineer to hook our Github repository to the build server that our engineers use for our production iOS app. This meant that every time we made a change to the prototype, the build server would generate a fresh build of the app. Switching to the build server meant our prototype app was now considered an enterprise app and was no longer subject to Apple’s hundred-device limit. This change also allowed us to automatically publish our prototype to Hockey, the tool we use to distribute our alpha and beta apps internally.

Fidelity

Having a prototype that’s actually a real app isn’t just useful for distribution. By using Xcode and Swift, you get a lot of other benefits with little coding required. You can easily add an app icon and startup screen. You can use default push and modal animations that perform just like the real thing, because they are the real things. You can set up your text fields to summon the right type of keyboard. With more coding experience, you can implement swipe, pan, and edge gestures, custom transitions, and use device sensors.

Since the prototype was an app, it also performed like an app. Many other prototyping tools rely on some sort of web view to run on a phone, which causes performance issues as their scale increases. Ours was stable and fast.  All of this helps your prototype be more believable. This makes it easier to get feedback from users, buy-in from executives, and excitement from your team.

Progression & scale

The performance issues seen in many prototyping tools are not only restricted to the viewing experience. Often the building tools are not optimized for larger-scale projects either. Code becomes long and complex, and noodles become spaghetti monsters.

Xcode is designed for making real apps that are often large and complex. The behavior of each screen is defined in a separate file, so each can be short and simple. I did find that the storyboard became slow to refresh as the project’s scale increased, but you can avoid this by splitting the project across multiple storyboards.  

The other great thing about using Xcode was that we were able to build the prototype progressively over a number of months. I started by quickly dropping in static images of each tab and setting up the framework. We could then individually work on building out our respective sections, only doing as much as was necessary to reach the next goal. We started with the messaging and calendar screens, and later moved on to stats and listings areas. We were also able to progressively replace static images, first with scrolling views, and later with more complex sliced assets or even native elements.

This progressive approach could ultimately result in a prototype becoming a production app. In that case, the prototype would not be a throwaway artifact of the design process but an integral part of the development workflow. We didn’t try this in our case. The scale of the Airbnb product and the fact that we were not going to be building from scratch would have made this unfeasible, but it may be worth trying for smaller projects.

Understanding

I think a good designer should know their materials intimately. By using the tools that engineers use when building apps, you can become more familiar with the constraints and opportunities available to you as a designer. I don’t think that product designers have to code, but they have to be willing to get stuck in and really understand the materials they use to design. By using Xcode, I became closer than I ever was before to these materials and I think it has made me a better designer in the process.

Xcode and Swift may not be the right tools for every prototyping project. There is a learning curve for designers unfamiliar with code. But given the benefits I’ve outlined here, I think it’s worth considering for your next large-scale mobile project. We were able to progressively build a large-scale prototype that felt like a real app. That robust prototype allowed us to get helpful feedback from our hosts throughout the process. And, in the end, this all led to better design solutions.