We had a goal to make it fun and easy for friends and neighbors to give and get help for anything, anywhere.
After they released version 1, they realized they desperately needed a UX Designer. Below is the process I took to get them on track.
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 you can also see an example of the notes taken from one of the early usability tests.
While I was conducting Usability Tests and familiarising myself with the product and company, I was also working closely with the CEO to define the business goals. This presented an even greater challenge because he had not really defined them before, and wanted to target two completely opposite audiences. I worked with him and the team to come up with some targets to hit and some KPIs to start tracking. I also ran brainstorming sessions and got the team to come up with a deadline for the new version of Otherly.
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 to do more research on Altruism and to find out what motivated people to selflessly help each other. I would share these findings with my team and brainstorm ideas on how we could use this knowledge in our designs. Here you can see the notes from two of the many papers I read on the subject and the takeaways from each one that helped with our designs.
With my knowledge on altruism and motivations, I needed to lock down a preliminary target audience for our MVP. This would help us justify design decisions and give us a face to design for. Here are the research questions we asked our participants in order to determine if any patterns could be established in their answers. If we found patterns, we then used that as traits in our user personas.
From our interviews, we found a lot of patterns in certain apps and sites that our users used on a daily basis, so 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 in our designs. Here you can see several of the reference images we used and how that translated into our final designs.
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 needed to get across as there was much more limited space than on web. From that, we knew we could put additional features and functionality in our web app later on. Here you can see a sample of some screenshots from our mobile wireframes and our web app wireframes.
We then ran tests on our mobile and web app wireframes and iterated over and over again until we were getting consistently good feedback with little issues. Once I was satisfied that we were getting the goal across with the functionality and information architecture, it was time to pass these off to the Interface Designer, so they could turn them into beautiful mockups with a proper style.
Here you can see the inVision prototype that was used and updated over and over again every time there was a new feature. It has over 150 screens/states.
The ID then took the wireframes and gave back the first round of mockups. By this time, we were well on our way to the final product, but unfortunately our CEO could not secure investors and the product had to be put on hold. Once that issue is solved, I am hoping that we will pick up where we left off. Here you can see the first draft of the final designs from our Interface Designer.
The next steps for me would be to review the mockups with the ID, and constantly work with her to reiterate them so the functionality and architecture remains intact. Usability Tests on a new prototype with these would be conducted and, once satisfied with the feedback, the devs would then start building it while we worked on finalising the Web App.
This whole process took about four months, part time, to get to this point.