As college students, we felt like there was a critical lack of a way for college students to share information within students from the same college.
This project was mainly a class project with 4 other students, so there were some limitations as to what we could do: for instance, we wanted to take more time to further understand user needs and do background research on the user population.
ShareU aims to provide a solution for the lack of mass communication between peer university students. The app organizes information about events, clubs, tickets, textbooks, housing to verified students in one centralized platform. Not only can students exchange information and items, it helps students become more involved in their campus community.
Starting off, we asked ourselves questions, such as:
To answer these questions, we decided to research the current market space and understand what's missing, as well as understand the needs of our users.
To understand the type of interactions that we should either avoid and implement, we looked at the strongest competitors that:
The analysis process was broken down into 5 different criterion: each of which we determined are key components of the end product experience. We gave each criteria a rating out of 5 which indicates how much we want to learn from their design.
While we wanted to research deeper into understanding our users, we performed several informal interviews among our peers to create 3 main personas and 1 malicious persona.
We reorganized the data into behavioral patterns and developed user personas to represent the userbase.
From this, we created a couple ideal use case scenarios that would show how they would interact with the platform.
Following persona development, our team decided to make some basic design decisions to guide our design. This involved a 3-step process of: Question, Options, Criteria.
We asked 4 questions with this approach and sketched out each option, and then evaluated each option with the criterion. The decisions were based off of what we considered to have higher values than other criterion, and since we were a team of 5 designers, this method gave design discussion an organized structure and allowed us to collectively make decisions.
From the QOC results, we built two iterations of low fidelity paper prototypes that showcase basic interactions and use cases in the scenarios. The first was built for a quick round of testing with sample users. We gave subjects tasks similar to the scenarios and asked them to navigate through the paper prototype.
This helped us build a second iteration based on user feedback, where interactions were more refined and expanded upon. For instance, the second variation of the paper prototype includes the ability to look at other people’s profiles.
After building the second prototype, we moved our designs to Adobe XD, where details were more refined over two iterations. Again, we ran a set of user tests based on similar tasks, and used the feedback to improve our second iteration.
We made a couple more minor but essential changes during this process. For instance, opening other user’s profiles from the messages originally had an option to message and to navigate back to the messages page. This was not only redundant but very confusing. We solved this with just a close button to allow users to easily navigate back to the previous page.
A final prototype was created. Here's a video of us going through a sales scenario!
Due to the project limitations, we made some decisions that were different from our original vision. With that in mind, some key things that I might have done differently are:
Thank you!
