21-month-startup-journey: How we designed a UX that impressed

LESSONS LEARNED

21-month-startup-journey: How we designed a UX that impressed

The gradual process of turning a prototype into a beautiful app

Feb 21 ·22min read

As our service matured, UX became more and more important to us. We decided to take ownership of the user experience from first point of contact until repeated usage to make our users feel right at home in our app. Although we ended up changing directions, we were still able to impress our users with our design and overall experience.

I aim to give you detailed insights into how I approached our design challenges from version zero up to our latest release and will dive into some psychological design principles, theoretic concepts, and why they worked (or why they did not work) , too. Before we jump into this extensive survey on our design process though, lets have a look at the final result:

The app-part of our UX for Blisspoint Lunch users

The Goal

Before I started implementing the app, I had this simple idea to build a product that brings people closer together. So I set up the first goal that would lead to this outcome: Any user should use the app at least once per day to set up an appointment for lunch.

I read several books on habit loops, how to create them, how to build experiences that “hook” users, and how to get users to use a product more frequently. Some of the books I can recommend are Hooked , The Power of Habit , Contagious , and the Mental Notes .

Later I focused more on building a community, defining a culture and communicating our core vision (as taught by Seth Godin ) within a well structured app interface. But for now, let’s focus on the first attempt.

Who is it for?

After acquiring enough background knowledge, I started to define the target group. Being a student myself when I started the project and knowing the daily struggle to find cheap lunch, I decided to tailor this app to the needs of students. Essentially, we have two needs:

  • A student has not much money and wants to eat lunch as cheap as possible. A student thus needs a selection of cheap lunch offers.
  • A student usually wants to have lunch with her friends, so she needs to know where her friends want to go and when they meet. A student thus needs a way to communicate with medium sized groups to set up appointments.

Students who don’t have lunch or bring lunch from home were not part of the target group. Same for students who meet every day at the same time, same location with same people. They don’t need our product. But the student groups who are spread across the campus during lecture time and gather for lunch as well as the ones searching for some cheap variations for lunch may find our service useful.

Targeting on students also makes marketing a bit more straight forward: We know where they spend most of their day, how they talk, which other products they use and how we can reach them. Also, we can estimate which content will be appreciated and focus on valuable information for that target group. This means, sizing down the target group reduces our overall scope of content und functionality, clarifies which content we have to include, how we should shape our interface, and helps us to find out how we can get new users.

Defining a Theoretic Concept

Drafts of the user journey (user actions, paths and experiences) for V1.0.0

When it comes to user experience, I usually think through the whole interaction from the moment someone hears the first time of our product up to the point where she has become a regular user. I earlier wrote about the two main needs of our users. The necessary features are pretty clear: (1) To be relevant for students, we need to offer cheap lunch and (2) to be useful they need a way to set up appointments. These are two distinct behaviours which I believed I could make work together. I came up with the idea that people open the app to find out what there is for lunch, but stay in the app to set up appointments. I found the idea of habit loops interesting and implemented two habit loops for our product to keep users engaged. As a side note, I think now that it would have been a better choice to just focus on one habit loop and making that one work.

Loop 1

Loop 2

My idea was to drive loop 2 with loop 1. What I did not recognise back then was the fact that loop 1 in fact was not a habit loop but instead a content marketing technique. Even worse, our analytics data showed later that students don’t really care that much for their lunch and most often go to the canteen. Often with the same people over and over again. That removed the need for our product which is why we ultimately failed acquiring this target group. Definitely have a look on my post on building MVP’s to find out how we could have gotten this insight earlier. That would have saved us a lot of time and work :)

Patterns and Psychological Concepts

To make the product even more exclusive for students, I decided to limit app access. I created some invitation cards that contained a code that was necessary to unlock the app. However, once a user had the app, she could invite all of her friends when creating an invitation. The first version I designed was a set of 1000 invitation cards, each of which we packaged in a small paper bag (check out my post on marketing to find out about how well my approaches performed, e.g. conversion rates). The intention was to package our marketing material a bit different from the other stuff that was laying around at our campus. I wanted it to stand out and to tell students that this is different from everything else they got offered before. The bag raises tension. Plus, it looks like a small gift. People feel the need to reciprocate when presented with a gift, so I hoped to increase the conversion rate with these. The second version of these cards were distributed by our restaurant partners and branded with their logo. This made it easier to fit in the restaurant so that our partners could promote their dishes on our platform by handing out our invitation cards to their customers.

Some of the cards branded for out restaurant partners

As mentioned above, I aimed to design the complete user journey from first contact to repeated usage. The invitation cards were the entry point, followed by the App Store page and the installation of the app. In the first version I focused on keeping up the tension/curiosity to drive users through the app.

Printed and packaged in little bags, we distributed the cards on the university campus or through our partner network

Consistency

On the user journey, I tried to ask the user to perform several actions. Thanks to the principle of consistency , users should accept a task because of what they already did in the app. I sorted each action by its “severity”. The final goal was to get the user to share an invitation link with her friends. This is especially tricky if the user is not sure she should recommend our app to others. Her social reputation depends on it and usually people try to avoid spam, so I had to prove that our app was worth the risk. This also meant that a user should be able to understand the value of our app before even signing up. This was a major decision as we had to open up our backend for anonymous users. Feedback later confirmed that users really liked being able to check out the app without an account. Using this approach, we were also able to add users to our customer base and converting them to sign up at a later stage.

Loss aversion

Another principle I included is loss aversion : In the first version, users could create invitations and groups without signing up, but the groups were ultimately lost if they would delete the app or did not create an account. I later required users to create an account first, but eventually reverted the change. In the final version, the user had to provide at least an (anonymous) user name so that his friends could recognise him.

Priming

Priming was another technique I used. I added pictures and graphics of happy people, lunch, and gatherings. I later dropped this technique because I ended up mixing different UI styles. The final app version was completely based on graphics and icons, no images anymore. I used the humaaans library for these graphics. The reason I did this is that people feel attracted to other human beings and nature. By integrating these graphics in the app I was able to address users more directly. It is just nicer when a human shows you something instead of displaying a simple manual.

I used the metaphor of a letter to resemble invitations

Visual imagery

Visual imagery became increasingly important for me to communicate information. Users should not have to read, and especially when setting up an appointment this is kind of a challenge. Usually, you would use a chat to make up an appointment. By using icons and the right kind of layout, I was able to reduce text to a minimum and convey users the meaning of all those chat messages within a blink. The first app versions lacked most of this, though. Telling users what an appointment actually is was the next challenge. In the first versions you can see that I used some kind of straight forward interface of a big card with all the information. Though, it seemed a bit unintuitive. In later versions, I used a letter in an envelope to represent the invitation. That made it easier to link the concept to real world experiences. However, some users also linked it to their mail account (their mail program uses letters, too) which was kind of a downer…

Affect heuristics

Affect heuristics were something that I tried to include from the first version on, but I actually succeeded not earlier that V1.2.0. I tested the onboarding process that I designed and found that it pretty well succeeded in spiking the user’s feelings.

By creating a story that involved the feelings of the user, I was able to get users to have a positive opinion on the overall app, even before they explored it!

That helped a lot to keep the user engaged when using the app the first time. On the downside, I also found out that this effect only lasted for the first one or two times the app was used. Once users realised the app did not really address their needs they dropped out (as I stated above).

Authority

When guiding the user through the app, I payed attention to give her some kind of authority that told her what to do next. In the first versions, there was not really something the user could choose. I designed a process that each user had to complete on the first app start. That turned some users down. I learned that each user responds different to clues, and most often they want to explore the app in their own pace. So I later removed most of the authoritative guides and just hid more or less subtle hints in the UI (like some red dots where a user should tap next, or some animation, or a tool hint).

Chunking

Chunking is another thing I found useful: The first versions had one information per screen. The problem was that this led to long texts that noone red. So instead, I divided the information into smaller chunks and either showed single chunks on subsequent screens or hid the chunks all over the UI. This led to a much better information transfer und users finally read most of the information.

Sequencing

Just like chunking, I used sequencing to break down complex tasks into smaller subtasks. Creating an invitation is the most complex action you can take on our app. The first version asked users to fill in all the details at once which did turn off many users. We changed that later so that a user would just create a new invitation and then set up time an location within the chat. However, we encountered the problem that users were surprised by this usage flow and expected to be able to complete all the details before sending the invitation to their friends. This again turned users off. In our final version, we chained the invitation creation steps in a sequence: Who? When? Where? Each step could then be skipped or users could fill in the information. This left users with a greater sense of control and met their expectations without overtaxing them. We could verify this during our field tests.

Status quo bias

What did not work so well was fighting the status quo bias: Users still used WhatsApp to set up appointments. We already saw that coming and tried to offer users to share invitation links on WhatsApp, but this issue was so bad that we observed our friends share a link on WhatsApp and then even discuss the appointment in their WhatsApp group instead of in our app. That means, all had access to the app and looked into the appointment, found out about the time and location, but still used WhatsApp for discussion!

Status

Also, conveying a clear sense of status did not work. First, we thought users would get higher status just by having access to the information where they can have cheap lunch. Another status symbol would be the number of invitations a user was invited to and number of friends linked to her account. But all that proved wrong and people did not really care. Also worth mentioning is the fact that we did not make these metrics public, so people had no way to compare their status to others. Maybe that’s what we were missing. Anyway, we refused to play the status game while we could not even provide a product that covers the user’s real needs. We wanted to focus more on building a useful product instead of manipulating users with growth hacks.

Periodic events to form habits

We hoped to create periodic events, too. Ideally, some users would set up appointments periodically and bring their friends back into the app. This failed in two ways: Firstly, there were very few users who actually created periodic invitations. Secondly, after two or three appointments, a severe amount of users would just ignore any notifications and fall back to WhatsApp. They were not comfortable using our app (or we did not provide enough value to justify to switch from their favourite messaging app to ours).

I also missed out on including user interfaces which targeted the user’s emotion (the app always was kind of too “clean”), showing usage publicly, and integrating stories other than during the onboarding. Spreading the app should actually be supported by practical value and social proof. As we did not provide the former, the latter never happened and users seldom invited their friends through an invitation link.

Our logos, before and after retargeting

Naming

Our name played also an important role. Focusing on students, we called the app “Studentenfutter”. In Germany, that is something many students eat while learning (nuts and raisins). That also means the app has to be free because students don’t pay (much) money for nearly anything. As a logo, we used a salt and pepper grinder icon labeled “S” and “F”. Later we named ourselves “Blisspoint Lunch”. This removed the students from the name and allowed us to target employees and people aged 25 to 55. Linked to this change, we would also pay attention to include offers more relevant to the new target group. Price, location and quality were some of the key aspects that justified partnering with new restaurants.

Feature selection and layout

Now that I defined our concept, I had to select which features get implemented and how they are organised in the navigation hierarchy. As we want people to find lunch and set up appointments fast, these two became the two main screens. One screen is all about lunch, one screen all about invitations. On each screen, I emphasised one action as the app grew more mature. In earlier versions, users found it kind of tedious to find what they wanted.

I wanted to keep navigation hierarchy as flat as possible. This led to a depth of maximum three levels.

The hierarchy I ended up with for the latest release

Main level:Overview

First level:Details of invitation / food category

Second level:More options, even more information (that usually is not really asked for).

I then decided on the importance of a feature and classified it as “important for usability” or “important for app growth”. I then placed these features according to their priority on a certain navigation level and found a proper place for them. The more important, the easier it had to be reachable. After several sketches and paper prototypes, I ended up with the layout shown below in V1.0.0. I later improved the layout according to our user test results and new learnings and got the layout seen above.

The app

Raw features V0.0.1

I started by implementing the raw features. At that point, I did not focus much on design. I just had this idea in my head and tried to create a UI that was “good enough”. I didn’t think much about user experience at that point. Several features were not working that good and were even impractical, but I guess for a first prototype it was alright. Users could look for food and create groups. These groups could then be invited for lunch. No chat, no filters, no search function, basic error handling.

I realized that noone found the button to actually create a new invitation. So I put it somewhere where it is seen most of the time before releasing this version to our alpha testers.

Checking back with users

Turns out that it’s apparently cooler when you can invite multiple gorups at once. So I added that to the invitation creation. Also, the invitation creation process was not so clear before, so I added a dialog through which a new invitation can be created. According to our early adopters, a chat seems to be also useful, although I did not implement it in version 1.0.0.

To encourage users to invite their friends into a group, I now also offer to invite friends into the group right after creating it.

Also, I decided on a fixed color theme (orange and green).

Building version 1.0.0

All together, I published Version 1.0.0:

Our UI in version 1.0.0

Elaborating on usability

The first public version had several flaws: First of all, putting groups and invitations on the same screen was confusing and too much information at once for a lot of users. Invitation items were not perceived to be actually clickable and lacked a clear overview of what’s going on in the invitation. The navigation was confusing and inconsistent. That led to a bad understanding of the app functionality. Last but not least, users should be able to change time and location of an invitation.

Version 1.1.0

I updated the UI according to the feedback and added another menu for managing groups.

Still, the groups feature disturbed the other menu points, and so I decided to hide it on the bottom as it is a pretty unpopular feature (users create more invitations than groups). As I could observe during more tests, a chat now became increasingly important. I included one which integrated all time and location suggestions right into the chat messages. The need to create a new suggestion is also something I found during testing: People sometimes just want to discuss the options rather than having someone dictating where and when to meet. This is something that was not possible before, and is not seen so much in other apps.

I also was not satisfied with the overall look of the app, so I added new fonts and made UI elements stand out (e.g. the location and time suggestion messages in the chat or the animated letter). I decided to redesign the invitations list once again and used the metaphor of an invitation letter. As I did not expect users to have more than a hand full of invitations at the same time, I decided to display the invitations in a view pager instead of a list. In the end, version 1.1.X was published like this:

Our UI with version 1.1.X after some redesigns

Issues: Users have a bad overview within the chat, it’s hard to understand how to add more friends to an invitation, it’s not clear where all current invitations can be found, and some users found it hard to understand how to create a new invitation. We also lacked a proper onboarding process that I should now implement.

Redefining the concept

The first few versions gave us a lot of insights. I decided to redefine the UX with the found learnings, together with some more stuff I read in other books like Tribes , This Is Marketing and Permission Marketing . By the way, I really like Seth Godin’s approaches and tried to incorporate more of his teachings (he heavily influenced and inspired me through his books and the decision to overhaul the app was probably triggered by his books). These learnings also inspired a lot of the marketing materials and pitches I gave to potential partners.

Paper prototype for the new concept (with edits of test results) (I love paper)
I set out to create a culture that valued personal connections more than chats. So, meeting each other actually counts more than just chatting. Based on this thought, I redefined the app goal: Our app should be used for any privately organised appointment. I kept the lunch appointments as an entry point, but made the appointments feature more generic so that it could be used for generic appointments.

Note: I think this was the wrong step and I probably should have doubled down on lunch appointments. After enough people met for lunch through our app, I could have extended the functionality more easily. The way I did it, the app was not “the” app for lunch, but instead became just one more app “for any meeting”. This was too broad, I guess.

Linked to the definition of our culture, I looked into who actually was part of it, what status symbols there were, which status symbols users had to drop, who was influencing others to become part of that culture. I thought about what I actually deliver, what it makes our users feel and what they can reach with our app. I poured all of these findings into the app redesign. Most important for the communication was our advertisement and onboarding process, but the new concept also helped in reshaping my user interfaces. I also elaborated with my co-founder Steffen on new ideas which would reshape the look and feel of our app. Together, we challenged each other to come up with even better approaches that we finally implemented together. At this stage, we also defined our final corporate identity and general appearance.

We also looked into failed or successful apps, tried to classify competitors in our market and found out which steps to take to stand out against them. Analysing working UI concepts helped us to find a better layout system. We drew a lot of inspiration from Snapchat’s ideas as Snapchat and our app are somewhat similar, just for other use cases and target groups. We got ourselves a broader overview by looking at successful apps and found out which interfaces work best in which scenario. Based on these learnings we redesigned many features of Studentenfutter.

Sketching the different paths a user can take during the onboarding

Onboarding

When people downloaded our app, we initially did a bad job in explaining our vision and telling them why we built the app. Basically, users always told us that they could use our app to find cheap lunch. Some of them even recognized that they could use it to set up lunch appointments. But none of them considered the app as a possibility to spend more time with friends. Our vision was to bring people closer together by giving them tools to set up appointments spontaneously, fast, and with multiple groups and people at once. None of this was understood by our users, so I elaborated on a better onboarding. I now focused even more on the experience rather than the raw design . I outlined different journeys for users depending on how they open the app the first time:

Case 1: User opens the app first time without any invitation link.

In this case, the user needs an unlock code (note that in the meantime, I removed this step again as it performed very poorly) . That code is provided through one of our partners: When the customer pays for her lunch, she is asked if she wants to find out lunch offers for the next days through our app and receives an app invitation card, if so. We also distributed some cards on our university campus. The main intent is probably to check out lunch dishes and figure out how this app works, so the first thing we do is to give our new user an impressive tour through the app. The goal is to get the user to share an invitation link with her friends.

Case 2: User opens the app first time with an invitation link.

This means the new user should be enabled to join her friends as fast as possible. We take the user straight to the invitation where she is able to see her friends and join the conversation. In this case, the goal is to make the new user feel right at home — by showing her that all her friends are already there, we have a huge plus. Ideally she participates in the invitation which will trigger some push notification. That notification will bring her friends back into the app. However, the challenge is to get the user to sign up in order to join the appointment. That means we have to increase tension and trust to a certain level that will allow us to pull the user over the resistance to create an account (this is an important step of our funnel). We do this by lowering the requirements and by showing enough context information:

Jonathan invited you for lunch with three others. Choose a username to join him now!

This text is displayed above the name input field. The only requirement is the username. Tension is built by having her friend, “Jonathan”, wait for an answer on the other side. Would be kind of rude to not answer him, right? In addition, we build trust by showing off some of our app vision right before asking the user to sign up here. Plus, the seamless experience certainly helps to make a solid impression. Trust is further leveraged by using the real name of her friend. This reflects once again that “Jonathan and three others” are already using our app, so they probably trust the app already.

Case 3: User opens the app first time with an invitation to a group and the group is not organising an appointment

This is tricky, because the user never heard of our app and does is unfamilar with our concept of lunch invitations and groups. So the user journey has to differ slightly. We have to make clear that the user joins a group and can then start an invitation with that group. To do that, we tweak the user journey to include some explanatory one-liner and redirect the user straight to the group. Like in case 2, she can immediately see her friends and is offered to either invite them for lunch or to explore the app.

Jonathan invited you to the group “FriendsLunch”. Choose a username to join the group and meet for lunch!

The call to action is now slightly different. Again using the same techniques to build trust and tension, but reflecting that the user is added to a group.

Case 4: User opens the app first time with an invitation to a group and the group is organising an appointment

This case is even more complex, but easier to explain: We redirect the user to a screen where she, again, is added to the group just like we did in case 3. However, this time we then redirect her to another screen showing this:

Hooray! Your group “FriendsLunch” is already organising an appointment. Let’s check it out!

This serves both as explanatory text to the user and as a redirection to prepare the user for the invitation. Remember, users have to always be able to guess what will happen next, so there is some work needed to prepare the user that she is now joining a conversation.

As you can see, I handled all of these cases slightly differently by implementing deep links (aka dynamic links) that gave me enough context information to choose the proper way to introduce the app to the new user.

I also tried different attempts for explaining app features, adding tool boxes right within the UI context worked best, though. The onboarding, tutorial and new UIs were tested with several volunteers. In any way, the user journey had to be adjusted to the way the app was opened the first time to avoid irritation, enhance understanding and improve conversion.

One of the UI/UX testing sessions we participated in

Repeating feedback

As always, we ran a user test with the new release with impressive results: Each tester mentioned one of the following three issues: Groups and invitations are hard to distinguish, voting for a time and a location should be one atomic action and signing up with the phone number is very uncool. So we ended up with three points that we could fix in the next release.

Phone numbers were dropped and replaced with unique user names (as explained above, this also eased the onboarding process because now we only have to ask for one non-sensitive information: The username). The thumbs-up reaction on a suggestion was linked to both time and location, so users were not required anymore to vote for both with two separate reactions. And finally, the distinction between groups and invitations was made more clear by explicitly listing groups apart from the invitations and tweaking the onboarding as well as the first voting/group creations.

Version 1.3.0

Version 1.3.0 is the final release and also showcased at the top of this page:

The app-part of our UX for Blisspoint Lunch users

The last thing I did was to remove the invitation code (requiring codes just was a bad idea I guess). However, after all these developments, our analytics tool still showed us that users were dropping out shortly after launching the app for the first time, so we could not make it to achieve PMF, although we had a nice design and everything. As our research showed, the problem we were solving just was not severe enough and I guess, a nice setup does not compensate for actually solving a problem. This led us to reposition ourselves now as “Blisspoint Lunch” with a new target group and a different focus.

I believe exchange of experiences and learnings is crucial for creative makers. Thus, I want to share what I learned during the last 21 months of building my startup. Please see below for more lessons learned or follow me to never miss a story:

Next: How we beautifully failed marketing (coming soon)

Previous: The tricky part of building a team

If you are interested in a rather high level view on UX design principles you can learn about them in this story here .

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章