ABOUT TRUSS
When we first got together, we brainstormed lots of user groups to focus on, as we wanted to find one that was unique outside of the University of Washington system, but also one that we could gain access to so we can gather adequate research in the time allotted. We settled on Mentors being our target audience because we have all had experience being mentors or being mentored, and we thought that Mentors would be happy to help us in our research efforts. We also noticed that mentors use a lot of tools, but there is not really a tool designed with mentors in mind.
RESEARCH FINDINGS
As a group, we each set out to interview one person who had experience being a mentor. We wanted to start as broad as possible, so we did not limit what type of mentor we chose. We interviewed the following people:
-
A 54 year old woman who is a Chief Technology Officer at a 10,000 employee company.
-
A 50-year-old female completion coach.
-
A 23-year-old female University of Washington student organisation president.
-
A 35 year old digital marketing manager.
​
​
POLISHED PERSONAS
The personas represented here are based almost entirely on the research we completed. From the research, we noticed that there were two very distinct types of mentors that we needed to keep in mind: Older, more experienced mentors, vs younger, less experienced mentors. There was also a slight distinction in that some mentors are mentors as their occupation (advisors, counselors), while some are mentors side, such as a manager mentoring an intern, or someone who is skilled in the industry who had a college student reach out asking for a mentoring relationship.
​
The goal of these personas was to embody the research into a believable person, so we can keep in mind and refer back to who we are designing for. Creating these personas provided us insight into functions that we need to include within the application to tackle issues that mentors experience troubles with.
USER JOURNEY MAP
The user journey map represents a mentor’s mood as they go through their lives as a mentor. We originally set out to complete a day in the life of a mentor, but we eventually felt like a mentoring relationship does not really have particular pain points in the day by day, but rather over a long period time. So instead, we mapped a mentor’s stress and confidence level of the relationship over the time span of 3 meetings.
The was helpful in the design process, as it depicted a timeframe and its events that we were designing for. After creating this, we were able to think about how a new product could fit in the timeframe to alleviate the stress of the mentoring relationship while boosting a mentor’s confidence.
DESIGN REQUIREMENTS
While keeping our research and our user journey map in mind, we listed out design requirements that we wanted our application to have. Each requirement focuses on the mentor’s ability to successfully provide the mentee with the best guidance they can. Going through the major aspects we wanted our application to have and critically analyzing them presented us with a deeper understanding of the application we were designing. These steps solidified the ideas we wanted to present within the application and provided us a strong basis for designing the visual components during the design process going forward.
STORYBOARDS
We each went off on our own to create an array of storyboards on how we think mentors would interact with both our product and mentees. This process allowed us to not only think about the situations that mentors would find themselves in but the screens that they would interact with as well. Doing so granted us insight into the various displays and interactions that we needed to focus on going forward in the process of designing TRUSS.
INFORMATION ARCHITECTURE
The purpose of the Information Architecture was to think through the components of the application, and how they were going to fit in with one another. This allowed us to think of the key pathways and how elements of the application were going to relate to one another. We have updated the information architecture now that we have completed a final product, but what it was at the beginning helped us begin crafting the application itself.
PAPER PROTOTYPE
The paper prototypes tested three key pathways we imagined that mentors would take while using the application. The first was adding reasoning behind a set goal for the mentee and add a task for the mentee to complete, the second was checking and responding to emotional feedback the mentee has uploaded, and the third was adding summary notes from (or during) a meeting. These tasks were important to test because they address what was causing pain points in our personas, as well as help mentors achieve their desires. They also gave us information about our design ideas and if they resonated with the user. Going through this process gave us valuable areas to further iterate on to make it a more valuable and fluid experience for mentors.
QUICK EVALUATION FINDINGS
For our evaluation, we tested people who were either mentors themselves, or had experience being mentored. We had one man who was a father of 4, who also mentored a refugee family from Myanmar, a college senior at UW who mentored first-generation students who were new to the University, a 50 year old completion coach, and a 37 year old web developer who works for a digital ad agency.
We found that the icons we picked were not clear enough in signaling what we intended. This caused our participants to be stuck for an extended amount of time in navigating the prototype. We also discovered that the words that describe emotional response were unclear. We needed to correct and make clear what the mentee emotional response was and clarify what actions mentors can take to assist the mentee. We also discovered that the process to add meeting notes to a specific day was unclear, so we made sure to simplify the process when making the wireframes. Our last finding was that users wanted to know more about what is happening with the goals and tasks, and that it was a little unclear about how to add, edit, and delete them.
The testing was helpful, as we discovered what might have been clear to us was not explicitly clear to the users. We spent time rethinking the icons we used and simplifying the workflow by using similar screens for similar functionalities, as well as making sure the icons fit in the context they are presented in.
ANNOTATED WIREFRAME
The annotated wireframes are low-fidelity mock-ups of the entire system we designed. We dove in and explored all the realms of our design, from the Goals and Tasks functionality, the Overview with a timeline, to the Communication panel. Each display we created includes points with an explanation of what each part does to increase understanding to better depict how the future application will function. This laid out a solid basis for our visual design to further improve upon and allowed us to understand how all of our ideas translated into visual representations. Moving into the final steps of creating TRUSS, these mock-ups allowed us to think about the details we wanted to improve upon and to start thinking about color palettes that would make the application enjoyable to use for mentors.
GROUP REFLECTION
As a group, we learned the value that information about your user group holds. The more you learn and discover about your user base, the easier it is to make smart design decisions with confidence. When our team hit roadblocks in our design, the research we had done was a very useful tool to get us back on track and think about what can be done in creating our product.
Our biggest challenge in designing the product was honing in and deciding on the main functionalities. The life of a mentor is very complex and can vary greatly from mentor to mentor, as most people who identify themselves as a mentor are not mentors as their occupation. They can be parents, counselors, company executives, volunteers on the side, and many other things. With all these variables in mind, it was challenging for us to go in a direction that would be beneficial to all mentors.
If we had more time, we would have loved to interview more mentors about their mentor/mentee relationship, as well as interviewing those who identify themselves as mentees. Our project focused on the mentor’s side of the fence and what would benefit them the most, but we are fully away that a mentoring relationship is a two way street. With more time, it would be very beneficial to talk to mentees and pay attention to what they experience in this relationship, as they are just as big of a stakeholder as the mentors are.
Overall, this project challenged us as designers and researchers, but in the end of the day we grew to become better UX designers and left with a greater understanding of the profession we are pursuing.