THE APPLICATION
03 / EFFICIENT
Manages all communications and feedback and places them into one place to maintain efficiency.
02 / USEFUL
Helps aggregate useful communications from all team members all in one place.
01 / EASY
Looks just like something leaders are used to. No need to spend hours learning new software.
MEET STRIVE
What is Strive?
Strive is an application which allows leaders of informal teams to make better decisions for the group by allowing them to manage communication, ask for feedback from their team members, and send announcements all from one place. Strive helps leaders become better leaders and reach their own leadership goals by aggregating all of their important information in one place.
We completed this project as a part of an upper-level undergraduate course in User Experience Design at the University of Washington Department of Human Centered Design and Engineering. The primary purpose of this course and our project was to get experience in going through the user-centered design (UCD) process.​
The Problem
Leaders of informal organizations find that members of their team contact them through many different communication channels such as text messaging, emails or Facebook messages and it gets tough to keep track of member requests. In addition, since members seem to be active on different platforms of communication, getting responses from these members becomes quite difficult for the team leaders. The problem was that different members were comfortable with different communication platforms and the leaders found it difficult to keep track of all of them. We created Strive to tackle this very problem.
​
​
The Process
​
To solve the problem, we used the UCD process. This portfolio details the key steps which are outlined below:​
-
User Research
-
Modeling with Personas
-
Developing Persona Expectations and Context Scenarios
-
Design Sketching
-
Storyboarding
-
Creating a Sitemap (Information Architecture)
-
Paper Prototyping
-
Creating Annotated Wireframes
-
Creating Hi-Fidelity Mockups
​
RESEARCH FINDINGS
In order to solve the communication problem within informal groups, we, as a team, needed to research the problem space and understand what the motivations, goals, and pains of the users were. In order to accomplish this, we conducted user research by doing a competitive analysis of products which attempted to solve a similar problem and interviewing potential users.
​
After gathering data from the competitive analysis and semi-structured interviews, we created an affinity diagram to better understand the information we found and see the major themes which arose throughout the research. This was crucial because, after the analysis of the research, we could get a better understanding of our persona who we would design for. The user research and analysis process helped inform the personas we created by unearthing the goals, motivations, desires and pain points of the user. In doing so, we noticed quite a few key ideas.
​
We noticed that team leaders of informal groups like to manage logistics and be involved in the decision-making process. However, their frustrations in leading stemmed from a lack of responses from group members when something was asked of them, miscommunication between team members of certain event times or group discussions and conflict between group members. In addition, we noticed that group leaders did not like to be too involved in conflicts which would arise. From interviewing, we noticed that the primary goal of the leader was to be effective in making beneficial decisions for the group, managing the team members and also, in essence, become a better leader.
Read more about our user research here:
Affinity diagramming in process after qualitative interviews
POLISHED PERSONAS
After conducting user research and analysis of our findings, we created personas to reflect our users. The affinity diagramming we did during the user research phase highlighted the goals, motivations, desires and pain points of our users which helped inform our personas. These personas would help provide a more solidified understanding of our users.
We created 2 personas to resemble real people, Rebecca and Fred, who lead a team of people in informal organizations. First, we created provisional personas and then refined them into more polished versions. Rebecca is a full-time worker for March of Dimes where she is paid to lead a group of volunteers to fundraise for medical research. Fred, on the other hand, is a full-time college student who is also a captain of his college soccer club team. Both of these personas lead a group of people in an informal setting and they both reflect the frustration of dealing with conversations from different communication channels and miscommunication between team members. They both also reflect the key goal of helping their organization succeed in its objectives to further medical research (for Rebecca) and build a better soccer team (for Fred).
Creating these personas was a crucial step because the design process from this point on needed to be centered around them. Creating personas allows for us, as a team, to develop empathy for the users we are designing for and helps us make design decisions. In addition, it helps eliminate bias in the design process which could potentially stem from the design team members’ values. Creating personas helps the design process be centered around the users.
View personas here:
Persona 1: Frederick Lin
Persona 2: Rebecca Stephenson
SCENARIOS
After creating personas, we needed to understand how the persona would use our product to help solve their problems in context. For this reason, we drafted context scenarios which illustrate the situation the persona is in, the issue they face and the solution our product provides.
In order to successfully draft these scenarios, we needed to identify some expectations. Personas helped identify goals, pains, desires, and aspirations. Using this information, we needed to identify persona expectations because we need to know what the persona expects from our product to effectively uncover the scenarios in which the persona would use our product. All the members of our team identified persona expectations individually by referring to the user research findings and assumptions about the persona. After identifying these expectations, we started drafting the scenarios. These scenarios did not dig deep into the design of the product. Instead, they helped illustrate, at a high level, how the product would solve the problem.
The scenarios, essentially, started with the situation which contains the problem for the user, the user's feelings at that time, the user's decision to use the product, and the outcome and feelings of the user at the end.
Creating these scenarios helped provide a more solidified view of how the product we would end up designing helps solve the user’s problems. These scenarios are key in the design process because they help uncover design requirements of our product and inform future design sketches including data and functional elements since we now know the contexts in which this product would be used.
View full scenarios here:
DESIGN SKETCHES
After establishing the scenarios where our product would be used by the user, we began the process of ideating, sketching and iterating over some potential designs for the application itself which would help meet user goals and fit into those scenarios. These design sketches were, in essence, sketched out ideas of how our application would actually look and they also include discussion of how the operations would work and a discussion of its strengths and weaknesses.
In this process, we used the scenarios to come up with a list of design requirements including functional and data requirements. Using these requirements, each member of the team, individually, ideated and sketched different designs of our application. After individually sketching, the team came together, shared each sketch and discussed the pros and cons of each. After iterating quite a few times, we decided on our top 3 sketches and created an interaction framework for each of the 3 sketches of the product which included the overall design layout, a particular focus of the layout, its operations and discussion of strengths and weaknesses.
In this process, we came up with the ideas of having a messages function (similar to email), a polls function (to ask for feedback from members) which we found to be beneficial in meeting the user goals we found during user research.
This step was quite crucial in the design process because it helped us, as a team, visualize how the product would look and discuss how it addresses the pain points, user goals, and user needs. This step helped us inform our decisions for the storyboards and information architecture for our entire application because we had a better understanding of the product's potential designs and what it would include as functionality.
Brainstorming
View more design sketches here:
STORYBOARDS
Creating design sketches for our application in the previous step was crucial because it allowed for our team to get a better sense of what our application was going to look like. That step helped us, as a team, better visualize how our application would be used in the context of our users. In essence, creating the design sketches helped inform the next step of the design process: Storyboards.
In this process, we used what we learned during design sketches and visually articulated how our application would be used by the users in their context and essentially tell a story. In this step, all team members, individually, created a hand-drawn storyboard and a photographed storyboard between 3-8 frames to show how our application would be used in different scenarios for the user. The scenarios our team chose to depict in the storyboards included key path scenarios and context scenarios.
This step was crucial in the entire design process because it allowed for our team to better understand the ways our application could be used. It was quite necessary because it put our brainstormed key path scenarios and context scenarios into perspective. In addition, this step helped us get another step further in solidifying how our application would be laid out. This was really important because it helped us inform our decisions for creating the entire information architecture (sitemap) for our application which was next in the design process.
View all storyboards here:
Storyboards
SITEMAP
After creating our storyboards, we had a better understanding of how our application would be used in the context of solving problems for our users because it allowed for us to visualize our application’s use. Creating storyboards helped inform our next step in the process: creating a sitemap.
​
Creating a sitemap was a crucial step in the user-centered design process because it allowed for us to think about how the entire information architecture of the application we create would be laid out. In the process of creating a sitemap, we worked as a team to find out specific screens or areas of the application the user might find themselves in. We used that information to lay out how the information hierarchy would look like. We created a visual representation of our sitemap using Lucidchart. We also had a lot of discussion with our team about how the screens or each area of the application would fulfill our user's goals.
​
This step was crucial not only because it helped lay out the information architecture, but also because it helped inform the next step in the process: the paper prototype. By visually looking at how the application would be laid out, we were able to create a paper prototype which would model how our application would look like in low fidelity. The information from the sitemap was imperative for this next step.
View full sitemap here:
Information Architecture of Strive
PAPER PROTOTYPE
After creating the sitemap for our application, we were able to visually see the layout of the application’s information architecture. This was crucial because it helped inform our decisions in creating the paper prototype because it helped us know exactly where the user may find themselves and create those screens or pages of our application for our paper prototype.
The step of creating the paper prototype was crucial to the user-centered design process. This is because it was the first representation of our application as a whole in low fidelity. Since our application was intended for a mobile phone, we used notecards to depict the screens of our application. We used the sitemap we had to see which screens we needed to prototype for our application. We worked as a team to depict the screens and add the data and functional elements associated with them on the notecards. We ended up showing all of the most important pages on the paper prototype in order to ensure a better experience in our next step which was conducting a quick evaluation of our application (usability testing).
Creating the paper prototype was a necessary step in the UCD process because it provided us with the first interpretation of how our application would look like as a whole. This was crucial because, in order to have a usable application, we needed to test the effectiveness of our first interpretation. The paper prototype was necessary because it allowed us to test it with potential users which was the next step.
View full paper prototype here:
The first 3 steps to creating and sending a new message to all members of the team
QUICK EVALUATION
We created the paper prototype to see how our application would look like in low fidelity. The paper prototype also allowed us to be able to test it with some of our users. Using the prototype, we conducted a quick evaluation of our application with 5 people. Brief profiles of 3 out of our 5 users are shown above.
Conducting the quick evaluation was crucial to the UX process because it gave us a chance to find holes or gaps in our application which could cause troubles for our users. Since we had been working on our application for about 7 weeks at this point, testing it with other people provided us with information we may not have considered. We conducted usability tests with 5 people, and 2 of them were informal group leaders using the paper prototype. In future testing, we would ideally recruit people who would be our ideal users, however, for this project we were not able to due to time constraints and a holiday weekend. We tested the paper prototype by testing the effectiveness of the following key tasks the user would need to be able to perform.
1. Creating and sending a message to members which repeats every 3 days.
2. Asking members for feedback about how to improve the next meeting.
3. Viewing results of a feedback poll and reminding members who have not yet responded to do so.
We discovered quite a few perspectives and findings which we decided to consider using in our revision process. We noticed that the navigation bar on the bottom of our screens was not identifiable because of ambiguous iconography. This finding helped inform our design decision of including labels under our icons in the navigation bar of our application. We also found that users may also want more functionality such as agenda and reminders functions. Due to time constraints, we decided to not explore those functions. Instead, we used feedback to make sure that the flow of the application with the existing functionality was frictionless.
This step in the process helped yield quite a lot of information which we previously did not consider in our application. This is why it was such a crucial step in the UX process. This would help us later revise our application and better inform our next step: Annotated Wireframes which would essentially be our layout of the entire system in a more medium fidelity manner.
A UW student who has had leadership experience in the past.
A current leader of the Big Climb in Seattle, WA.
A current UW student who is not in the HCDE major.
User One
User Two
User Three
View quick evaluation report here:
ANNOTATED WIREFRAMES
After conducting a quick usability evaluation with 5 users, we found quite a few areas which could be improved or made more efficient. This really helped us make our design decisions during this step, Annotated Wireframes, because we knew which areas need to be improved and created the wireframes of our entire system keeping that information in mind (such as labels for icons in the navigation bar).
Creating wireframes was a crucial step of the UX process because it allowed for us to lay out the entire system of our application. We created wireframes of our entire system which meant that we created all of the screens of our mobile application which the application would have. We also incorporated feedback from our quick evaluation in the wireframes (e.g. added labels to icons in the navigation bar, changed a few buttons and their labels to maintain consistency across the application). This was a long process because we had to make sure that all parts of the system were covered and that we annotated each unique feature of each page to remove ambiguity about what the entire application and even its smallest components do. Although long, this process helped us get a better sense of how our entire application would be laid out and what all the screens would look like. We used Adobe Illustrator and Sketch to create the wireframes and annotations.
This entire wireframing and annotating process was long and it helped us learn a lot about how much work goes into the step. It also helped us get a more solidified sense of our application’s nature. This step helped inform our decisions for the next step in the process which was to create high fidelity mockups of some of our system. The reason it was helpful is because it helped us see how all the screens would look like and, based on that information, we could add some visual design to the screens to make them look more complete and high fidelity. Since we also conducted critique of our wireframes, the high fidelity mockups were also a place where we reflected the changes we needed to make in order to clear ambiguity of the wireframes.
Creating and sending a message (key path scenario)
View all annotated wireframes here:
HIGH-FIDELITY MOCKUPS
After the user testing of our paper prototypes, we refined our design, made the wireframes and prepared for the high fidelity mockups with SketchApp. Visual communication is an essential part of the UX design because color speaks to people and we can use color to further refine the user experience of the application.
First of all, the default color of the Strive is blue. Blue is a cool and calming color, which also indicates creativity and intelligence. Since leading the teams is a stressful work and it requires a lot of decision-making, we used blue to create the effect that can reduce our user's stress. Moreover, we use red or yellow to emphasize some important features and information, such as the notification and the anonymous feature of the poll. Since red and yellow stand out from blue, these color choices help us reach our goals of creating a user-friendly design.
The color is also an effective way to group something. That is, in our high-fidelity mockups, we came up the idea that uses colors to distinguish different groups. The user can choose the color of the group tabs in the settings area of our application. When users have multiple groups in their hand, we want to make their job easier and reduce the possible chance of mixing and confusing information from different groups.
View all high fidelity mockups here:
"Messages" wireframe high-fidelity mockups
"Create a Poll" wireframe high-fidelity mockup
