Otherly

Freelance

Overview

This was a platform built for people to selflessly help each other. It was designed to make it fun and easy for friends and neighbors to give and get help for anything, anywhere.

The problem

When I came on board, the devs had already built an MVP but were not seeing any traction at all. There was no clear vision from the CEO, and every dev in the company had an equal say in how the site should be designed and built. This resulted in a Frankenstein’s monster of an MVP, with no flow, no informational hierarchy or prioritization, and an overwhelming amount of poorly thought-out features that meant nothing to their users.

My role

I was hired on as the Lead UX Designer, to redo the MVP and to get this product back on track.

The final version of Otherly's mobile app

Original designs

This is what was built before I joined the company. It was designed and built by the programmers, and seemed to have no consistency, focus, or flow. They knew it needed some work, but did not understand how much, so I started doing quick Usability Tests to show them the overwhelming, negative feedback, and that almost everything needed to change.

Here are some raw notes from one of my quick usability tests.

Once I proved to the team and CEO that there were some serious issues, there was immediate buy-in for UX.

A screenshot of the original platform

Wrangling the CEO and team together

Defining business goals

After the results from the usability tests, I worked with the CEO to define the business goals. This presented an even greater challenge because he had not really defined them before, and he wanted to target two completely opposite audiences with the same features.

I worked with him and the team to come up with some targets to hit and some KPIs to start tracking. Then I had them create a new roadmap and we agreed on a deadline for the MVP of the new version of Otherly.

We were really starting to feel like a team here.

The team at Otherly planning our MVP and roadmap

Research on Altruism

Since the goal of this project was to make it easier for people to selflessly help each other, I took a step back from the designs and I conducted more research on Altruism to find out what motivated people to help each other.

I shared these findings with my team and we brainstormed ideas on how we could use this knowledge in our designs.

Here you can see some of the takeaways from the research that helped with our designs.

al·tru·ism

/ˈaltro͞oˌizəm/ (..?)

noun

the belief in or practice of disinterested and selfless concern for the well-being of others.

User research interviews

With my knowledge on altruism and motivations, I then needed to lock down a preliminary target audience for our MVP. This would help us justify design decisions and give us a face to empathize with.

I conducted around 30 research interviews in order to determine if any patterns could be established in their answers to use as traits to define our target audience.

Here are the research questions I asked our participants.

An image of the survey used to help define our target audience

Product research

From our interviews, we found some patterns in certain apps and sites that our users used on a daily basis. For our MVP, we knew we needed to get something out that would be easy to use for our users, so we incorporated common conventions from those apps and sites, as well as other apps I found in my comparative analysis.

Here you can see some of the images I compared and how that translated into our final designs.

You can also click here if you want to see the full image.

A comparative analysis of the products our target audience use

First mobile, then web

Wireframing the apps

At this point, we were comfortable with the vision and direction of the product, so I then began wireframing the functionality for the mobile version. This allowed us to really consider what functionality we absolutely needed. and how we could enhance their experience with the full web app.

Here you can see some of our mobile wireframes and our web app wireframes.

You can also view the full image of the mobile wireframes here, or the full image of the web app wireframes here.

A closeup of the wireframes for the mobile app

Prototypes, tests, and iterations

We then ran tests on our mobile and web app wireframes and iterated over and over again until we were getting consistently good feedback. Once I was satisfied that we were getting the goal across with the functionality and information prioritization, I passed these off to the Interface Designer, so they could turn them into proper mockups.

Here is a snapshot of the InVision prototype for the web app. It was updated several times and now has over 150 screens/states.

You can view the full InVision prototype here.

A screenshot from the inVision prototype for the Otherly webapp

First draft of mockups

The Interface Designer then took the wireframes and gave back the first round of mockups for mobile.

By this time, we were well on our way to the final product, but unfortunately, the company could not secure more funding and the product had to be put on hold.

Here you can see the first draft of the final mobile designs from our Interface Designer.

You can view a more detailed image of the final designs here, or you can see a comparison between the wireframes and final designs here.

The final version of Otherly's mobile app

Next Steps

If I ever worked on this project again, my next steps would be to review the mockups with the ID, then constantly work with her to reiterate them so the functionality and architecture remains intact. Usability Tests on a new prototype with these mockups would be conducted and, once satisfied with the feedback, the devs would then start building it while we worked on finalising the Web App.

Sparq Next Gen Party in my Dorm