Swublr
Product design for a new app that makes it easier to plan activities with friends
Role
Project leader, UX designer, Business analyst
Team
Johan Sveide
Duration
1 Month
Summary
Swublr is a product I've created to address a common problem: the hassle of coordinating plans with friends through messaging apps.
While messaging is convenient for quick check-ins, managing multiple booking processes across different platforms can be overwhelming. It can take a long time to finalize plans, and keeping track of everything requires a lot of mental effort.
I realized there was a need for a simpler, more streamlined way to schedule meet-ups. By reducing the complexity involved, Swublr aims to encourage people to connect more often and spend less time on screens.
Discovery
I created a fictional company with the goal of getting people to meet up more often. First, I prioritized to understand the business goals, set out a budget and map out assumptions.
Business goals
The company's goal, or "why," is to encourage people to engage in activities together. A common problem arising from using messaging and social media for planning activities is:
Managing multiple booking processes across different platforms can be overwhelming.
Keeping track of everything requires significant mental effort.
With a budget for one month, I developed a strategy and work plan.
UX Strategy
Since the product is completely new, as is the company, I chose to start with discovery research and gather the necessary data to later answer the following questions.
Which of my assumptions do I need to validate and how should these be prioritized
How do people book activities privately today
What tools are used and what is the user experience and attitudes towards these?
Can I find opportunities that other services have missed
Do the target groups need another app? What needs should the app meet if so.
Before talking to the target users, I wanted to get an idea of what services are available on the market that solve similar needs. After identifying 5 potential tools, I analyzed them through SWOT to primarily find opportunities that I assume these services have missed, business opportunities for our app if the assumptions are correct.
SWOT
There were surprisingly few services that, like a calendar, facilitate the booking of meetings. Most, such as Calendly, are more focused on B2B audiences. These easily become complex as there are a large number of needs that need to be met. The calendar app, on the other hand, doesn't solve enough needs for it to be worth using every time meetings are planned with friends. One insight from the analysis is that there is a lack of a middle ground, a service that meets a few more needs than the calendar app but with less complexity than B2B services like Calendly. A feature that calendar services don't solve today is helping users decide what they want to do, that has to be solved through conversations today.
Interviews
By talking to users, I found that they do use messaging apps often to book meetings. At the same time they don't really seem to mind booking meetings over messages. However, they seem to think it can be cumbersome, that it's often easier to call. If they are to stop booking meetings over messages, Swublr needs to be much better to convert and earn the trust of the majority.
Define
From the discovery research, I learned that there is a business opportunity for needs somewhere in the middle between too complex services with many features and the calendar app. And that there are several needs that messaging apps meet today that the calendar cannot meet.
To convert users to our service, our service needs to meet more of the users' needs than conversations over messaging do.
My priority became to first define which needs the target groups can only solve through conversations. Insights from the discovery research data, such as the interviews, formed the basis for two defined user types "adult parents" and "teenagers" with slightly different needs. These user archetypes cover all four target groups.
Through a workshop and with previous insights as a basis, problem statements and a backlog with corresponding user stories were defined. These became the app's specification. In retrospect, I would have instead chosen to create a user journey instead, to better understand when pain points occur during the booking process.
The Challenge
Something most user types have in common is that they often use either messaging apps or social media to book meetings with friends. At the same time, several prefer to call instead for one-on-one meetings. Services like Facebook are preferred in some cases for larger group activities with many invitees when there is a fixed date. There are several problems with using messaging services, here are the overall problem statements and user stories that apply to both user types and were therefore chosen to be prioritized.
Problem statements
Users experience that it can be difficult to find a time when all parties are free, which leads to the meeting not happening
Users experience that it can be difficult to find an activity that both want to do, which can lead to a longer conversation that risks petering out
User Stories
As a sender of an invitation, I want to suggest several times so that the recipient can find a time that suits them
As a recipient, I want to be able to respond to an invitation with a new suggestion for a time if I am booked on the selected date
As a user, I want to get suggestions for activities that suit the selected date to make it easier to find something to do
As a user, I want to be able to share my contact quickly at meetings,to increase the chance that it will happen
As a user, I want to be able to create meetings without suggestions for time and place to lower the threshold for the meeting to happen
Ideate
User stories were gathered in a backlog where they were prioritized. In retrospect, I would have instead created a user story map to more easily prioritize and plan the design work.
Interaction Design
Since Swublr needs to be a much smoother alternative to messaging, high demands are placed on the interaction design. The goals must be achieved through as few steps as possible with low interaction cost.
I started by iterating on user flows for different tasks such as "creating an invitation". I iterated on these to reduce the number of steps to a minimum.
Sketches
Based on the user flows, I sketched out several different solutions. Crazy 8 was used primarily to get sketches to take inspiration from when defining the design as wireframes.
Information Architecture
Since the concept according to the business goals is intended to take a lot of inspiration from Swish, several similarities can be seen in the information architecture. One advantage of using a similar concept as Swish could be that users' mental models fit Swublr's conceptual model, but this remains to be tested. Several design patterns have been borrowed from Swish in the hope that the majority will quickly feel at home. One risk that is easy to assume is that users might feel confused about the app sharing similarities with swish while not sharing the same function, therefore future interviews is required.
Business Analysis
From defined research I now assume users will only use this service if it is much better than their existing solution.
One general need users have are to get help finding activities that suit the date set for the meeting, imagine if these could be presented as discounted offers from companies? If the user base is large enough, perhaps companies would be willing to pay to be included as a selectable option.
First, the user base must first become large enough to attract companies to join. Therefore, it is absolutely necessary to prioritize the functions for planning the activity and then design and develop the offer functions.
If the business model works, Swublr's revenue could come from the companies instead of the users, which should increase the chance of converting new users and making the service easier to scale globally.
Prototype
An interactive prototype was created to test whether the ideas make it easier for users to book activities together.
The starting point was flows and wireframes from the interaction design and the information architecture structure.
Almost all elements are components to be able to quickly iterate and change the prototype. The component library is structured according to atomic design with the difference that all components are sorted by function and built entirely with auto-layout.
A style guide was created based on the brand with blue as a starting point to give a sense of security.
Tools like Material Theme Builder were used to quickly generate color styles based on the primary color.
This interactive prototype follows Material Design guidelines, the next step is to make a corresponding design for iOS.
Test
With the interactive prototype, I tested the usability of the primary flow of sending an invitation. The measurement criteria were:
Complete the task in no more than 1 minute
Without making any mistakes along the way
Early in the testing, it became clear that the "Agenda" on the homepage was not clear enough and was misunderstood. I made changes to the design for the next test and then it went better.
After the usability test, an interview followed where I wanted to understand the test subjects attitudes and experience of the concept. Does the app solve their needs, is there anything they miss? A positive surprise was that many could imagine testing using Swublr instead, especially if there are offers. Several people started coming up with more features and ideas for solutions. An engagement that I interpret as that they may be motivated to use the service.
Next step
the next step on the road map is to finish the interaction design for the discounted offerings flows, more specifically the user story:
As a user, I want to get suggestions for activities that suit the selected date to make it easier to find something to do
Further business analysis has to be made to validate if the new business plan holds up. If users actually are motivated to use the service if there are discounted offerings.
Also the conceptual model using Swish as inspiration has to be further investigated. From the interviews the answers are mixed and give no clear answer.
I sincerely believe in the project and will continue iterating on it and keep evolving this portfolio case.
