Problem
analysis & field studies
The
premise of the course was to create a product (up to a prototype) for
a particular problem encountered on a geographic site connected to
public transportation. We picked the ferry line between Slussen and
Allmänna gränd for our project,and our target group would be
foreign tourists or first time visitors. To formulate a problem we
first did a pilot study to get a feel for the place through
observation
and unstructured
interviews.
This enabled us to formulate more exact questions, which we posed to
travelers on the line a couple of days later in more structured
interviews.
The gathering
technique
used was very basic. We worked in pair and while one of us was asking
questions, the other one wrote down the answers. A more advanced
gathering technique like video or audio recording seemed to us too
intrusive and therefore counter productive. A challenge was to
formulate an idea based entirely on the empirical
data
that we recorded during our field work without prejudice. The first
step was to categorize
our data for qualitative
and quantitative analysis.
We tried to group similar problems together and count the occurrences
of each problem. Since different subjects expressed themselves in
different ways we had to interpret the answers to know if there were
any recurring
patterns.
The problems that most people faced were:
- How do I purchase a ticket?
- Where do I go when I get off the ferry
- What activities are there in the city?
In
conjunction with contextual interviews, state of the art analyses
were conducted. The purpose of them was both to trigger the
imagination and perhaps also to steer us away from creating a design
that already exists. We concluded that there are no current solution
that solves all of the above mentioned problems, that most travel
guides rely on an internet connection and no current solution have
asian languages.
Persona
and Scenarios
Based
on these problems we set out to create a requirements
specification,
and the usual way to do this is through personas.
Personas enabled us to embody the problems and see them in practical
action. We could better analyze user
experience goals
and through informal
narrative description
we could formulate human
activity
in a specific context.
In retrospect our attempt to formulate two different personas was
very successful. We wanted to include a broad spectrum of potential
users with different consumer technology skills and interests. Our
main persona Sonya was an early adopter, which means that she had an
active interest in new technology and used it whenever she could. Her
setting was that of a family vacation in different degrees of
turmoil. Already here it became apparent to us that our solution must
fit in a situation
with many conflicting desires, be available and seamless with high
quality usability.
Our secondary persona, Luis, was put in a more lonely setting and his
indifference to technology prompted us again to create something so
easy that it barely could be described as technology but rather a
second nature.
By
creating personas we automatically line up with the recommendations
in ISO-9241-11 that points out the importance of defining usability
in terms of user
goals
and context
of use.
In this case we are all the time focusing on practical issues of
navigation for tourists. User
centered systems design
has the strength that it forces developers to envision themselves in
somebody else's situation. We are not developing tools for ourselves
but for users whose needs and predispositions are very different from
ours. Now at the end of the course one can see that we have followed
the the core idea of UCSD by involving users throughout the entire
project but since the project was short, we could of course only make
few iterations of involving users. These were the think aloud method
and in some respect the evaluation by other students.
Designing
& prototyping
Here,
at the first brainstorming session, we became ready to establish the
first requirements and begin the first cycle
of prototyping.
The session included collaborative iteration and parallel design. The
first segment, collaborative iteration, was meant to produce all
imaginable ideas, from the most concrete and practical to the most
wild and unrealistic. The idea at this stage is to encourage
reflection,
shut off the common censor, and by allowing input from every group
member by turns, encourage participatory
design.
This technique proved useful as members with otherwise good ideas but
quiet personalities could make themselves heard. How to make use of
introvert personalities is a contemporary managerial question and
although strictly speaking group dynamics is not part of the course,
this problem still surfaces, especially since a mayor component of
the course is the peer feedback. This technique took some load off
this problem.
With
some results now available, we decided to focus on a mobile app with
a complementary screen that would be spread out across the city and
used on its own or together with the mobile app. We were looking to
create an all-in-one package that could solve ticket, navigation and
activity finding issues. With these guiding principles we went on to
the second segment, the parallel design, in which we divided into two
groups each creating sketches
through paper
prototypes.
By using post-it notes in different colors ideas could be quickly
created and organized into a conceptual
design.
The two groups spontaneously and unconsciously worked on different
aspects of the prototype, one focused on content and the other on the
interface. After a third design concept some days later, we took the
best aspects of each prototype and combined them into a final
prototype idea. Our design had become a mobile application that
through a browsing interface presented the user with various
activities and a navigation system to take him or her there. It also
included a ticket buying system for transportation and an augmented
reality mode for recognition and description of famous sites.
Evaluation
The
main evaluation session took place during an exercise with one of the
other groups acting as an evaluator
of
our design. Usually, an expert
evaluator denotes a person trained in evaluation with extensive
experience of judging designs and theories about proper design
choices. Our comrade students could hardly be called experts in this
sense but as computer science undergraduates, they neither could be
called laymen, so they took on the role as expert in evaluating our
design using some kind of frame work to come to conclusions. It is
not known what method was used by our evaluators to make the
judgements. We were just handed a list of positive and negative
aspects of our design. At least we know the tests were conducted in a
highly
controlled environment,
since they were conducted by experts.
Our
own evaluation strategy was based on Nielsen's
rules of thumb,
a checklist of features a good design should have, and an approach
which is a part of the heuristics
method. Before embarking on this formal approach we made a quick
walkthrough
of the design, intuitively imagining how it would be to use the
design in real life by embodying different roles and intentions. The
design we critiqued was a system for buying tickets for public
transport, which basically was an interactive touch screen. There are
many other evaluation methods, some more and some less relevant for
this course since it is limited in scope and time. The KLM
method, used for measuring the time it takes for each key stroke,
swipe, etc, to complete a task, would prove itself pointless as it is
tedious and differences in micro seconds between designs would not
register for our purposes. A cognitive
walkthrough
on the other hand, a method for studying how a small aspect of a
design helps problem solving, could be interesting as problem solving
of a practical issue of transportation is a marked premise of the
course. Next followed a more concrete
design
of our paper design in a relatively low-fidelity
prototype using
the tool
myBalsamiq.
The purpose was to get our ideas on screen and connect its different
parts into a preliminary whole.
This
prototype was taken for a test drive using think aloud sessions where
subjects commented on our design in real time while navigating around
it. It became apparent that while the problems that our project was
based on were all addressed, there remained inconsistencies in some
of the design elements. To properly handle this we chose to switch
prototype tool to Flinto.
Design
critique, design iteration
We
presented our low-fidelity prototype during an exercise and got some
new feedback, making this yet another iteration
of the design process. Similar issues came up this time as during the
think aloud sessions but more importantly we got some esthetic
feedback that concerned symbols on the screen. For instance there
were some issues with the cogwheel button that takes the user to the
settings page. This critique turned our attention to images and our
final design has far more pictures than our first one. At this stage
we began to study general design theory to back up our design choices
with literature in the subject, while using Flinto and Photoshop to
create a high-fidelity prototype.
Final
thoughts
Our
estimation is that we did a good job, both regarding the project
process and final prototype results. We met regularly and structured
the work load evenly with everyone performing their part. If only one
thing would be taken away from the course as its most valuable
lesson, it might be the UCSD approach to product development. By
working closer with the users we were able to create something useful
not only in theory but also in practice. It shows how developers and
end users can disagree in their understanding of the concept of
usability. This does not mean that the practical side of design dominates the theoretical side, the theoretical idea of practical engagement with end users is just as important. Without the ability to link practice to its theoretical component, practice can become automatic, contingent and lack self awareness. The strength and elegance of UCSD then is the theoretical formulation of the primacy of (end user) practice. For computer science engineering is spreading to virtually every
sector of the economy and culture everywhere. It will become
important that developers can keep the integrity of each sector so
that computers and software work for them and not the other way
around.
