• Built an interactive prototype with Axure, refining the interaction design using design patterns, and conducting testing.

1. P4 Mid-High Fidelity Prototype Proposal
CDM Collab
Mustafa Ahmed, Rachel Quist, Will Estus
Prototype: https://6e8ejw.axshare.com/#g=1&p=log_in
Denise Nacu | ISM 220

2. Introduction​​:
Most students are subject to the occasional group project, but for DePaul students in the
College of Computing and Digital Media, group projects a fact of life. Given the necessity of
collaboration in the college, we sought to find a way to help make the experience better for
students by making a mobile app that could provide resources to help in the problem areas we
identified while conducting initial research. CDM students were asked about their thoughts and
opinions on group work, as well as their process in seeking out help from other people. We put
together a list of eleven insights that could help us target problem areas. Using those insights,
we moved on to form four design principles to guide us in our approach to our mid-high fidelity
prototype of our app.
Insights
1. Students prefer getting help online (info sources) first.
2. Students are willing to seek help from peers.
3. Students will seek help from professors and tutors only if absolutely needed.
4. Schedules prevent students from getting help from professors.
5. Students tend to avoid seeking help from professors because of anxiety and authority
differences.
6. Students seek some level of comfort and control when working on a project.
7. Students prefer to work alone because they are insecure about their skillset.
8. Students prefer working in groups so they can benefit from each other’s contributions.
9. Students need organization to keep projects moving.
10. Unaligned schedules limit productivity on group projects.
11. Students prefer group members that have skill sets tailored to the project.
Design Principles
A successful solution will:
1. Offer multiple sources for help with an emphasis on online help.
2. Address the need for comfort, control, and confidence.
3. Align students’ availability and preference for organization.
4. Utilize different students’ unique skill sets, contributions, and experience.
Mid-High Fidelity Prototype | 1

3. Users and Context​​:
We conducted one-on-one interviews with nine undergraduate CDM students at DePaul
University. When we set out to do research, we wanted to see what problems, if any, students
have with group work in their classes. In addition to that, we were looking for the processes they
through which they sought collaboration (e.g. who they wanted to collaborate with, be it
teachers, peers, or other sources, like those online) so that we could cater our design towards
what they already seemed comfortable with or drawn to.
We found that there were two very different types of users we were working with: those
who prefer to work on projects in groups and those who prefer to work on projects alone. Those
who liked working with other people reported that they benefit from the wide range of skills that
become available to them on a group project. They also told us that group projects can save
time and allow them the opportunity to focus on their specific part of the project instead of
worrying about the entire thing at once. Those who liked working alone said that they got a
sense of comfort and control from being the only one on a project. If decisions needed to be
made, there would be no discussion, and there is no need to settle for other people’s way of
doing things. In addition to that, they said that they never needed to worry about the quality of
their skills while working on a projects because the only one who’s grade was on the line was
their own. The people we interviewed agreed across the board on some aspects of group
projects, however. They told us that scheduling in-group meetings between everyone’s
conflicting schedules could be nightmarish, and as a result, seeking collaboration online was
preferable. They also agreed, on a similar note, that some amount of organization is always
called for when working in groups. From this research, we arrived at our design principles.
Once we understood our users’ needs, motivations, and concerns, we set to work
brainstorming design ideas that could aid them in their group projects. We began with sketches,
storyboards, and scenarios to explore these ideas before moving onto our actual design.
Mid-High Fidelity Prototype | 2

4. Overview​​:
Our design consisted of five core features: the homepage, the search option, the chat,
the calendar, and the user profile. Some of the main user activities supported in our design
would allow the user to be able to see current or recent projects that people are working on,
search for a specific type of project or person, easily be able to instant message people through
the app, schedule a meeting time, and provide a description about their experience and skills on
their profile. The features of our app tie into the design principles because they offer multiple
sources of help, acknowledge the need for comfort, control, and confidence, helps students
organize their availabilities, and it helps make use of different students’ skills and experience.
Homepage
We designed our homepage to serve as being a news feed for the user to look through
current and recent projects that students are working on. It would also allow the user to create a
new post for others to see what they are working on or if they need help with a specific project.
When the user creates a new post, they would first need to title their project and write a
description of what exactly they’re looking for or what they need help with. Next, they would
select the project type and skills needed and post it. Here are some screen captures of what we
envisioned the homepage looking like along with the project post creation.
Mid-High Fidelity Prototype | 3

5. Search
For the search feature, it would help the user find other people to collaborate with easily.
The user would type in a type of project (for example: game design) and a list of possible
projects pertaining to game design would appear; the user could also type in a person’s name if
they wanted to search for someone specifically. Here is a screen capture of the search function.
Chat
The chat feature would serve the primary function of being a direct messenger in order
to make it easier for students to contact each other while using the app. There would essentially
be an option when the user clicks on someone’s profile to be able to message them. Here are a
couple screen captures of what we thought the chat feature would look like.
Mid-High Fidelity Prototype | 4

6. Calendar
The calendar in the app would help students organize their availabilities and allow them
to schedule meetings with each other. We thought a helpful solution for students scheduling
meetings with each other could be having the app sync the user’s schedule with the person they
are planning to meet with in order to help calculate a good time for both of them to meet. Here is
a screen capture of what we visualized our calendar looking like.
Profile
The profile would allow users to list their specific skills and experiences they have along
with providing a description of who they are as a student at DePaul. We thought it would also be
helpful if it had their email and phone number on their profile to provide another way of other
students to contact them. Here is a screen capture of our user profile.
Mid-High Fidelity Prototype | 5

7. Prototype​​:
The tasks that our prototype demonstrates are: allowing students to work in groups
where all of their skills are used, keeping track of their group’s progress and availability,
scheduling in-person meetings, finding students to work with, communicating with one another,
and finding projects that students are working on. These are the six user stories that our group
came up with that are represented in the design.
1. As a CDM student, I want to work in groups where each person’s unique skills are put to
use.
2. As a CDM student, I need to keep track of my group partners’ and my availability to work
on projects.
3. As a CDM student, I need to be able to schedule in-person meetings with other students
who are working on the same collaborative project.
4. As a CDM student, I want to be able to find other students to work on group projects
easily and efficiently.
5. As a college student, I need to be able to easily communicate with group partners.
6. As a college student, I want to find other projects that students are working on and
helping them with my qualifications and experiences.
Mid-High Fidelity Prototype | 6

8. Evaluation:
Our designs primary target is to create platform for CDM students to network and
collaborate on projects. Our platform provides CDM students with a very convenient application
that helps them find other students with skill sets that they need in order to complete their
projects. We also added features to help students communicate with one another as well as
scheduling appointments according to their schedules. We evaluated the effectiveness of our
design by having giving multiple users tasks and scenarios to complete. We asked them to think
out loud and provide us with any suggestions and feedback. In our low-fidelity prototype, we had
users test our paper prototype. As you can see below we made several changes on our paper
prototype.
Originally our plan was to have other student’s projects on our homepage but after
testing it out and receiving users suggestions, our group decided that the primary function of the
app would be to get help for a project, and offering help on a project was more of a minor
function of the application. So we took out our student’s projects form our home page and
enlisted the main users projects on the home page feed. We then added buttons on top to view
our projects and create a project. Lastly, we took out the search bar on our home feed and
decided to add a completely new search feature in our navigation bar on the bottom.
Mid-High Fidelity Prototype | 7

9. After testing out our final prototype with users, we realized that our calendar application
was very difficult to understand since the user cannot identify the colors and what the colors
mean. Our testers give us ample amount of feedback and ideas in order to make this easier to
understand and read
​ Before After
As you can see before the user testing we did not explain what the colors mean. This
made users very confused and did not understand the calendar and the availability. We also did
not provide the user with an appointment date. This can be also cause a lot of
miscommunication on what day the user is supposed to meet. After our testing, we took the
feedback into consideration and defined the colors by providing the colors a profile picture. The
profile picture helps identify who the color belongs to and when the other person is available.
We also added text on the bottom to identify the exact date and time when their appointment is.
Mid-High Fidelity Prototype | 8

10. Conclusion:
Overall, our group really enjoyed the whole procedure of developing a mid-high fidelity
prototype. Each step along the way was a crucial task that needed immense work in order to
come out with a high quality product. This project has given us ample amount of information and
experience on user centered design process. We had an idea and after working on it for weeks
we were able to come out with a legitimate product. This project taught us the importance of
research and design. From the research we learned how to conduct interviews and with the
information we receive we learned how to brainstorm and create insights to include in our
application. From designing the application, we learned how to create hard copy prototypes and
design a hi-fidelity prototype using Axure RP 8. Ultimately, from the help of our group, users,
and professor we were able to create a working prototype of a very useful application.
Mid-High Fidelity Prototype | 9

11. Appendix 1 - Design Patterns​​:
Tab Menu Navigation​​ - For our primary method of navigation, we chose to use the tab menu
navigation design pattern. In addition to being a pattern that most users are well acquainted
with, the tab menu navigation’s standard length fit our app’s five core features well. It maintains
an almost constant presence throughout our prototype, disappearing only for the “create a post”
multi-step form. It’s design, which made use of standard iconography choices, was received well
during testing. Considering all of this, we decided that this pattern would be ideal for our primary
navigation.
Multi-Step Form​​ - On our prototype’s homepage, under the “create a post” secondary tab
navigation selection, we have made use of a multi-step form. Initially, this form made use of pop
up menus, but was changed during testing to reduce error rate and increase effectiveness. We
believe that the multi-step form decreases confusion over the tagging system and is a good
choice for this feature.
Initial Design in Paper Prototype Final Design: Multi-Step Form
Mid-High Fidelity Prototype | 10

12. Scoped Search​​ - In our app, two of our main functions are finding other people’s projects to
collaborate on, or finding people to collaborate on your project. Due to this, we felt it might be
useful to use a scoped search in our search page so users could search by either project or
people. Users do not have to use it, and can instead just search based on keywords, but we
believe that because the search diverges by two main tasks, the scoped search was called for.
Early design idea in the paper prototype vs final version of scoped search
List Menu ​​- As a form of secondary navigation in our chat feature, we used the list menu design
pattern to organize the contacts a user has the option to message. We decided to use this form
of navigation because the number of contacts a user might have is arbitrary and may be very
long. Using a list menu, their contacts can reach any number without disrupting the design or
making it hard to understand content of the list.
Final product. The list of contacts can go on forever if it needs to, and ideally it will
have some form of creating a hierarchy (e.g. most recent, alphabetical, etc.)
Mid-High Fidelity Prototype | 11

13. Chart: Overview plus Data ​​- Our calendar feature like a chart, conveying data (availability)
between members of a project to simplify scheduling group meetings. It gives a visual overview
of availability for users to look over, as well as a legend that makes sense of the chart, and data
in the form of a calculation of the times every group member is available. This takes the work
out of coordinating busy schedules, but still allows users to follow along the logic with the simple
presentation.
The calendar feature went through lots of development, but the design pattern we used was the basis for almost all iterations.
Profile ​​- Our app rides heavily on social interaction between users, so we deemed it necessary
to have a profile feature. Using this, users can determine from the information other users
provide whether or not they want to work with this particular person. It gives a sense of control
and comfort that we found was necessary from our initial research.
Paper Prototype versus Final Product
Mid-High Fidelity Prototype | 12

14. Appendix 2 - Reflection​​:
The experiences granted by this project gave our group a good view of the general
process of user experience design. Though the process felt rushed in places, we have learned,
from the initial research to the completion of a high fidelity prototype, how to make a
user-centered design. Going forward, we hope to learn about the steps in more detail, but we
believe we now have a strong foundation to build off of.
Though our prototype may have some areas in need of improvement, we have created a
design we are all proud of. If we had had more time, there are certainly certain aspects of our
prototype that we would love to give more attention to, such as the profile’s design, the
interactivity of the calendar, or the filtering system in the search. Despite this, considering the
time we had to put into vital parts of the design process, like the paper prototype, we are
satisfied with how our project came out.
It was difficult at times to balance each group members’ individual skills. We all had
different levels of understanding of Axure as we tried to make our prototype as responsive as
possible, and some of us missed days during the process. This led to more pressure on group
members at different times over the course of the quarter, and perhaps without this we would
have been able to take our prototype even further.
Overall, we’re all confident in our ability to apply what we’ve learned during this class in
our work in the future. Most of all, we’ve gained knowledge in what to pay more attention to next
time, such as design heuristics and patterns, since we didn’t keep them in mind as consistently
as we would have liked. We’re all looking forward for our next chance to further our
understanding of the process of interactive design.
Mid-High Fidelity Prototype | 13