Background
Guidebook makes it possible for anyone to build beautiful mobile apps. Using our builder application, an app can be built without needing to know how to code or design. Our platform is home to many different types of apps for events, places, venues, universities, and organizations. Guidebook’s original mission was to enhance a user’s experience at a complex space such as an event. Since then, one of the resulting benefits was this idea of replacing paper. As more apps are created we continue learn, iterate, and evolve our mission and technology. We’ve learned that users expect more than simply a paper replacement — they want to be engaged, delighted, informed, and connected.
Thinking beyond paper
Just 9 months ago our iOS apps looked significantly different than they do today. When I joined Guidebook last July each app’s home screen consisted of a collection of static icons for navigation. The problems with such a simple landing page were 1) valuable app information was hidden behind icons, and 2) this page was not engaging, inviting, or dynamic. The iOS team was gearing up to move from this tiled home screen navigation to a sliding drawer. This was a huge opportunity to re-invent the most important screen in our app — the very first that users see: the home screen.
Where to begin
Since a majority of our clients were building event apps we decided to narrow our scope by focusing on events. It was clear in addition to providing information about the event, there was an opportunity to engage and connect event-goers (end-users) through the app. At the time, our apps already had ways to connect event-goers. Shared photo albums and one-to-one messaging are just a couple of these features. However, we wanted to create a more engaging social space. After all, events are inherently social — whether you attend alone or with a friend, you will be surrounded by hundreds if not thousands of people.
Research
In order to better understand our users and opportunity space, we set out to gather information from clients (the people who purchase and create the apps using our builder application), end-users/event-goers (the people who use the event app/guide), and competitors (other companies in the market providing a similar service or product).
Talking to clients
We collaborated with our product marketing team in order to gain insights on what clients were expecting from an event app. The team interviewed various clients to gather information relating to their wants, needs, and expectations. The outcome of these interviews revealed clients wanted increased user engagement with the apps they create. Key findings included the importance of a social component to give attendees a voice and the ability to moderate user generated content.
Observations
While we had some great findings from interviews with clients, we also needed to gather insights from end-users. We pulled insights from our experiences at conferences, trade shows, festivals, etc. A common theme from these observations was the event lifecycle. This refers to different parts of an event — before, during, and after. We found that user needs changed depending on where they were in the event lifecycle. For example, before an event a user might be in research mode while after an event they’re more likely to be in reflective mode.
Competitor analysis
We knew that a few of our competitors had an “activity feed” so we decided to evaluate what they were doing in order to see what worked and what didn’t. We found the main feature in each feed was the ability for users to post text and photos for other users to view, like, and comment on. These features matched what our clients were looking for in an event app. A few competitors went a step further and provided ratings and surveys, but that was it. This competitive analysis helped us define strategies that would provide us a distinct advantage in the marketplace and informed us of potential pitfalls to avoid.
Goal
Requirements
High level requirements included the ability for users to create posts and easily access relevant app content at the right time. We knew that smart, sophisticated algorithms were going to be necessary so we set out to discuss the possibilities with our back-end team.
Features and MVP
Numerous teams including product marketing, engineering, and design were involved in the brainstorming process. The result was a list of 31 different feature ideas. We then prioritized the list by importance as it relates to the user experience and level of difficulty to implement. We also classified each feature into buckets corresponding to stages of the event lifecycle — before, during, and after.
Structuring the feed
Our team decided to break elements of the feed into “card types” which we could then display in the feed based on time, relevance, and personalization. Personalization allows for individual users to see their own version of the feed depending on actions they’ve taken within the app (highlighting saved events, etc).
Beta Releases
Beta releases provide valuable design feedback. For this project, we were able to test 2 internal releases.
Tahoe Guidetrip 2016
As a means to test and use our own product, we create apps for each Guidebook sponsored event (Holiday Party, Yosemite Trip, Tahoe Trip, etc). Every February Guidebook plans a company trip to Tahoe. This happened to align nicely with our project timeline. We used this year’s Tahoe app as a testing ground for an internal beta release (see below, left). This beta was kept pretty minimal centering around the ability for users to post text into a feed. The feed was also set as the app’s home page. Additional features included the ability for users to like and comment on posts. That was it. Minimal, but the feedback we received was valuable.
Guidebook’s Weekend Adventure
Our next beta release was a simple weekend app (see above, right). The purpose of this beta was to test new card types that were built and integrated into the feed. We looked for bugs, usability issues, and other ways to improve the feed.
Design Details
Macro
It was important to focus first on the higher level goals and strategy for the product in order to see the big picture. This focus helped us design for scalability and future iterations. Looking at the high level goals also helped us map out a full feature set beyond the MVP and gave us the foresight to avoid potential road blocks and technical constraints. Keeping the bigger picture in mind is a design strategy that helps save time, energy, and resources. As much as we can plan things out, it is always expected that we will discover new opportunities and changes to our plan are inevitable and welcomed along the way.
Micro
Micro interactions are a way to make the app delightful and enjoyable. We explored various micro interactions via prototypes created with Principle.
Measuring Success
Success is an important metric. Our goal is to engage and inform attendees so how will we know if we’ve achieved this? We’re tracking usage metrics and seeing which card types are interacted with the most. If a card type is rarely used then we can focus on figuring out why and try to make it better — or remove it all together. Beside looking at metrics we will continue to talk and interview our clients and users. Continuing this communication will be key as our product and technology evolves.
Looking forward
Our MVP barely scratches the surface of what’s to come. We’re excited to iterate and improve upon this new feature. There are a number of new card types currently in development and we look forward to receiving feedback so we can provide the best event app possible.
Appendix
Android
You’ve probably noticed that, so far, we’ve only discussed iOS. We’re happy to let you know that Interact is also available for Android users and was designed using Google’s Material Design Guidelines.
iPad
