Overview:
This is the general description - there are
four
specific pre-made project options
to make things a bit more manageable,
but within each there is much room
for each team to shape it in this phase.
There is also a set of hardware rules.
The pre-made options are
a kiosk for the Iribe Center
and
a "Kitchen Kompanion" app centered on a home's refrigerator and other kitchen concerns.
and
an integrated Health-themed Mobile App
and
a tablet advising app for Computer Science majors.
Teams are expected to have 4 students
and have to pick one of these options.
More details about the options can be discussed in class.
The overall purpose of this phase is to give you experience at:
* articulating a proposal for a project
* communicating with potential users about their needs
* exploring related technologies and conventions but not limiting yourself to them
* constructing and conveying good task descriptions
* constructing and conveying good sample user personas
* using the task descriptions to decide upon
system requirements,
* brainstorming low fidelity prototypes based
upon the above, and
* evaluating the ideas and prototypes with
potential users
In Phase 1.1 you will form your teams around a project option
and submit an initial "pitch-back"
where each team will describe (in two pages or less)
their project as they see it, including its overall audience
and overall goals, all presented in the team's own words.
For the goals, you should be able to describe at least three
primary goals, and potentially more (and/or some secondary
goals).
You will need to express why your team feels the application
is needed (ie: what need or hole in the market would it fill).
You will need to be able to provide a list of types of users
of your system that are somewhat generic yet provide example details.
Rather than "My photography friend Sam."
we want to see things like "An avid freelance photojournalist
who wishes there was a way to add more credibility to his
photography."
You should also make a tentative decision on the development platform
and then work on Homework #2 individually using that platform.
This sub-phase will be due before 11:59pm on
February 6th
As the Phase 1.1 submissions are being reviewed,
you will begin work on Phase 1.2 where you continue to
think about your project option, potentially updating the
pitch, but most importantly investigating your users and
their needs more,
building 2 to 3 example user personas
and writing up 4 to 6 full task scenarios
(we will discuss what these are in class)
that you envision represent some of the situations in which
people will use your system.
A PDF containing these personas and task scenarios will
be the deliverable in this sub-phase.
You will be expected to speak with some example potential
users and/or stakeholders of your system during this sub-phase.
In your write-up, indicate the type of people you spoke with
(for example "a junior who is a female CS major who lives in
a quad apt with a single refrigerator") and whether they inspired
any of your scenarios or personas.
Also, indicate why you chose it as an important scenario example.
At least 2 of the full task scenarios that you include must be inspired
by example potential users and/or stakeholders.
This phase of the project is a hands-on exercise on project
ideation and task-centered design and prototyping, which is
the first step in an iterative user-centered system design.
Fundamentally, this means that you begin your design around
a concept by getting to know the intended users, their tasks,
and the working context of their actions.
Only then do you consider what the actual system's design
should look like, basing the design on real people, real
tasks, and real needs.
User centered system design is not an academic process where some
cookbook formula can be applied. There are research-based and
practice-based techniques that you will apply, but it will be
important not to approach things with a "checklist" mentality.
It is also not typically an "intuitive" process where a programmer
will sit in their office and imagine who the user will be and what
their tasks might be.
Rather, it is a hands-on process that requires you to go out and
identify actual potential users, talk with them about what tasks
they are trying to do or wish they could accomplish, and understand
the entire context of their work.
You then base your designs on this information.
Additionally, the underlying infrastructure of software is often
shaped by the design of the user interface and experience, which is
why we undertake this design work the way that we do in this course.
Lewis and Rieman wrote of HCI,
"It just won't work to build a complete system and then,
in the final stages of development, spread the interface over it
like peanut butter."
As you are working through this design process you will work to identify
potential usability problems by continually evaluating your design and
by crafting new designs.
This is called iterative design.
This sub-phase will be due before 11:59pm on
February 13th
With this more complete view of your project, phase 1.3 will
have each team work
and create a set of paper prototypes reflecting several rapid
iterations on their ideas, the team's brainstorming on how to
support the users, as well as ideas from some of the example
potential users you show these prototypes.
While these paper prototypes do not need to be perfect, they do
need to demonstrate thought and care and an eye towards realistic
elements.
In this sub-phase, you will begin your iterative design of
your system, continuing to talk with people and showing them
your low fidelity prototypes.
Your task scenarios might need to be updated as you learn
more during these iterations.
You will be continuing from this design in phase 2, so it is
important to do this phase well.
The project option descriptions attempt to discuss things in
a realistic, full-application manner.
When we get to phase 2 we will discuss things such as what parts
of the back-end can and should be simplified or even which tasks
or interactive elements might be too complex to implement in the
next phase. However, for this phase we want to focus on what the
software should look like in an ideal current world.
You should have at least three screens
prototyped. These need to demonstrate three distinct, representative
features that your final product will have. At least one, though
preferably more, need to show thinking about non-trivial interactions
the user will have with your final prototype (ie: think data entry).
Each team will need to
virtually meet
with their TA "senior manager" during
the week of
TBA
to discuss their progress and post any artifacts that
have been created in their team channel on Slack.
During these meetings, the TA may offer ideas
and suggestions based on what you show them. They might point
out an important element that they feel is required for the
current stage.
With the exam being in the same week, this semester
we will offer you the opportunity to upload your
low-fidelity artifacts
as they exist by February 22nd to your team channel on
Slack if you would like any quick feedback on where
your team is so far.
However, this
optional
feedback opportunity is not to detail everything
that should be done, since discovering this is part of your work,
and different teams might choose to focus on different approaches
or audiences depending on the option. If in great doubt, arrange
to meet with me with some well-developed questions, and I'll be
happy to provide my input.
The outcomes of this user and task-centered prototyping phase
is a design portfolio containing:
* an updated list (if needed) describing
the expected users of the system and their work contexts
* a list (if needed) of actual,
representative tasks that people are expected to do
* a prioritized list of system requirements
* a low fidelity prototype
* a brief (one to two page) discussion of the
user feedback about your prototype
* a list of primary features and of secondary features
that you imagine the final product would have.
* a preliminary style guide
(color palette, typography, iconography,
buttons, pop-ups, etc) - this is something that will evolve as you move
forward in the phase, but having one at this point should help you start
on a thoughtful path
You can see
an example of how you could express your style guide here,
but please note that the actual style choices it shows
are BAD one. Your style guide should show good style choices.
When we ask for a prioritized list of system requirements
above, we primarily mean a list of things that people will be able to
accomplish/do/experience via what you are designing (not things like
screen resolutions).
Your PDF will contain photos of the low fidelity prototype(s)
the team created (you will keep the actual paper prototypes to
potentially show others, probably by pointing a webcam at them during
a videochat).
You will also need to submit a public "who did what" one page summary of
who in the group did what in this phase.
This sub-phase low-fidelity prototype bundle will be due before 11:59pm on
February 27th
Important Mindset Notes
As your team works through this phase, please keep in mind that
this semester-long project is more than "just a coding project."
You are starting from an idea with goals and a context and
are designing and expanding from there.
In this phase you will delve into the larger context and
things such as
understanding and expanding on your specific posted option,
identifying the likely categories of target users of the end product
and getting to understand more about their needs and abilities and contexts,
constraints presented by the posted option's details,
and shaping your design ideas based on these understandings.
As part of your design thinking,
you will likely need to consider things like user distance to screen,
needs such as supporting users who do not have 20/20 vision,
many aspects of the diversity of your users,
as well as both visual and tactile interactions with all options
using touchscreens.
In this phase, be sure to keep the platform of your option solid in your mind
(smartphone app or lobby kiosk on a large touchscreen) and do not allow your
eventual Phase 2 development platform to skew your overall design here.
For example, even if your team has decided to use HTML/CSS/Javascript to have
your Phase 2 prototype "live" in a Chrome browser,
you are not designing a webpage/site (that would involve very different
metaphors, constraints, etc).
You would do best to undertake your entire Phase 1 without assuming
that you will be using a browser when you implement the interactive
prototype in Phase 2
(even if in the end that's what you use)
to avoid thinking about things as they might appear or behave if
done as a website.
As you work on your design, please keep in mind that
you cannot "farm" elements out to existing services.
As some examples, shopping lists in the Kitchen Kompanion
cannot be handled by an external resource such as
Amazon shopping,
the Iribe Kiosk and CS Advising app cannot embed any
CS or external campus resources as interactive features,
and the Health app cannot redirect the user to existing
sites for videos or health information.
Grading Note
Grading will be based upon things such as the
sophistication and maturity of the work,
the elegance of the designs and how they reflect
real users and tasks,
the logic of the written presentations,
and the completeness of the work.
The elements of this phase will be worth
6 of the 40
percentage points that the team project makes of the
semester grade.
|