Meeting And Exercise 8/10

Before yesterdays exercise, we met up to finish all of our current tasks and to prepare a short presentation for class. We summarized the focal points of our design process, and rewrote our proposals (proposal 1, proposal 2) we came up with during last weeks exercise. When we began to discuss what proposal to develop further, we concluded that they both had great potential. Both proposals solve the prospect of having to tell fortunes: one by using the current system and one by revamping the current system. If we put the two together our design has the potential to satisfy all needs.

The application we intend to develop shall therefore include the following:

• If your SL Access Card has run out of money, you can pay by direct debit. When registering a crossing your card will automatically file the cost to your bank account. At the end of each month, an algorithm will calculate what SL Access Card would’ve been your cheapest option, and the amount corresponding to this card will be withdrawn from your account. For a more extensive explanation, click here.

• When you pass a turnstile using your SL Access Card, your activity will be recorded. Based on the frequency of your past travels, an algorithm will calculate what ticket is best suited for you. When your previous ticket is about to expire, you’ll be able to purchase the recommended ticket within our app. For a more extensive explanation, click here.

During the exercise, our task was to evaluate the work of group D1. In short, our impression was that their proposal didn't serve it’s purpose. They need to reestablish the physical environment in which their prototype will operate. If your target group are travelers who travel during rush hour and your goal is to reduce crowding and to lighten the mood of the passengers in the subway cart, screens in every pane of glass won’t suffice. Screens will most likely worsen crowding, especially if an interactive screen is placed by the entrance of every cart. Moreover, we don’t get how these screens will better the mood of the passengers. If people are rude, how can a screen interfere? To view all of the critique we presented to group D1, click here.

Our group was also critiqued by group D3. They thought, in summary, that our project has great potential, motivating this by the fact that they want to use our app. The only thing they criticized was the layout of our application, something we have yet to work on.

The next step in our design process is to start prototyping. Prototyping is relevant to our design process because interaction design involves designing interactive products and prototyping is the most sensible way for users to evaluate a design. With the critique of group D3 in mind, user-friendly is what we’ll be aiming for.

Evaluation: Group D1

During our fourth exercise, we were assigned the task of evaluating the work of group D1. Evaluation is the process of determining the usability and acceptability of a product or design. Since interaction design require a high level of user involvement throughout development, an evaluation enhances the chances of an acceptable product being delivered. Our task to evaluate the prototype of another group is therefor not only helpful to them, but to us as well. By recognizing errors in the design of another group, we could also recognize some faulty design choices of our own. When working with a particular design for a long period of time, tunnel vision commonly causes you to limit your perception of what is truly in front of you. This evaluation will hopefully force us to think outside the box. 

Bellow is a rendering of our evaluation of the project presented to us by group D1. In short, we don't believe interactive screens to be the way to go to solve crowding and unfriendliness in a subway cart. If someone is interacting with a screen located by the entrance of the cart during rush hour, the person will most likely cause havoc in their surroundings. The group must reevaluate the physical environment in which their prototype will operate.

User group

Is it clear to whom the service is made for? 

No, it’s not that clear as whom the service is made for. The screens show rather common messages that their target group most likely already know. It is swedes that we are talking about here, and they don’t really like to stand in the “spotlight” and it’s hard picturing users of this product on a crowded train.

Is functionality well adjusted to the particular user group? (language, difficulty level, interests)

User that travel during rush hour will probably not be interested in using an interactive screen in a crowded train.

The Feeling

What does the first impression tell? 

The project tries to eliminate large crowding, but the displays requires the user to stand rather close to the screen, and will likely encourage crowding. The placement of the screen is not ideal, since a crowd will form in front of the entrance.

Will the user stay? Return? 

They have no other option.

Does the design keep the users “all the way”?

So far this is unanswerable without a prototype.

Regular commuters might not be interested in using the interactive screens. Since they are already familiar with their route.

Interaction and over arching structure

Is it a clear flow? 

The lacking part of this design is that there is no clear plot with this project. What would they like to change with this project? Why would they want to transfer everyone from their cellphones into glass screens that may cost a fortune to replace in case of damage / repair? Why?

It’s always clear what options and possibilities the interface provides?

From the picture we have seen, yes. The design itself seems simple but can still be improved upon regarding the layout. See below.

Primary and secondary functions

Is the main functions in “focus” in the design? 

No it’s not. The main focus of the project is to make the travel more convenient by eliminating crowning encourage interaction between travellers, but by the information displayed, we believe they do not achieve this. 

Is the the secondary functions valuable or un-

necessary?

The secondary functions like news and traffic-info is unnecessary for the specified target group. Nearly all of the travellers in rush hour have access to a smartphone and can most likely access this information easily by their phone. The information displayed is therefore redundant.

Design/composition

Is functions and elements naturally grouped? 

The aisle windows seem to priorities the Twitter window before the Reseplanerare, which seems like a bad design decision since many may not be interested in Twitter that already exists

Does the design have a good structure and layout?

It’s hard to tell so far but there are topics like how to let people waiting for the train outside to see information from their side. Maybe a display that shows how crowded the entire train-car is or even destination and illustration of the whole train-line.

Suggestions for change? Remove stuff? 

Rework the project with a clear goal in mind. There seems to be no reason to force people to touch on dirty glass and always “get in the way” of other people who might want to use the screens. 

The twitter feed seems unnecessary and can be used to instead rework the screen to maybe allow people to see.

Is the design appealing to the user group? 

No. The target group is a completely wrong choice for this type of project purely because every single person in the target group can much easier access every piece of this information through their smartphone. Today, almost everyone has a smartphone with internet access and therefore can access almost everything this project offers. Judging by their illustration, the only thing that isn’t accessible is the part that shows current progress on the train and how far away it is from the next station. This is more of a gimmick then an actual project.

The design doesn’t solve their problems (crowded, unfriendly people).

Help

Is it needed? 

We think there will be a use for this, but not on the train. The platform would be a more suitable place for the screens since this won’t block the entrance to the train.

Sketches

Clear enough? Self explaining? 

We’re not sure how much information will be displayed. 

Well thought through? 

Unfortunately it seems that this project needs a bit more work and discussion within their group. The group has not thought about how the target group correlates to the project or why they should do the project at all. The group needs to rework the design a bit and decide which parts are necessary and which are not. Also, they really need to specify exactly what they want to achieve with this project and how they will work around the biggest problems like crowding, diseases, economics and how doable AND necessary this project is. Will it improve upon anything today? Does it benefit somehow to the target group?

Sloppy? 

As previously mentioned, the group needs to sit down more and talk the project through to specify a direction and ask themselves question as:

• “What do we want to achieve with this project?”

• “Will this benefit our target group?”

• “How?”

• “Do we need to narrow the project down and specify a single target group?”

Other important questions/problems/tips?

Realistic questions to keep in mind:

• How are you planning to solve the crowding problem?

• People will probably stand in the way of the screens, will this be a problem during insane rush hour?

• If a glass-screen breaks, is it worth to spend so much money to repair it for little-to-no use?

The SL Access Card Payment System

In this post, I'll be describing the details of the SL Access Card payment system, information of importance to the functional requirements and our applications usability guidelines.

The SL Access Card is a smart card storing either seasonal tickets, single zone-dependent tickets or SL Access Credit (or a combination of the above). The actual plastic card costs 20 SEK and can be reloaded as you please using a variety of alternatives. Some examples of where to charge your card are at the machines located inside the metro stations before the turnstiles, at Pressbyrån or online at sl.se.

You can, at the most, charge you SL Access Card with two tickets and SL Access Credit. If you've got multiple tickets on the same card you cannot charge your card with a new ticket until at least one ticket has run out.

When you use your card to pay for a travel the system looks for the following in written order:

1. If there is a valid seasonal ticket or zone-ticket.
2. Whether there is a pending ticket, if there is, it is started.
3. If your card is charged with SL Access Credit.

You can check the balance of your SL Access Credit in several different ways:

• At the ticket machines by the stations.
• Using Mitt SL if you've registered your card on the site.
• The card reader when traveling by bus.
• With the barrier guard, the conductor and/or the bus driver.

References:

• https://sl.se/sv/kop-biljett/

Establishing Requirements

Based on all our interviews and state-of-the-art analyses we've now reached a point in our design process where we're able to establish some very necessary requirements.

We're currently discussing the functional requirements of our design, requirements identified specifically in software engineering. During our discussions we're contemplating what our system should do. Establishing these requirements will be an ongoing process since understanding the functional requirements for an interactive product is fundamental. Thus far, our system must be able to calculate what ticket is most suitable for a specific traveler by using the statistics of the travelers previous trips. It'll also have to calculate what ticket to charge a traveler with if the traveler has chosen to pay by direct debit. The interviews suggest that travelers within our target group find these two variations to be interesting.

Data requirements are relevant to all interactive products in some way or another since they capture the essence and value of the required data. Since our prototype is dependent on the recordings of turnstile passings, the data must be up-to-date and accurate, and is likely to change many times a day. Furthermore, the data must persist over many months and probably years to be of any value to the traveler, and therefor there'll be lots of it.

Environmental requirements, also referred to as the context of use, are requirements that refer to the circumstances in which the interactive product will operate. Our application will most likely be used whilst traveling, and so the environment will, at times, be very crowded. A lot of travelers may even have to stand up for the majority of their trips. Because of that fact, using a speech interface will likely be problematic. Moreover, the subway cart can be noisy. These are some examples of the physical environment in which our prototype will operate.

Regarding the social environment of our application, the information of the whereabouts of each traveler will have to be shared and updated with each trip and this information has to be synchronous.

When it comes to the technical environment, we observed that most of our interviewees use different smartphones, and therefor our application has to be compatible with all popular smartphone brands. In order to use our application, accessibility to the Internet is also a necessity.

The key attributes of our target group, or the user characteristics, are frequent user of applications, smartphones and SL Access Cards. Therefor, an uncluttered interface using symbols is a good way to communicate information. A language option is another feature of interest since foreign students are part of our target group. The user characteristics are further investigated through our personas (Hanna, Johannes) and scenarios (scenario 1, scenario 2, scenario 3, scenario 4).

As far as our usability goals and user experience goals go we want our application to be easy to use, enjoyable and invaluable. A user of our application should feel satisfied and the experience should be aesthetically pleasing. The traveler should feel in control and the SL payment system should be very clear.

Proposal 1

The following proposal will, combined with our second proposal, make up our application solving the problem of having to know when you need to travel before you know you need to travel.

Pain Point: Price

Persona: Hanna Göransson

Scenario: 4 “Out of Cash”

Pay by Slay

Our main usability goal is to create a payment system where you’ll, in contrast to the current SL Access Card payment system, never have to worry about your SL Access Card running out of money as long as you’ve got an account (with money) connected to your card. By using our app (Slay - SL Access Yo) you’ll get to choose whether you’d like to pay using direct debit (Pay by Slay), or if you’d rather use the current SL Access Card payment system.

As far as our functionality requirements are concerned, if you choose to pay by direct debit, you’ll activate the option using your smartphone. By activating this option you’ll be able to cross the turnstile even though your card’s run out of money. When registering a crossing your card will automatically file the cost to your bank account. At the end of each month, an algorithm will calculate what SL Access Card would’ve been your cheapest option, and the amount corresponding to this card will be withdrawn from your account. Moreover, the app will also include statistics of you travel routes and costs.

For more extensive information on our established requirements, as well as our user characteristics and usability goals, follow this link.

Proposal 2

Proposal 2

Pain Point: Price

Persona: Johannes Östberg

Scenario: 5 “SL-Stats”

During the brainstorming session and time of writing this proposal we came across a very good idea that was worth mentioning here. Therefore this particular scenario does not exist on the blog, but the general consensus is that Johannes still wants to save money. In a way, this proposal will solve the problem at hand.

The smart way of saving money that Johannes Östberg wants is with the service “SL-Stats”. Every day thousands of people go through the turnstiles. There is no doubt that SL is recording all the activity and has it saved in a database somewhere. There should be no difficulties to link those statistics with an application that tracks your personal data using a smartphone. This could be evolved further to have a “Recommended ticket” based on your activity and how much you travel.

The more you travel, the lower the “cost per trip”. Either way, you will get a suggestion for a better ticket depending on how often and where you travel. Basically, travelling only once a year when you’ve purchased a yearly ticket is a waste of money.

Johannes with his fragmented and mutated leg can only today sit down and watch his statistics together with the “recommended ticket” that allows him to save money for not traveling.

A Summary of Our Design Process Thus Far

Our design process began with us reflecting on the course material assigned to our first seminar. We all agreed that a project cannot be successful if the research meant to back it up falls short and that the groundwork of today determines the outcome of tomorrow. To gathered data by conducting a survey and to analyze this data and establish necessary requirements is in other words essential to the success of any project, ours included.

By determining that open-ended or unstructured interviews with emphasis on quantitative data gathering was the way to go to gather data concerning a traveler traveling the route of our choosing, we arranged a meeting to debate what route to choose. At first, we thought the bus might be a good option, since we had a couple good ideas on how to improve the system. Later on, though, during our first exercise, we began comparing the boat option to the subway one. Since we were unable to make a final decision we opted for a strawpoll. Most of us chose the subway system as our second option (we all made two choices) and so the subway it was and our main target group had therefor been established. This target group was made more specific by us only including travelers owning a smartphone and using a SL Access Card.

From there we began discussing different ideas on how to improve the subway system and we tailored our questions keeping these ideas in mind. With those questions as our cheat sheet we conducted audio-recorded interviews and transcribed them separately. Those interviews were analyzed later on. Whilst summarizing all raw data gathered from our interviews, we categorized the data and identified the recurring patterns.

Based on our interviews, the next step in our design process was to perform a state-of-the-art analysis and so we did. These analyses were also summarized later on. Once we'd reviewed all data gathered thus far, we discussed how our project should continue from there on out. Even though most of our interviewees were pretty happy with the system as it currently is, a few of them seemed open to our suggestions.

By writing our personas (Hanna, Johannes) and scenarios (scenario 1, scenario 2, scenario 3, scenario 4), our project became more tangible. We want to change the way you think about the actual payment system. Instead of paying beforehand, and having to predict the future, why not pay by direct debit? Why not use statistics as a way of predicting the future? After coming to that realization, we listed the pain points of our primary- and secondary persona.

Since then we've had a brainstorming session where we came up with a lot of new ideas and refined some old ones. The session resulted in two ideas (one we've been discussing previously and a new one) becoming one (this will be posted on the blog shortly).

We've also reflected on chapter 13 and 15 and summarized our thought on the matter in a blog post. In short we believe the DECIDE method to be a great method to use when designing an interactive prototype and we got all of our questions answered.As for now, our next task is to establish the necessary requirements and finalize the framework of our prototype.

When it comes to the distribution of our workload, we alternate writer when we summarize each meeting and exercise, and we always make an effort to do so on time.

Seminar 2 Group Summary

Chapter 13:

DECIDE is a method of evaluation. Concordingly, each part of the method is explained in the chapter. We feel that our idea and design has gone more towards the “back-end” of the problem. We try to solve the problems and focus alot on how to it looks aesthetically.

Chapter 15:

We want to evaluate if a user will be able to actually do a payment via their smartphone. We’re currently doing a style of cognitive walkthrough where we focus on identifying specific problems of a user at a high level of detail.

Questions and discussions in the group

What makes an expert?

In conclusion, an expert can be defined by someone having education in the HCI field, if the project is dependant on HCI. A followup question can be how much experience is needed to be an expert? In theory, we are all experts by having used the SL access system for so many years. In reality, mayhaps an expert is someone who has evaluated the whole field of tickets and inspected all aspects of a system.

The question that lingers is which expert is needed for our project? There can be experts that know the programming code for the SL-Access system.

How important is it to follow these heuristics when developing a product?

Evidently, there are plenty of projects that do not use the guidelines / framework with their projects. After all, they are guidelines to serve.

How do you choose which model you use without hiring an expert?

You need to start looking at the practical issues. You can in theory follow DECIDE since they are not strictly ordered in a manner. “Identify the practical issues”.

Is it a good idea for the developer to do regular evaluations themselves and therefore save the company money by avoiding expert costs?

A company exists to gain profit. In theory every measure should be taken to save as much money as possible. It completely depends on the part that needs to be evaluated but the general opinion in the group seems that it’s completely impossible to know if an expert will be able to contribute with more valuable information and data. It’s also possible that a developer is “blind” and won’t see things that an outside observer will.

What are the risks of setting an ambiguous goal for an evaluation?

Well Hannes, you won’t get the proper results for the evaluation. If you don’t evaluate correctly you won’t necessarily get the correct information and data. There is also a chance that you may get information about other parts of the evaluation that you did not count on. It’s however a game of chance and probably not used by big companies that have alot of money invested in a product.

What are the factors that determines the scope of an evaluation?

Factors that needs to be reminded about are economy, target group, location, the scale of the evaluation. If a company does not have a good budget to spend on planning the evaluation, it will be hard to have good progress evaluating their product. The same goes for the target group - if you for example choose children as a target group you might not be able to apply the results to grown ups as well.

What is the most cost efficient way to do an evaluation?

One of the most efficient ways to save money is to limit the evaluation and the amount of experts. This however will risk the design project and may doom it purely because of a bad foundation. Not having all of the framework done and researched enough for the project will definitely be a cost-efficient way of doing it but ultimately result in failure. It’s a rocky road.

Seminar 2: Chapter 13, 15

During the work with projects and products, evaluations should be done of design functions. Depending on the goal of the evaluation, different methods can be used. The DECIDE framework is using six statements with focus on the goal, identifying the issues and thereby choosing the method and the relevant questions, and how to analyze the data. It also talks about dealing with ethical issues, such as participants’ privacy, and how it is important to keep for example personal records separated from the collected data in a safe way. By reading the report, you should not be able to identify the participants, if they haven’t given their permission. Before the test, a consent form is useful, so that the participant know all about their involvement and their rights.

By going back and forth between the statements, they are supposed to help you to choose the best ways to perform your evaluation process. Before starting the process it is important to think about all aspects, as well as who the participants should be, or if you have the right equipment, resources, knowledge or enough time to perform the chosen method.

When analysing the data, it is important to think about the reliability - how reliable the result is, the validity - if the data meet the goal of the evaluation. The ecological validity is a measures of how much the used environment has affected the result. The scope of the study says how widely the information can be used, or if the results are really narrow.

Chapter 15 gives examples of different evaluation methods where no users are needed. These kinds of models are called inspection methods. One of them is the heuristic evaluation, which is a method of testing user-interfaces, by using experts instead of actual users, with focus on how accessible the product is, e.g. if it speaks the user's language, how easy it is to use,if the language is consistent and if the purpose of the use can be fulfilled.

Walkthroughs is another method where the purpose is to predict the user problems. During cognitive walkthroughs, the participant can be told to do a task during a given scenario, while documenting the process and the occurring problems. During pluralistic walkthroughs, several experts try out a scenario together. They do the task separately, and does then discuss their different solutions to solving it.

Analystics is a method were user traffic on a system is being evaluated, which is often used by presenting statistical data. One dilemma is that the users not always are being aware that they are being “watched”. The predictive model is similar, but doesn’t involve users. Instead predictions are made based on role-plays and estimations. Two well used predictive methods is the GOMS model and KLM model.

Queston: What are the factors that determines the scope of an evaluation?

Seminar 2: Chapters 13 and 15

Chapter 13 introduces the DECIDE framework, a concept made up of six steps to help you plan for an evaluation study. These steps include everything between determining your goals to presenting finalized data. 

Before conducting a study using the DECIDE model, there are plenty of issues you need to take into account: What are your goals? and How should you collect the data? are just two examples of questions you need to answer. Moreover, you should deal with its items iteratively, the reason being that any decision concerning one item of the framework could impact all of the other items as well.

I find this concept to be very intuitive. It’s a great method to use when designing an interactive prototype. Since the perspective of the user can get lost in the whirlpool of ideas, this framework keeps you at bay. The DECIDE method is definitely something to put to use further down the line.

Furthermore, we need to establish what it is we want to do. We aren't able to conduct lots of field studies (due to a very short time frame), neither will we be able to perform a lot of usability testing. We've got plenty of ideas but we need to narrow them down. What is possible? What isn't? The DECIDE method can most definitely be out guiding hand when making these decisions.

In chapter 15, heuristics and walkthroughs are introduced as two inspection evaluation methods offering the evaluator a structure to guide the evaluation process. Heuristics includes any approach to problem solving and learning that employs a practical method sufficient enough to fulfill the immediate goal. Walkthroughs are the alternative approach to heuristics, enabling you to predict users’ problems without doing user testing. Since users aren’t always easily accessible, specialists or experts are sometimes assigned the task to role-play user interaction with the design or prototype to be evaluated. This allows for efficiency whilst still being provided with feedback.

I think we could put both of these methods to use in our design process. Since we don’t have a lot of time performing tests on actual test subjects, constructing a walkthrough could provide us with the necessary data whilst still being time efficient. Combining these methods with practical testing would probably be best though, since testing and heuristic evaluation often reveal different usability problems. Experts are, well, experts, they know how a system should work, non-experts don’t.

Question: What makes an expert?

Seminar 2: Chapters 13, 15

HCI Seminar 2 - Reflections Document

Chapter 13:

This chapter introduces the framework DECIDE.

“Determine the goals, Explore the questions, Choose the evaluation methods, Identify the practical issues, Decide how to deal with the ethical issues, Evaluate, analyze, interpret, and present the data.”. The chapter investigates the meaning of each point in the framework. The framework is made to help create a proper evaluation of for an example a software product. The evaluation being HCI related, in other words it is an evaluation of the usability from a users perspective. Analysing a user’s behaviour can reveal problems in the design, which is important to handle as early as possible so it's not as expensive. An evaluation can be useful not only to find critical errors, it can also improve the user experience if the developers choose to develop their product according to the result.

The DECIDE tool is a good platform to start on when you have realised that an evaluation might be required or beneficial. I will probably go back to this section if or when we do an evaluation on our project.

Chapter 15:

This chapter entails on different evaluation methods. It is mostly based on heuristic models, which means that experts pretends to be the user and try to anticipate where the user might go wrong and also what might be frustrating to the user. The chapter discusses the accuracy in finding problems based on how many experts you employ. Different walkthrough options are also discussed, a walkthrough being how experts might approach a user interface. There is also a part that talks about analytical tools. Such as web tools for analyzing traffic data etc. How statistical data might be useful to create a good user experience for your website and to analyze if your marketing is working the way you think. Predictive models are also covered in this chapter, such as GOMS and KLM. Both designed to try and predict how time consuming a task is.

Question: Is it a good idea for the developer to do regular evaluations themselves and therefore save the company money by avoiding expert costs.

My own opinion: Regular evaluations at every step of the design process seem more beneficial than one large evaluation. Because programmers know that fixing the previous problems might cause new ones.