Summary of the Project and Final Reflections

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.