SignPal

Executive Summary

Introduction

Imagine you encounter a deaf person in your daily life, would you be prepared to communicate with them? Wouldn't it be great to have an effective way of learning how to communicate with them in a fun, interactive way? What you need is SignPal. SignPal is a sign language learning app designed by my team and me using the process of Lean UX. Lean UX is a user-centered design process that streamlines the design process by removing time-wasting tactics, including constant collaboration, and more experimentation.

Duration

August 2022 - November 2022

Approach

Lean UX

Role

UX Designer, Researcher

Team

Kai Laborde
Chisom Izuchukwu
Witty Boateng
Ana Velarde
Almasi Gathoni

Tools

Figma, Miro, Discord, Zoom, Otter.ai, Protopie

Sprint 1

Sprints are short-duration work cycles that allow teams to tackle parts of a project and get it to a state where it can be ready for deployment. Throughout each Sprint the team began with a design week, then two Sprint weeks that involve building, testing, and refinement.

Design Week Zero

For this week, my team had to figure out how to design our website based on the processes of the Lean UX canvas. The Lean UX canvas has eight exercises: Business Problem, business outcomes, users, user outcomes & benefits, solutions, the most important thing we need to learn first, and the least amount of work we need to do to learn the next important thing. The canvas was designed to guide the conversation from the current state of your product or system to its desired future state or target condition.  (Gothelf & Seiden, 35)

1. Business Problem

The main question for this step was "what problem does the business have that you are trying to solve?" To solve this problem, my team had to brainstorm what features the app would need, what our market is, what similar products there were in the market and what they fail to address, what we would focus on, how we would solve the gap in the market left by competitors, and how we would measure our success.

2. Business Outcome

The goal for this exercise was for my team to create assumptions on how to measure the success of our design. Together we worked on the acquisition, activation, retention, revenue, and referral columns (AARRR) on the left. We worked on these by creating sticky notes of our individual thoughts and suggestions. Once we were done with that we looked at each AARRR note and charted what outcomes we thought would occur and what behavior in the users would prove our app's design/features as successful.

3. Users

The goal for this step was to create proto-personas, a persona based on my team's collective assumptions of the app's potential users. Personas are fictional avatars that represent the potential users of an app. Proto-personas are our best guess as to who is using (or will use) our product and why (Gothelf & Seiden, 56). Therefore, we ended up creating two potential users, Alex Robinson and Kate Smith. Alex was a 20-year-old student that needs to take a language class in order to graduate college. Kate is a 30-year-old woman to wants to expand her knowledge and learn a new language.

4. User Outcomes and Benefits

The goal for this exercise was for my team to answer why users should seek out our product, what benefit they would gain from using it, and what behavior change could be observed that communicates that they've achieved their goal.  Using data from the proto-personas we answered these questions:

5. Solutions

In this exercise, my team had 10 minutes to sketch out a solution to the previous exercise's questions to brainstorm on what features the app should have. We then had to vote on which sketch we favored.

6. Hypothesis

Taking our assumptions from boxes 2,3,4, and 5 into account, we created several hypothesis statements and placed them into a table. The hypothesis statement must be structured as:

  • We believe we will achieve [this business outcome]
  • If [these personas]
  • Attain [this benefit/user outcome]
  • With [this feature or solution]

7. Hypothesis Prioritization Canvas

The hypothesis statements we created in the previous exercise then had to be chosen and ranked based on their perceived value and their risk of implementation to see whether or not they were worth keeping.

8. MVPs and Experiments

The point of this exercise was to test each of our hypotheses for effectiveness. We did this by brainstorming how we could test the features we were proposing for effectiveness.

Sprint Week 1

2- Day Standup Meetings

Standup Meetings are short 15-minute daily meetings where each team member discusses what they did, what needs to be done, and what could be improved upon.

Sprint Week 2

Eye Spy Challenge

At the start of this week, we did our first experiment, the Eye Spy challenge. For this challenge, we gathered a group of people to play a virtual eye spy game. The game had several levels in which the participants were asked to spot a specific color or item in their daily lives. Once they found said item they would send us pictures of the item to increase their score on the leaderboard. Participants also had the option to customize their own avatars to personalize their experience.

The experiment ran for about one week and involved about eight people. The overall design of the layout and features we included in our challenge mockup we came up with after doing the exercises from the previous one. Furthermore, the purpose of this experiment was to observe whether the features we designed for the app would work positively in practice. Once the exercise was completed, we interview the participants on their experience.

Affinity Mapping

Affinity mapping is the process of grouping similar items. For our affinity maps we made sticky notes of the main points our participants made in their interviews for the Eye Spy Challenge.

Sprint 1 Retrospective

A retrospective is a longer meeting between the team to look back at what we learned throughout the sprint. What went right? What went wrong? What could be improved?

Sprint 2

Sprint 2 followed the same process as the previous sprint, however this time the group was focused on improving upon our previous design based on the feedback we received from the usability tests and and extra information we learned.

Design Week Zero

Design Week Zero was all about us looking back at our previous conclusions on our Lean UX Canvas drawing either new ones or reaffirming them. The initial proto-personas that we made didn't change and all the feedback we received through our tests affirmed much of our initial assumptions.

Design Week 1

Low-Fidelity Prototype

Design Week 1 was dedicated to out team creating our minimum viable product(MVP), a version of a product with enough features to be usable by users who can then provide feedback. We created our MVP prototype with Figma using a low- fidelity design. A low-fidelity design being a simple and low-tech concept.

Week 2

Usability Testing

For week 2 our team created a high-fidelity version of the app by applying the feedback we received from the low-fidelity prototype's usability tests. In this version of the app, we created it by using a modern design based on what would be seen from other language-based applications. The whole prototype was created in Figma and each member had a different area of the site to work on.

After completing the prototype we gathered the previous interviews participants again to compile their feedback on our high-fidelity version.
The questions we asked included:

Week 2

For week 2 our team created a high-fidelity version of the app by applying the feedback we received from the low-fidelity prototype's usability tests. In this version of the app, we created it by using a modern design based on what would be seen from other language-based applications. The whole prototype was created in Figma and each member had a different area of the site to work on.

Conclusion

Doing this project helped me learn how to use Lean UX and how to walk through the process of it with a team. I am very satisfied with the finished product and the fact that we made it in only 4 months astounds me. My prototyping skills and my ability to communicate with a team have greatly increased.

​The main challenge that I faced was getting the interviews to be scheduled consistently since many of the interviewee's schedules didn't line up with ours too well.

Although I am satisfied with the finished product, I believe if we were given more time extra features could've been added since we prototype doesn't include any interactable games.​Overall, this was an enlightening experience and I enjoyed every moment of it.

Final Prototype