AWS Amplify Studio

User Persona & User Journey

The first step of the design process involved creating the user persona and mapping out the user journey in order to identify the characteristics, needs, and painpoints of the user. The target user for Amplify Studio is the frontend developer who may not be as familiar with fullstack development so they lean on Amplify Studio to help set up their app backends.
‍

Needfinding

Then, I sourced (via AWS Amplify's Twitter and Discord) and interviewed a number of developers who use Amplify Studio in order to better understand their perspectives from their experience developing fullstack apps.

The questions I asked were as follows:

What did you use Amplify to build? What data models did you create? Did you use Studio’s visual editor to create your data models?
What configurations did you set on the data models / fields? What authorization rules (if any) did you set on your models?
How did you use the visual / code editor to configure your desired settings?
Were there things that you wanted to do that’s not in the visual editor?
Where did Amplify make it easier to create and manipulate data models? Where was it harder?

After I collected the datapoints, I synthesized the findings from the interviews.
‍

Couldn’t apply all the configurations they need (custom queries, mutations, and subscriptions, and field-level and dynamic group auth)
Studio seems like a good place to start the schema but people would eventually had to transition to their code editor
Providing explanations in-line, so that they don’t have to keep switching between Studio and documentation

Data Modeling Research Survey

We decided to narrow down on the need for additional configuration tools in Amplify Studio. I then ran a 1 -week survey with the UX research team to gather more quantitative data on what kinds of customization users wanted to see. We targeted for 50-100 responses and hit a total of 80 responses before closing the survey. Each respondent received a $25 gratuity for completing the survey.

Our findings from the survey are as follows:
‍

Most users use Studio alongside their own IDE/code editor for data modeling (73%). The top three reasons this is the case is they “learned how to write their own database schema” (37%), they “use the Amplify CLI instead” (37%), and/or they want to add some sort of extra customization like “custom queries, mutations, and subscriptions” (29%) or “advanced auth rules” (26%).
The top reason users have never used Studio’s data modeling feature in the first place is because they “need more flexibility and customization” (39%), followed closely by the fact that they “write the database schema themselves” (34%).
Many of the use cases were for rapid prototyping purposes. Users highlighted the speed and ease of getting a backend database up and running.

Goal: Extending the functionality of Amplify Studio's data modeling tool
‍

Ideation / Brainstorming

We were inspired by the accounts we heard of chance encounters and proximity-based connections. Our final solution was a mobile app that alerts you when you are near a person with whom you share similar interests, creating more opportunities for people to stop and connect in a spontaneous and organic fashion. The user would be able to perform the following tasks:
‍

Simple Task: Befriend someone nearby with similar interests as you
‍Rationale: The most basic task we want our users to complete is to connect with others on the app. This would be a way to see who’s around and befriend each other based on commonalities.
Moderate Task: Start a conversation with someone in-person
‍Rationale: A more difficult task would be to “collide” with someone (AKA come into close proximity with a potential match), navigate to them, and start a conversation in person. We wanted to use this task to simulate a “chance” encounter to get people talking in-person rather than on the app.
Complex Task: Add a past friend to your network.
‍Rationale: As users stay on the app, we want them to be able to expand their network by adding new people as well as existing friends who are also on the app.

Design Iterations
‍

Lo-fi wireframes

Task 1: The first task featured a home page where the user can see other users nearby. Clicking on any of the profile bubbles will bring the user to their full profile where they can message them and add them to their network.
‍

Task 2: The second task is a “collision” where the user receives a notification and the user with whom they collided. They are given a list of similarities and a choice to accept the collision. After they accept, they can navigate the person to meet up in person.
‍

Task 3: The third task features a node diagram where the user can see their existing connections. When clicking on the “plus” button, they are brought to a menu where they can add new friends. After they add a new friend, the friend shows up in their network and they can chat with them.
‍

We conducted initial usability testing to validate the task flows and identify points in the design that needed to changed in the next iteration. From our usability tests, we created a visual critical incidents log to identify points in that our users especially struggled with or enjoyed:
‍

Based on this initial round of feedback, we made a number of changes in the next iteration of our design:
‍

Feedback: Users liked the different bubble sizes but were unsure if it meant distance or compatibility.
Change 1: We added match percentage and a proportional stroke around bubbles. Users will know that bubble sizes are proportional to their match score instead of their distance by seeing bigger bubbles with larger scores.
Change 2: Bubbles will bob around slowly instead of staying fixed.To further dissociate bubbles with distance (prevent the idea that the screen is a map), the bobbing will indicate that bubble positions are random, not fixed in place by distance as a map would be.

Before

After

Feedback: Users said they would not look down at the phone while talking.
Change 1: We replaced the similarities list with icons. While users are walking or talking to the other person, they are unlikely to look down at their phones for a prolonged time, so we want them to get a general gist with a glance.
Feedback: Users were unsure what “accepting” a collision entailed.
Change 2: We replaced “Accept with 3 buttons stating explicit actions. This eliminates users’ confusion and concerns on privacy, and creates more options for them to evaluate and interact with the match before having personal interaction.

Before

After

Feedback: Users try to click on the picture of themselves when adding a friend.
Change 1: We indicate ourselves with a different color. The purple differentiates the user from the rest of the people and makes the center of the network clear.
Feedback: Users really enjoyed the network concept.
Change 2: Make the interface more interactive (zoom, scroll, etc) and added a timeline filter. This makes the tree building process more fun and makes filtering out earlier connections easier.

Before

After

Med-fi prototype

Brand Identity

Meanwhile, we started to define the brand identity for our app. We decided on the current logo for its symbolism and simplicity, as two circles - representing people - of different colors interlocked together. For our color scheme, we were inspired by companies like Stripe and Splunk that used a bold and vibrant gradient. We though that this would look more modern and also add to the energy of the social app.
‍

Concept Video

We also created a concept video to illustrate the core action in our app and visualize how those interactions would occur in real life. This helped us to further develop the purpose and direction of our app when we apply it to real-world settings.
‍