Team Builder
Team Builder is a multi-platform software designed to streamline the process of creating teams. These team are specically academic in nature and it’s intended users are college professor and their students. Currently, there is only one well known program that provides our functionality but they (1) have a cost to use and (2) are only available web. We plan to make the software free to use and be available on web and mobile.
UX Team Members
- Nicholas Shaddox
- Personas & Scenarios
- Heuristic Evaluation
- Wireframes
- Sketches
- Phase I Report
- Phase I Executive Summary
- Phase II Report
- Phase II Executive Summary
- Phase III Executive Summary
- Zane Gabor
- Personas & Scenarios
- Heuristic Evaluation
- Wireframes Report
- Prototype
- Phase I Executive Summary
- Phase II Executive Summary
- Fabian Garcia
- Personas & Scenarios
- Heuristic Evaluation
- Images for Personas
- Phase III report
User-Centered Design Artifacts
Phase I: Analyzing Users, Competitors, and Initial Designs
Executive Summary
As we move forward into the future there is a rising need for ease of use program ready built to assign teams at the push of a button. Team Builder will strive to be the complete package, including everything necessary to build a well-balanced team under user-set parameters with full chat functionality to have every tool in one place.
Our Competitive Analysis lead to a few important observations:
- Our closest competitor has a UI that is out of date and requires a subscription fee
- Chat programs don’t have an automated team building function
- Survey tools are great for data collection, but they do not have robust chat functionality
- There is no available free program that combines all of the functionality listed above into one usable package
Our Heuristic Evaluation shed light on the format we would like to emulate for ease of use.
The needs of our personas lead the design of our system to include:
- Two primary roles for the users of Team Builder, Organizers and the Organized
- The Organizer needs to be able to input their own parameters for team sorting
- The Organized will be able to adjust their user profile to specify preferred roles and working styles
Our sketches gave us a view of:
- The user interface made to streamline relevant information for the user
- Actions for creating and giving input on possible teams will be upfront in design so as to reduce app travel for any given task
Full phase I report
Phase II: Refining interaction and designing wireframes
Executive Summary
REWRITE
We’ve officially made it past Phase I and II in the development of Team Builder. In our efforts to make it an all in one program for building and managing teams, we have had several learning experiences that have guided the direction of progress on our way to a usable product.
We created our initial wireframes to:
- Achieve a basic understanding of the layout we are going to use in our application.
- Identify and map out the key elements of our application
- Gain an understanding of the process of putting together a wireframe, to begin with.
Upon receiving our Cognitive Walkthrough we were presented with several problems regarding our wireframes, many of which existed because they were incomplete.
- Recurring feedback was that our application was confusing to use
- Many elements presented a poor mental model for new users
- The application did not provide feedback to the user regarding the task they were currently completing
- Testers were unsure which buttons lead to which page
Moving forward we have refined our work around the given feedback.
- The wireframes are now complete
- Directions are now learnable for new users
- Creating a new group/team is easier to follow
- Group and team icons were revised for a better mental model
- Confirmation messages added for functions to provide feedback to user
Full phase II report
Phase III: Prototypes and User Testing
Executive Summary
In phase III of our report, we focused on user testing with a functional prototype (limited by the XD software). We interviewed a professor and four students from the same class. The interviews were designed to collect data about specific tasks and to see if the participants could complete them in a manner that would be similar to other software that has similar features answering the fundamental question; Is the Usability Experience familiar and learnable?
We created our initial prototypes to:
- Mimic the functionality of the programmed application.
- Create a workflow we are going to use in our application.
- Emphasize the most common tasks.
- Prepare for user testing.
After receiving the feedback from our User Test, there were many common areas where we could improve. That includes our application and the tasks in our user test.
- Students found that the members button could be an icon instead of a dropdown.
- Students found that the logout button is less important on mobile than web.
- Students found that a person icon would be better than a gear icon denoting an account.
- Students found that completing tasks was familiar using *common conventions.
- professor found that it would be useful to have an archive feature for groups/teams no longer being used.
The fact that none of the students got stuck on any tasks either indicates that the UI was well designed using common conventions or that the tasks were too simple to test learnability. Moving forward, these are the changes that we could make.
- Improve the tests by having the user start at the beginning of the first task for each new task. This can better test if the application is learnable.
- Make the tasks a multi-step and multi-page process to better understand users’ paths as they navigate the application. Could give insight into better/other workflows.
- Make recommended changes based on the feedback from the user test.
- Run another user test with the everything listed above.
Full phase III report