Philipp Steinacher

Interaction Designer and Developer

Building an

App to trust.

Revue is a diary app for iPhone that captures important life events by itself and encourages people to extend it with their own memories.

Background

Keeping a diary up to date is a burden a lot of people. It needs a lot of attention and a good habit to keep it alive. At the same time a great place to remember and relive notable moments of the past. With our app „Revue“ we are trying to investigate the cause and how to counteract by giving users small incentives to enrich a diary that writes itself mostly automatically.

With Revue we challenged ourselves to create an app that communicates the intimate feeling of a diary with the power of automation, allowing the user to focus on the task that’s more fun to most of the people — consuming their memories.

Therefore the app came with two main challenges for us: On one side the design is the design challenge. How do we create an app that is fun to use to browse content and feels secure and authentic, since it houses private and sensitive data. And on the other side, closely tied to that, the technical challenge: How do we pick the important bits from a never ending stream of digital information about your life.

Process

We started to work on Revue by defining what kind of data is needed to create a basic frame work of information about important events of the day. In a matter of a few hours we build a small, unpolished prototype that started to collect location data so that later on we could make design decisions on real data and not on our assumption about what a „regular day“ looks like.

From the beginning on we had big discussions on how to create a save and trusted environment where users feel confident to record some of their most sensitive information. Therefore we challenged ourselves to create a guideline on how we deal with data and how communicate that with our users.

Badge

Transparency

We commit ourselves to communicate clearly what happens with collected data points. It’s important to give direct user feedback about what data we are processing to create trust in an App that relies heavily on private data.

Cloud Thunder Storm

Offline First

To avoid potential data leaks and minimize an attack vector, we’re never saving any data in the cloud and try to find necessary data points on the device before we check our servers (e.g. data about venues).

Tresor

Software Security

The lowest software should make sure that all data is encrypted securely on the phone itself and requests to external data sources should be as anonymized as possible. Every request should be evaluated carefully before it’s implemented.

On-boarding

This framework has implications on design as well as implementation details. We agreed that we have to be very clear about those principles from early on when people start using the app. We started to explore different options and ways to convey our message during a classic on-boarding process.

We created different variations of a classic on-boarding flow as it’s known from other apps, that present information about data usage and then ask the users about permission. After getting some feedback that this is obviously better than blindly asking for permission to data points, it wasn’t enough to allow our users to make an educated decision. Therefore we tried something radically different that allowed us to engage the users much more and make them more confident about what is happening with the data by giving them direct feedback and examples.

The new iteration of the on-boarding flow is a tutorial on how to use the app itself while introducing the user to new data points that we’d like to use and asking for their permission.

Therefore, the first touch point with the app is the user writing his first diary entry together with the app, complementing each other. Hence, we allow the users to gain trust in the app mechanics while learning that he or she has still full control over all the details.

Story baseed on-boarding: Name text entry Story baseed on-boarding: Addressbook confirmation Story baseed on-boarding: Location confirmation Story baseed on-boarding: Revert Decisions

Text Entry

The on-boarding process starts to write the first diary entry together with the user. During the process the app asks for information that is needed to enhance the automatic diary features.

Privacy Requests

During the story based on-boarding the app requests access to different data points on the phone. The user can learn more about the usage of the resources by tapping on the annotated text.

Instant Feedback

To let the user understand for what we need the data, an example is directly included into the ongoing story.

Full Control

While the app allows the users to deny or revoke access to sensitive at all times. If the access to one data source is essential but denied, the story will follow up on why it is important to grant access and how the app will effected if it doesn't know about the data.

Story Flow

We had two main goals while designing the main screen of Revue that allows people to browse days and events. Number one: let the content define the experience — The Pictures, Places and Memories of the stories should heavily define how the app looks and feels to the user. Therefore, we wanted to make sure to make every screen rich of user generated content and use as few interface elements as possible. Secondly we wanted to make sure that it is easy and fun to browse between different days and events. Hence we came up with a fluid grid that allows you to scroll vertically to switch the day and horizontally to switch between events and encapsulated media.

First Prototype

When we finished our first touches on the information architecture and general interaction design patterns for the app, we started to implement a first rough prototype of our design. We focused on the broad user flow and decided to not spend much time on optimizations in the first place to allow to make quick decisions and iterations on some of the details.

Therefore, we were able to make first usability tests with potential users. They quickly understood how to navigate between days and events. Additionally they reported that they really enjoyed the navigation and liked the concept.

Days and Moments

With the knowledge and feedback that we obtained with our first rudimental prototype we kept designing and refining the different screens. We came up with a holistic design approach that has fluid interactions and transitions to stay true to our design goals.

Revue Day Overview Screen Revue Event Screen Revue Event Actions Screen Revue Event Editing Screen Revue Location Edit Screen Revue Friend Edit Screen Revue Event Story Screen

Day Overview

The day overview lets users scroll vertically through several days and month of memories. The Apps always highlights the most outstanding event of that day based on a number of factors, such as uniqueness, number of social media posts and attendance of friends.

Event Detail

Selecting on day, leads to the highlighted event of the day and allows the user to see more events and pictures of one event by scrolling on the horizontal axis.

Event Context Actions

The context menu gives access to fundamental editing options or let's the user highlight a particular event.

Event Editing

In the edit view, the user can change the location and add or remove friends from the event.

Location Edit

The location edit gives a selection of locations around the event, e.g. from the address book or points of interest from Foursquare. Additionally, it allows to create a custom location.

Editing Friends

Users can add or remove friends from the convenient friend picker that has data from the address book and social media sources like Facebook.

Text Entry

Naturally, users can add a custom text diary entry that belongs to a day. He is able to incorporate Facebook or Twitter posts into the text.

Retrospection & Learnings

Working on Revue allowed us to explore a lot of micro interaction and test out how they effect the feeling about an app from person to person. We spend a lot of time implementing details aren’t necessary to ship a product but to make an app feel valuable. That leads to the fact that it took us ages to publish a version that we wanted to test with more people than just individuals.

Generally we’ve been working on to many challenges at one in the beginning instead of focusing on a core feature. So shipping Revue in a reasonable time frame is a tough task and should have focused on shipping a minimal viable product from early on.

Anyway, working on Software that is really supposed to see the light of day, always has a steep learning curve, since you’re tackling challenges that you’ve not solved before. Therefore, such projects are always great fun and rewarding, even though they are exhausting at some times.

Role

I mainly contribute three parts to Revue. I had a heavy influence on the concept and product direction from the start on. That means defining out goals, ambitions and challenges that we wanted to tackle with the App. Secondly I’m working on the Interactions Design of the product, defining user stories and flows, sketching wireframes and designing micro interactions. While Dominic, focuses a lot on the great visual design, I’m responsible for actually implementing the whole app natively in Swift on iOS. That includes security and privacy models, front-end development with UIKit and some Node.js backend services as well as writing tests and providing the continuous integration and deployment infrastructure.

Team