|
Overview:
This is the general description - there are
two
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.
There is also a set of hardware rules.
The pre-made options are
a kiosk for the Iribe Center
and
a 'Smart' Refrigerator and Mobile App.
More details about the options will be discussed in class Zooms.
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"
or "pitch" 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. 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."
This sub-phase will be due by
11:59pm on September 13th.
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.
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.
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.
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 by
11:59pm on September 20th.
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.
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.
Each team will need to meet with their UGTA "senior manager" during
the first half of the week of
September 27th
to discuss their progress and any artifacts that
have been created. 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. However, they are not there 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
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.
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 by
11:59pm on October 4th.
Important Mindset Note
We are not looking to design simple HTML pages in this course
or to limit ourselves to what easily fits inside a browser.
Additionally, modern design requires consideration of
multiple display sizes and orientations.
For this reason, the default rule for your project is that your
project cannot be something that looks like it would be a web page,
and that the UI prototype may not be assumed to be of a browser-based
product even though you might be prototyping for Chrome.
Basically, you should undertake your entire phase 1 assuming
that you will not be using a browser when you
implement the interactive prototype in phase 2 even if in the end
that's what you use.
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 9 of the 40
percentage points that the team project makes of the
semester grade.
|
