Department of Computer Science and Engineering 

CHALMERS UNIVERSITY OF TECHNOLOGY 
Gothenburg, Sweden 2017 

 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

Making an Internship Management 
System More Usable 
A Usability Study for An Internship 
Management System 
Master’s thesis in Interaction Design and Technologies 
 

ALEXANDER CHAU NGUYEN 
MENGHAN XU 
 



  II 

REPORT NO. 2017:9 
 
 

 
 

Making an Internship Management System 
More Usable  

A Usability Study for an Internship Management System  
 

 

ALEXANDER CHAU NGUYEN 

MENGHAN XU 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

Department of Computer Science and Engineering 
CHALMERS UNIVERSITY OF TECHNOLOGY 

 Gothenburg, Sweden 2017  



  III 

Making an Internship Management System More Usable  
A Usability Study for an Internship Management System  

 
ALEXANDER CHAU NGUYEN 

MENGHAN XU 
 

 
 

© ALEXANDER CHAU NGUYEN, 2017.  
© MENGHAN XU, 2017.  

 
 

 
 

 
 

Technical Report No. 2017:9 
Department of Computer Science and Engineering 

Chalmers University of Technology  
SE-412 96 Göteborg  

Sweden 
Telephone + 46 (0)31-772 1000  



  IV 

Acknowledgements 
 

First of all we would like to thank our academic supervisor Fang Chen from Chalmers 
University of Technology, who supported and guided us.     

...Second, we would like to thank our supervisor Martin Hjulström at GR, who gave us 
invaluable advice, and looked for users for us. 

...Third, all the participants who took time out of their lives to be our interviewees and test 
users, thank you very much! 

...Last, we wish to thank GR and Rasim Avdic for giving us the opportunity to participate in 
this wonderful project. 

 
 

Gothenburg, May 2017 
Alexander Chau Nguyen & Menghan Xu 

 
 

 
 

 
 

  



  V 

Making an Internship Management System More Usable  
A Usability Study for an Internship Management System  

ALEXANDER CHAU NGUYEN 
MENGHAN XU  

Department of Computer Science and Engineering 
Chalmers University of Technology  

 
 

 

Abstract  
Praktikplatsen.se is an internship management system that is used by schools, businesses and 
Göteborgsregionens Kommunalförbund (GR) to provide and manage internships for students 
of all ages. The team who handles the tool, has a support section in the system which is 
frequently used by many of the users. They want to reduce the amount of support errands, 
which is why they have requested an analysis of the system to find usability problem and 
design suggestions on how to improve it. 

With the problem in mind, this study aims to make Praktikplatsen.se more usable for school 
administrators who experienced the most usability problems of all the users. The thesis 
proposes a list of problems that have been found and solutions to the them which are 
presented in the form of guidelines and a high-fidelity prototype shown as screenshots in this 
report. In order to accomplish this, the project was divided into two phases, one research and 
analysis part to identify the usability problems, and one design and evaluation part to develop 
a good solution to the problems. The first phase consisted of user research methods and data 
analysis to collect data. The data was then evaluated with the KJ method and experience 
mapping to get a list of critical usability problems. Further, the results from the first phase 
was used in the next phase to design solutions. The design was first made in the form of a 
low-fidelity prototype which was evaluated with usability testing and then re-designed into a 
high-fidelity prototype. Evaluation methods were used after each design step to refine and 
finalize the prototypes. This resulted in a design that is very close in “look and feel” as the 
end product. 

 
 
 

 
 

Keywords: internship management system, usability study, user experience, human-centred 
design, interaction design 



  VI 

Table of Contents 
 
Acknowledgements IV 

Abstract V 

Introduction 1 
1.1 Research aim and question 1 

1.1.1 Scope 2 

1.1.2 Limitations 2 

Background 3 

2.1 Internships in Sweden 3 
2.2 Praktikplatsen.se 3 

2.3 Stakeholders 4 
2.3.1 Users of Praktikplatsen.se 4 

2.3.1.1 School administrators 5 
2.3.1.2 Business administrators 5 

2.3.1.3 Praktikplatsen.se administrators 6 
2.3.1.4 Students 6 

Theory 8 
3.1 Human-centered design 8 
3.2 User experience 9 

3.3 Complicated systems 10 
3.4 Usability 10 

3.4.1 Usability of complicated systems 12 
3.5 Design of websites 13 

3.5.1 Interaction design 13 
3.5.2 Information architecture 16 

3.5.3 Navigation design 16 

Methodology 18 
4.1 Ethnography 18 

4.1.1 Interviews 18 
4.1.2 Observation 19 

4.2 Data analysis 19 



  VII 

4.3 Brainstorming 19 
4.4 Affinity diagram 20 

4.5 Personas 20 
4.6 Experience mapping 20 

4.7 Sketching 21 
4.8 Prototyping 21 

4.8.1 Low-fidelity prototype 21 
4.8.2 High-fidelity prototype 21 

4.9 Usability testing 21 
4.10 Heuristic evaluation 23 

4.11 Perspective-based UI inspection 24 

Design Process 25 

5.1 Phase I - Research and Analysis 25 
5.1.1 Ethnography 26 

5.1.2 Data analysis 26 
5.1.3 Usability test 27 

5.1.4 Heuristic evaluation 30 
5.1.4.1 Study 1 30 

5.1.4.2 Study 2 30 
5.1.5 Affinity diagram 30 

5.1.6 Experience mapping 31 
5.2 Phase II - Design and Evaluation 33 

5.2.1 Iteration 1 33 
5.2.1.1 Personas 34 

5.2.1.3 Brainstorming 34 
5.2.1.4 Sketching 35 

5.2.1.5 Low-fidelity prototyping 36 
5.2.1.6 Usability test 36 

5.2.2 Iteration 2 37 
5.2.2.1 High-fidelity prototyping 37 

5.2.2.2 Perspective-based UI inspection 38 

Results from user studies and data analysis 39 
6.1 Ethnographic study 39 

6.2 Data analysis 41 
6.3 Usability test 43 



  VIII 

6.3.1 Test 1 43 
6.3.2 Test 2 44 

Usability problems and design solutions 46 
7.1 Problems and solutions 46 

Problem 1: Cannot find functionalities 46 
Solution 1: Shortcuts 46 

Solution 2: Buttons to the right 47 
Problem 2: Complexity 47 

Solution 1: Clear buttons and simpler workflow 47 
Problem 3: Memorability 48 

Solution 1: Overall timeline 49 
Solution 2: Page specific timeline 49 

Problem 4: Language 50 
Problem 1: Menus 50 

Problem 5: User interface 50 
Solution 1: Help the users understand 50 

Problem 6: Export/import 51 
Solution 1: Saving configurations 51 

Problem 7: Missing functions 52 
Solution 1: Student management 52 

Solution 2: Advanced search bar 52 
Solution 3: Standard email functionality 53 

7.2 Guidelines 53 

Discussion 55 
8.1 Research question 55 

8.1.1 Generalizability 55 
8.2 Application of theory 56 

8.2.1 Design process 56 
8.2.2 Usability 56 

8.2.3 Web design 57 
8.2.3.1 Interface design 57 

8.2.3.2 Information architecture 57 
8.2.3.3 Navigation design 57 

8.2.4 The importance of user experience 58 
8.2.5 Similarities with complicated systems 58 



  IX 

8.3 Design insights 59 
8.3.1 User research 59 

8.3.2 Evaluation methods 59 
8.3.3 Personas 60 

8.3.4 Prototyping 60 
8.4 Future work 61 

Conclusion 62 
9.1 The first part of the research question 62 

9.2 The second part of the research question 62 

References 64 

Appendices 67 
Appendix A - Interview & Observation 67 

Appendix B - Usability problems (and more) from interviews 69 
Appendix C - Data analysis of Google analytics 78 

Appendix D - List of usability problems 81 
Appendix E - Test Plan - FINAL 83 

Appendix F - Summary of usability test I 92 
Appendix G - Heuristics evaluation results 105 

Appendix H - Transcription for Perspective-based UI Inspection 112 
Appendix I - Tasks for the 2nd iteration of usability test 118 

Appendix J - Perspective-based UI inspection results 120 
Appendix K - Current views of Praktikplatsen.se 122
  

 
  



 

 
1 

1 
Introduction 

Nowadays, finding internships or a summer jobs to enhance competitiveness before their 
graduation has become an increasing tendency. For university students, doing internship is a 
way to have a greater chance to find career in the future, but for elementary school and high 
school students, internship is a way to understand different divisions of social labour so that 
the students can find their own interest among different areas. That is, they will establish their 
goal of future and not completely be in the dark when choosing a major after graduation. For 
university students, it will not be easy to find a job via social recruitments, because a large 
number of companies will require working experience before a candidate apply for the job. 
Students will face some obstacles if they lack of real-world experience (Hurst et al., 2014).  
Because of today’s omnipresent technologies, a large amount of job hunting websites are 
available on diverse platforms. These websites gather information from different companies, 
and the job seekers can search jobs according to different categories, such as location and 
experience level. However, the job hunting websites are to a large extent for people who are 
over 18 years old and have behavioural competence. Elementary school and high school 
students who are willing to find an internship cannot find proper internships on these 
websites.  

In this master’s thesis, we will mainly focus on how to improve the usability of an internship 
management tool which is developed by Praktikplatsen.se which can also be considered as an 
internship management tool whose target groups are mainly elementary school students, high 
school students, university students and administrators because finding an internship is a 
mandatory part in the curriculum. There are two parts in the website which include student 
platform and administrator platform. In this project, the task is to improve the usability of the 
administrator’s part.  
During this thesis we have found out that internship management systems are complicated in 
general, which is why a small part of the report will also have focus on complicated systems 
and its similarities with Praktikplatsen.se. 

There will be eight parts in this report. In the first part, we will bring out the research question 
and the research problem which will be answered and solved in this master’s thesis. Second, 
the background of the master’s thesis will be elaborated. Theories and methodologies that 
would be applied to the project will be described in the third and fourth part respectively. In 
the fifth chapter, a detailed time plan and design process will be presented. In the sixth 
chapter, the result of the project will be presented. Some design insights and issues will be 
discussed in the seventh part. In the last part, a conclusion will be made. 

1.1 Research aim and question 
The research problem is about finding out difficulties and problems that school administrators 
experience when they are using Praktikplatsen.se. The system can be considered as a 
complicated system and requires training before usage and that is why it is inevitable that 
some usability problems occur for a certain amount of users. When problems occur, the 



  2 

support team is usually contacted which leads to higher costs for Praktikplatsen.se. Since 
there are deadlines to be met and time constraints to planning and managing, it often leads to 
a disturbed workflow for the user. With this problem area in mind, a research question was 
formed which consists of two parts:   

“How to identify usability problems in an internship management system and 
design it to increase usability for school administrators?” 

The first part of the research question is about an exploration of finding the usability problems 
in a complicated system like Praktikplatsen.se, while the second part is about how to design 
for, and make such a system more usable by reducing the found problems in order to ease the 
operational burden for the support. 

1.1.1 Scope 
This master thesis will result in a list of usability problems that exist in the current system and 
these problems will be summarised from the user research in the first phase. The detailed 
design concept will be described by high-fidelity prototypes which are aiming to solve the 
usability problems. Since there will be some other design details that cannot be shown in the 
high-fidelity prototypes, the report will also include some design guidelines that can be 
referred to in future development. 

1.1.2 Limitations 
Different kinds of administrators use different parts of the system, which is why this project 
had to be limited to certain parts of the complicated system. Students who apply for 
internships also see different views than the administrators, but Praktikplatsen.se did not want 
us to focus on those users since they only use a small and simple part of the system. Time and 
budget would not allow for an thorough analysis and design of all parts, so that is why finding 
out which part to focus on was the first step in the project. 

School administrators is the category that was chosen and studies only concerned schools and 
educations in the Gothenburg area, and mostly schools with specialization in health care 
programs which has more internships than other programs. 
In this thesis we included information architecture, but because of time limits we only focused 
on navigation design from that principle. 

 

  



  3 

2 
Background 

In this chapter, background of project be introduced. There will be three parts in this chapter. 
In the first section, how internships in Sweden works is presented. In the second section, the 
system of Praktikplatsen.se will be described. Lastly, Stakeholders and the relationship 
among them will be presented. Specifically, the different kinds of users of the system will be 
introduced. 

2.1 Internships in Sweden 
Internships are offered in many of the different educations in Sweden. In the vocational 
programs in high school for example; at least 15 weeks of the program has to be done at a 
workplace (Skolverket, 2016a) and some high schools with special apprenticeship programs, 
offer as much as vocational training 2-3 times a week (Katrinelundsgymnasiet, 2017). 
Vocational training is important to the schools and they need to give a lot of support to the 
students so that they can do the internships without any problems. Competent supervisors are 
assigned to the students and the school and its teachers has the responsibility to make sure 
that everything is going well. This is done through workplace visits, student feedback and 
continuous communication with all involved parts (Skolverket, 2016b). 

2.2 Praktikplatsen.se 
Praktikplasten.se (See Figure 2.1) is a digital internship management system for internships 
and other forms of collaboration. About 12000 internships are handled every year through this 
tool and it is used mainly by students in elementary school, although the target groups also 
include different kinds of administrators, employers and higher education students. 
Praktikplatsen.se was relaunched in July 2015 and is based on an old platform. 

Students use the website to submit their wish list. Administrators are in charge of matching 
the students with proper internships. Employers will go the website and publish new 
positions. The website, in this case, is an intermediary among these roles, which tries to fulfil 
the requirements from the users. As the system has to provide services according to different 
roles, it might cause some problems which make the users feel perplexed. This is also the 
purpose of doing this project which was mentioned in Chapter 1.1.  



  4 

 

Figure 2.1. Praktikplatsen.se  

2.3 Stakeholders 
Stakeholders in this master’s thesis include students and administrators who come from 
schools, companies and GR (Göteborgsregionens kommunalförbund). GR is the provider of 
this project as well as the producer of Praktikplatsen.se. Administrators are the most 
important part of the stakeholders in the project, since we will focus on the usability 
improvement of their part in the system. 

School administrators coordinate among students, businesses and Praktikplatsen.se. They are 
responsible for managing students and managing internships. They are a significant part of 
the administrator users. Praktikplatsen.se administrators are coordinators between schools and 
businesses. They are responsible for providing the training courses, planning internship 
periods and support the other administrators when they meet problems. Administrators from 
businesses were only involved in a smaller scale, because they do not use the system to 
upload information frequently. Instead of which they usually call the administrators at 
Praktikplasten.se and tell them how many students they can accept and when they will 
provide internships, so that the administrators can upload this information on the website. 
Students are also main users and uses the system as a tool. They have to find a proper 
internship that is suitable for them every year with this tool in order to fulfil the requirements 
from school. As mentioned in Chapter 1.1.2 about limitations, the students and the student 
portal will not be focused on in this project. More information about different kinds of users 
and their different perspectives will be explained in Chapter 2.2.1. 

As the mission was provided by GR, the result would be used mainly by them to improve 
praktikplatsen.se for their school administrators and also lay ground to future projects.  

2.3.1 Users of Praktikplatsen.se 
The system has different perspectives and is used by several kinds of administrators, all of 
them seeing their respective configuration of the same views. The administrator perspectives 
can be split into three main categories; Praktikplatsen.se administrators, business 



  5 

administrators and school administrators. Separated from the administrator perspectives are 
the students who has a simpler interface. 

2.3.1.1 School administrators 
School administrators are mainly responsible for ordering places and managing groups, 
students and internship applications. They work as coordinators who coordinate among 
business administrators, Praktikplatsen.se administrators, school teachers and students. 
Therefore, they have limited permissions which are related to these parts. For example, in 
Figure 2.2, in Administration menu, they can only see the information of the users in their 
school and their own school information. 

 
Figure 2.2. Praktikplatsen.se from the perspective of school administrators   

2.3.1.2 Business administrators 
Business administrators play a role in providing internship positions and updating the 
information of the positions. Also, they are responsible for supervising the students when the 
students are doing the internships and evaluating them after they finish. Therefore, these 
administrators have completely different permission than the school administrators. For 
example, in Figure 2.3, they can only see their own business information such as job 
advertisements and user information. 



  6 

 
Figure 2.3. Praktikplatsen.se from the perspective of business administrators   

2.3.1.3 Praktikplatsen.se administrators 
Administrators in Praktikplatsen.se have full permissions of the system, because they are the 
coordinators who work with both business and school aspects. For example, in Figure 2.4, in 
the Administration menu, they can view more information than the school and business 
administrators and they are allowed to view as a specific user in the system. 

 
Figure 2.4. Praktikplatsen.se from the perspective of Praktikplatsen.se administrators   

2.3.1.4 Students 
The interface for students is completely different from the administrators. Since they only 
need to apply for the internship positions in the system, they interact with an easier interface 
as shown in Figure 2.5. They select five positions according to their preferences to the wish 
list, and the school administrators will assign and book a position for them. 



  7 

 

Figure 2.5. Praktikplatsen.se from the perspective of students 

  



  8 

3 
Theory 

Some relevant theories will be explained in this chapter. Since Praktikplatsen.se is similar to 
a complicated system, the theories regarding complicated system will be introduced. Further, 
since this project is in the area of interaction design and will improve the user experience by 
solving usability problems, some theories regarding human-centred design, usability, web 
design and user experience will be presented. Within the section of usability, what need to be 
considered when doing usability studies on complicated systems will also be described. 

3.1 Human-centred design 
According to ISO 9241-210 (2010), human-centred design (HCD) is an “approach to systems 
design and development that aims to make interactive systems more usable by focusing on the 
use of the system and applying human factors/ergonomics and usability knowledge and 
techniques”. During the design process, there will not only be designers who get involved, but 
also users, customers and developers, etc.. HCD is also called as user-centred design in some 
occasions. As users will be involved throughout the design process, HCD can be regarded as a 
way to put user’s perspective into software development process. In this way, as Maguire 
(2002) suggests, HCD is a complement rather than a replacement to software development 
process.  

HCD pyramid (See Figure 3.1) raised by J. Giacomin (2014), which consists of a set of 
questions and answers which span from human factors to metaphysical meaning. These 
answers to the questions are supposed to build up a bridge that connects human with the 
product, system or service. According to this pyramid, the following questions could be 
asked: Who are the stakeholders; What are the goals of using the product; When do the users 
use the product; How do the users learn the product; Why do the users use the product. These 
five questions can be asked and answered by the designers themselves during the whole 
design process, which will be helpful to understand the users and stakeholders. 



  9 

 

Figure 3.1. HCD pyramid (Giacomin, J, 2014)  

 

Donald Norman (2005) thinks that considering users too much can lead to the lack of 
cohesion and add the complexity to the design. This is to some extent true because if a 
designer excessively consider users needs, it might cause some problems. Technologies 
improved rapidly these days, human have to change their behaviours to adapt themselves to 
the improvement of technologies. For example, people did not think of applying touchscreen 
to smartphone ten years ago, after which developers had to develop application that could be 
used on a touchscreen phone and users had to learn how to interact with touchscreens using 
different gestures. If designers did not think of ways to adapt new technologies but to stick to 
old styles, the design would have been obsolete. This is to require designers to keep the 
balance between technologies and human needs and let them adapt to each other when 
applying human-centred design approaches. 

HCD is a multi-disciplinary field (Maguire, 2002). This means not only the designers need to 
know knowledges from different fields, but also have to involve experts from varied areas at 
different stages during HCD process. Designers should communicate with other stakeholders 
who will influence or be affected by the design (Maguire, 2002) in addition to users and 
developers.  

3.2 User experience 
User experience has a very broad definition and covers the user’s experience in all steps of a 
product’s life cycle, from when they see the commercial on the television to buying the 
product, online tracking of the shipping and even the return of the product to the store (Krug, 
2014). Whilst usability focus a lot on objective user performance measures, user experience 
design adds something called emotional impact to adapt to products becoming more personal, 
social and intimate parts of our lives (Hartson & Pyla, 2012). When talking about emotional 
impact, Hartson and Pyla (2012, p. 24) connects it to “pleasure, fun, aesthetic, novelty, 
originality, sensation and experiential features”, in other words, “the emotional impact of 
interaction on the user”.  



  10 

Emotions are an important factor of user experience, but user experience is much more than 
that. Garrett (2011, p. 6) describes the user experience to be “how it works”, in contrast to 
“what it does”. He states that the user experience is about how it works on the outside when a 
person comes into contact with a product or service. An example of how good user 
experience can outclass functionality is the iPhone contra the Blackberry. According to 
Hartson and Pyla (2012) the blackberry was once a market leader full packed with 
functionality, but then came the iPhone, a phone with less functional capabilities but with 
careful design with quality user experience and easy access to the little functionality it had. 
Hartson and Pyla states that if the user could not access functionality, then they simply did not 
have it. Which is why the iPhone became so successful; all of the functionality was easily 
accessible which also enhanced the user experience. 

Preece, Rogers and Sharp (2015) points out that a user experience cannot be designed, you 
can only design for user experience. For example a sensual experience can not be designed, 
but features can be created to evoke it. Which is why many disciplines must be taken into 
when designing for user experience. Under the “UX umbrella”  are quite a few disciplines 
involved, including Usability, Information Architecture, Interaction Design, Interface Design, 
Visual Design, and Content Management. All of these disciplines overlaps and contributes to 
designing for a good user experience (Krug, 2014).  

3.3 Complicated systems 
Complicated systems differ from those we typically encounter in a few ways. Redish (2007) 
mentions some major differences in her article. Firstly, there is an overload of information 
and users need to go through more information than they can deal with, and secondly, that 
information is often incomplete and it may be hard to find the meaningful information one is 
looking for. Two other authors, Norros and Savioja (2004) also mention that the number of 
relevant factors that designers must consider in complex systems are enormous and that those 
systems are dynamic in nature, which makes a high degree of potential hazard when operating 
them.  

As complex systems usually involve many people over a long time period (Shneiderman, B. 
et al., 2004), the system provider often has to deal with issues such as privacy, trust and 
limiting the harmful effects. This will always adds complexity to the system. Therefore, the 
designers should consider designs both for first-time users that emphasize ease of use and 
timely feedback to build trust with them, and for professional users that will enable rapid 
performance of complex procedures (ibid.). 

Increasing the user experience and usability of a complicated system requires the designers to 
reduce the complexity of the system. Noman (2010) suggests that to treat a complicated 
system as whole, because if a system is separated into pieces, it will lead to an end result with 
separated pieces. Garrett (2011) mentions that one design challenge of designing for complex 
system is finding out which parts of the system are redundant and then reducing the user’s 
visibility.  

3.4 Usability 
Usability refers to ensuring that systems and products are easy to learn, effective to use and 
enjoyable from the user’s perspective (Preece, Rogers & Sharp, 2015). There are quite a few 
definitions of usability, but the one that this thesis relies on is defined by Rubin and Chisnell 



  11 

(2008) which states: A product or service is truly usable when “the user can do what he or she 
wants to do the way he or she expects to be able to do it, without hindrance, hesitation, or 
question” (p.4).  

Krug (2014) suggests that much of usability is just common sense, although it might not be 
obvious until after it is pointed out. Some may use the term “user friendliness” for usability, 
but according to Nielsen (1993), that is an unfitting term. He states that a system does not 
need to be friendly when used, it just need to stay out of the way when the user is trying to get 
work done. The term usability is therefore preferred. 

According to Nielsen (1993); if you know enough to be able to talk about a product, then you 
know too much to be able to tell if it’s usable or not for novice users who don’t know what 
you know. This is why products and services needs to undergo usability testing. Testing 
“reminds you that not everyone thinks the way you do” and “knows what you know” (Krug, 
2104, p. 114). Krug states that the basic idea of usability testing is simply watching people 
use your product, while you note where they run into problems. More on usability testing can 
be read in the method section (See Chapter 4.3.4).  

Usability is often broken down into goals or attributes (Preece, Rogers & Sharp, 2015; Krug, 
2014). Mentioned in different sources, some common ones are: 

1. Effectiveness 
This is a general goal which refers to if the job gets done or not? It measures how 
good the product does what it is supposed to do (Preece, Rogers & Sharp, 2015; Krug, 
2014). Measurements are usually done quantitatively with error rates (Rubin & 
Chisnell, 2008), an example of an expression is “95% percent of all users will be able 
to load the software correctly on the first attempt” (p. 4). 
 

2. Efficiency 
Efficiency has to do with time and effort (Krug, 2014). To measure efficiency, Rubin 
and Chisnell (2008) suggests that one should look at how quickly the user's goal can 
be accomplished accurately and completely. An example of an efficient design is 
Amazon’s one-click option which lets users make a purchase with only the click of 
one button (Preece, Rogers and Sharp, 2015). The user then has 30 minutes before the 
order is processed, and during that time the user can make any changes if needed 
(Amazon.com, Inc., 2017). 

 
3. Safety 

Safety refers to protecting the user from unwanted situations and dangerous conditions 
(Preece, Rogers & Sharp, 2015). There are two ways to make products safer; First, 
reduce the risk of pressing the wrong buttons and mistakenly activate unwanted 
functions and secondly, provide users with reverse/undo options should they make any 
errors (ibid.). 

 
4. Utility 

Utility refers to the functionality of a system and to which extent it is provided. 
Preece, Rogers and Sharp (2015) states that good utility is when the system provides 
enough functionality so that users can do what they want or need to do.  

 
5. Learnability 

People tend to dislike spending a lot of time on learning how to use a system, which is 



  12 

why learnability is an important goal. It refers to how easy a user can learn how to use 
a system (Preece, Rogers & Sharp, 2015). Rubin and Chisnell (2008) adds that it can 
also include the ability to re-learn a system after periods of inactivity. They also 
mention that it includes both system which requires training and those without. 
 

6. Accessibility 
Accessibility refers to making a product useful for people with disabilities. It involves 
those with permanent, situational and temporary disabilities (Rubin & Chisnell, 2008). 
By making products more accessible, Rubin and Chisnell suggests that it almost 
always benefits the people without disabilities, because it clarifies and simplifies a 
design. In fact, “making sites more useful for the rest of us is one of the most effective 
ways to make them more effective for people with disabilities” (Krug, 2014, p. 178). 

3.4.1 Usability of complicated systems 
When doing usability studies for complicated systems Redish (2007) mentions some 
important points which need to be considered to conduct an effective usability study; 

1. Collaborate with domain experts 
Since usability experts are rarely domain experts, it is difficult to use inspection 
methods like cognitive walkthroughs, persona or heuristic-based evaluations to 
evaluate complicated systems. Praktikplatsen.se administrators for example, always 
receives training before they use the system, so without it, it is hard to conduct certain 
types of evaluations. This is why working with the users are critical when working 
with complicated systems. Redish (2007) states that they must be included throughout 
the whole process, from planning, to design and development. 
 

2. Collaborate with other specialists 
In usability there are different kinds of areas or goals that one can be an expert on (See 
Chapter 3.4). There may be some specialists on effectiveness, efficiency and safety, 
who then must work together with specialists in utility, learnability and accessibility to 
ensure a successful system. Collaboration is key when working with complicated 
systems. 
 

3. Get the right users 
It is critical that the participants of usability tests represents the real users, because 
there are a few things that could go wrong. Two major problems is getting a false 
positive or a false negative. The first one, a false positive is when the system does 
good in the usability test but when users use it, they have a lot of problems. The 
second one, and also the more likely scenario is to get false negatives. When getting 
false negatives, a lot of problems appears during the usability tests but real users won’t 
have the same problems. To avoid these problems it’s important to use domain experts 
as participants when doing tests and evaluation on complicated systems. 
 

4. Getting the right scenarios 
Realistic and complex enough tasks that represent real use is critical and must be 
thoroughly thought of when preparing Usability tests. Domain experts can help a lot 
with this point.  
 
 
 



  13 

5. Understand the difficulty of setting goals and tasks 
When doing usability on complicated systems, goals and tasks will be at a higher level 
than in typical usability testing and will be much more difficult to specify. These high-
level goals are likely to be vague and are also likely to change as the participants 
moves through the data. Because of this, it might be difficult to define a priori of what 
represents effectiveness or efficiency in a given scenario. 
 

6. Accept domain experts judgment of effectiveness and completion 
Since we are usability experts and not domain experts, we might not know the answer 
to a given task, which is why relying on the participant's judgement that they have 
arrived at a reasonable solution has to be done. 
  

7. Do testing of both the entire system and individual components 
Since complicated systems usually consists of many components and tools, it is 
possible to test them individually with typical usability tests. However it is 
recommended to test the components together because the desired measurements is 
when the users can use the systems to solve high-level problems or goals. The 
scenarios and work situations need to be realistic, so doing tests with both individual 
components and as an entire system is advised. 

3.5 Design of websites 
The process of designing websites contains much more than just its design. Benyon (2010) 
states that website design should follow sound design principles, have a good structure and 
organization of the content, and lastly, include good navigation so that people can move 
around the site. Below we will explain those things with three important pillars of web design 
which are interaction design, information architecture and lastly, navigation design. 

3.5.1 Interaction design 
According to Garrett (2011), interaction design concerns user behaviour and how a system 
respond and accommodates to that behaviour. He mentions that interaction design is to design 
software that works best for the people who use it instead of designing software that works 
best for the machine. 

Designing interfaces is a big part of interaction design, and actually until the mid-1990’s 
designers focused largely on making effective and efficient user interfaces for desktop pc’s 
aimed at single users (Preece, Rogers & Sharp, 2015). When designing interfaces, it is 
thoroughly relevant to understand the users, their behaviour and needs. A human-centred 
approach where the user is in focus is emphasized as needed by Preece, Rogers and Sharp 
(2015). More about HCD can be read about in Chapter 3.1.   

Tidwell (2011) has developed a set of patterns which describe human behaviour which are 
good to think about when designing interfaces. According to her, interfaces that support these 
patterns well helps users more effectively achieve their goal than interfaces that don’t support 
them. There are 14 patterns and they are: 

1. Safe exploration 
A user should be able to try something unfamiliar, go back, and try something else, all 
without stress. Exploring an interface should result in any dire consequences.  



  14 

2. Instant gratification 
The user should easily be able to find introductory functionality and finish the first 
tasks quickly and successfully. It’s gratifying to get a successful experience and 
immediate results in the first few seconds of using an application. 

3. Satisficing 
A user will scan the interface rapidly and pick whatever he sees first that might get 
him what he wants, even if it’s wrong, rather than reading everything on the page 
methodically and decide. 

4. Changes in midstream 
The users goal may change while in the middle of using the interface. So designers 
should provide the opportunity for users to do that. Either in the form of connections 
to other pages and functionality or make it possible with re-entrance, in other words, 
save information and make it possible to start where the user left off. 

5. Deferred choices 
Give the user the choice to skip questions and just answer the minimum for instant 
gratification. An example is a registration form, where the user can fill in some 
information and then fill in the rest later if needed. 
 

6. Incremental construction 
In builder-style and creative interfaces. When building something, one doesn't usually 
do everything in order. It should be possible to build small pieces and the interface 
should be kept responsive to quick changes and saves.  

7. Habituation 
The user can develop habits after repeated use of interfaces. Be consistent across 
applications and think about standards. 

8. Microbreaks 
Users often have microbreaks where they have a few minutes of time between other 
things. During these microbreaks the user can do some activity on an interface if it is 
easy and fast to reach. An example is checking email during a traffic jam or in the line 
at the store. 

9. Spatial memory 
People often find objects and documents by remembering where they were before 
rather than by their names. 

10. Prospective memory 
Prospective memory is used when planning to do something in the future. For 
example with calendar, virtual “sticky notes” and alarms. These functions can help the 
user remember to finish or do something at a later time. Other simple examples are 
leaving windows open on the screen, bookmarking webpages and so on. 

11. Streamlined repetition 
In many interfaces, there is a need to repeat operations over and over. Help the user 
reduce those operations down to as simple actions as possible for a better experience. 
For example one keystroke or one click to do something. 
 
 



  15 

12. Keyboard only 
Some people cannot use a mouse because of physical constraints or assistive 
technology only interacting with the keyboard API. Take this into consideration when 
designing. 

13. Other people’s advice 
Users tend to be influenced by their peers and what they think. Not all interfaces and 
systems accommodates social components, some are not fit for social components and 
should not try, but it might enhance the user experience if applied. 

14. Personal recommendations 
This pattern is similar to the previous on. Users are much more likely to view and try 
things that are recommended to them. For example it is more likely that you will 
watch a video that someone recommended to you than if you found it in some other 
way. 
 

An interaction design process is not only about interface design. Below a simple lifecycle 
model by Preece, Rogers and Sharp (2015) is presented in a simplified version to give an 
example of how a project could look like (see Figure 3.2). 

 
Figure 3.2. An interaction design process, simplified (Preece, Rogers & Sharp, 2015). 

 
This is a basic process that is usually changed and detail is added depending on the project. It 
contains four basic activities which can be found in many other design principles too, like 
product design, graphic design or architectural design (Preece, Rogers & Sharp, 2015). The 
four activities described by the same authors are: 

1. Establishing requirements 
To start off, we must learn who our target users are and what kind of support the 
system can usefully provide. These are needs that forms the products requirements. To 
understand the needs is done through data gathering and analysis. 

2. Designing alternatives 
In this step, the ideas for meeting the requirements are brought forth. This activity can 
be divided into two sub-activities: conceptual design and concrete design. Conceptual 
design includes production of conceptual models for the product. It includes what the 
users can do with the product and what concepts are needed to understand the 



  16 

interaction with it. Concrete design includes things like sounds, icons, colours and 
other details of the product. Alternatives are designed in both sub-activities. 

3. Prototyping 
After bringing out different design alternatives, trying them out by building prototypes 
and iterating throughout the process will become the next stage. Prototyping is a 
useful way when communicating with stakeholders, answering questions and 
supporting designer to choose between alternatives. 

4. Evaluating 
Evaluation is done to help designers to improve the product further. Feedback from 
users or experts will indicate if the prototype or the product is efficient, effective and 
safe, and also if it can satisfy the users. Many techniques are available for supporting 
evaluation. In this step, in order to get feedback of the prototype or product, designers 
need to know what to evaluate, why it is important and when to evaluate. 

3.5.2 Information architecture 
Information architecture concerns the classification of website content and how it is 
organized. It includes how to label the categories and items, how to present the architecture to 
designers and users and how to describe the website's content (Benyon, 2010). Morville and 
Rosenfeld (2006, p.4) defines information architecture as four things: “The structural design 
of shared information environments”, “The combination of organization, labelling, search, 
and navigation systems within web sites and intranets”, “The art and science of shaping 
information products and experiences to support usability and findability”, and “An emerging 
discipline and community of practice focused on bringing principles of design and 
architecture on the digital landscape”.    

Information architecture provides the context for the content and can tell people what they 
can do at the current position (Morville & Rosenfeld, 2006). Morville and Rosenfeld (2006) 
also mention top-down and bottom-up information architectures which help users understand 
the context. They also structure information architecture components into four basic 
categories: Organization Systems, Labelling systems, Navigation systems and Searching 
systems. Good information architecture can reduce the cost of finding information, 
maintenance, construction and training, and also increase the value education and brand.  

3.5.3 Navigation design 
There are four ways of people seeking information (Wodtke and Govella, 2011). First, they 
know exactly what they are going to search and they know what to search, and this is called 
Know-item search. The second way is Exploratory seeking. People know what they need but 
they do not know what to search and they will recognize the answer to the question but they 
do not know if it is the correct answer, so that they have to explore more until they are 
satisfied. The third way is “Don’t know what I need to know”. It means that people do not 
really know what they need to know so that when they are looking for one thing, they figure 
out that they need to know something else. The last way is called Re-finding, because people 
usually need to go back to find what they have found in the past.   

Garrett (2011) mentions three goals that navigation design should accomplish. First of all, it 
has to provide users a means to go from one point to another on the website in a practical way 
to facilitate user behaviour. Second, the relationships between elements of the navigation 
have to be clear. User should not get confused about which choice they should make when 



  17 

they have to choose the available links. Third, the relationship between navigation and the 
page the user is currently viewing also has to be indicated. Understanding this relationship 
can help the users make the best choice regarding the task or goal they are pursuing. 

Also, five navigation systems are presented by Morville and Rosenfeld (2006) and Garrett 
(2011). Global, local and contextual navigation systems that are embedded within the website, 
and are wrapped and infused within the content of the system. They help the users understand 
where they are and where they can go. Supplementary and courtesy navigation systems are 
not embedded within the structure of the website. They provide information which the users 
will turn to when they feel frustrated with the other navigation tools or they can come to a 
conclusion after a quick glance.  

These five navigation systems will be introduced as following: 
1. Global navigation  

It provides access to the entire system. Global navigation does not need to appear on 
every page of the system but users can get to anywhere in the system with global 
navigation.  

2. Local navigation  
It provides access to the pages that are most related to the current page. For example, 
if it is a strictly hierarchy architecture, local navigation will lead the user to the parent, 
siblings and children pages of the current page. 

3. Contextual navigation  
It is embedded within the content of the page itself. It will be necessary if the users 
need additional information when they are reading the text, and this can help increase 
the efficiency by putting the link right there and not letting them scan the whole 
system again. 

4. Supplementary navigation  
It provides shortcuts to the most related content which the users might not be able to 
access through global and local navigation. 

5. Courtesy navigation 
It provides access to the information that the users do not usually need but it is 
provided for the user’s convenience.    



  18 

4 
Methodology 

Throughout the project, many research and design methods have been executed in order to get 
a methodical process. In this chapter, we will introduce a number of methods which are 
relevant to the project.   

4.1 Ethnography 
Ethnographic research methods can be used to gather rich data from the users. Methods 
included in ethnographic studies are for example observations, interviews and questionnaires 
(Preece, Rogers & Sharp, 2015).  

4.1.1 Interviews 
When looking for facts, interviews are common to use. Interviews often go together with 
observation as a combination in field studies and is good for finding out behaviour, beliefs 
and attitudes on a subject (Preece, Rogers & Sharp, 2015). There are several interview types, 
but the ones which will be used in this project are unstructured and semi-structured 
interviews. 
In ethnographic studies, unstructured interviews is a great way to get new insights about the 
interaction of users with technology. It is also a great way to explore and find out major issues 
in a new domain (Wilson 2014b). This type of interview is open-ended and more like a 
conversation which go into considerable depth rather than a question by question interview, it 
covers topics, rather than specific questions (Preece, Rogers & Sharp, 2015). Unstructured 
interview does however not mean that one should conduct it without a written plan. Wilson 
(2014b) suggests that one should beforehand develop an interview guide with listings of the 
general topics or questions and a script for the interview guide. 
Interview methods are also commonly used when moderating usability studies or when 
briefing and debriefing during usability evaluations (Wilson 2014b; Preece, Rogers & Sharp, 
2015). The type of interview that will be used for usability tests and evaluations in this project 
will be semi-structured interviews which is a combination of structured interviews with 
predefined questions and unstructured interviews with open-ended exploration (Wilson 
2014b). In a semi-structured interview, Preece, Rogers and Sharp (2015) suggest that the 
interviewer uses a basic script with preplanned questions and then leads the interviewee to 
keep talking until no new relevant information is being said. The interviewer should lead the 
conversation but it is important to avoid phrasing question in a way that would suggest that a 
specific answer is expected. An example of such a question is “You seemed to like this use of 
colour...” (Preece, Rogers & Sharp, 2015, p. 394) which would encourage the interviewee to 
agree. 



  19 

4.1.2 Observation 
According to Patel and Davidson (2014), observation is a helpful way to collect information 
on behaviour and events in natural situations. Together with other methods like for example 
interviews, it produces rich and in-depth data which can be used for further studies. 
Observations, produce a lot of data which can be tedious to analyse and irrelevant if the 
observation is not planned and carried out well (Preece, Rogers & Sharp, 2015). Preece, 
Rogers and Sharp recommend that data gathering has a clearly stated goal and that the focus 
is on that goal during sessions, because so much is going on and often a lot of changing 
circumstances happen during observations which can make one lose focus. 
There are several types of observations, such as unobtrusive and obtrusive observation and 
direct and indirect observation. The one that will be used in this ethnographic study is called 
Direct Observation in the field. It is a method where observations happen in a normal setting, 
where the designer can get the full context of why activities happen the way they do because 
some things are difficult to explain as a user (Preece, Rogers & Sharp, 2015).  

4.2 Data analysis 
Two sources of the data are involved in this process which include quantitative data collected 
by praktikplatsen.se on Google Analytics as well as qualitative data from the support portal 
where inquiry emails are sent when users meet problems while using the website. From 
Google Analytics, we will find out information such as which platform users tend to use when 
logging in to the website and how long they will stay on different pages. Also, from the 
support portal, we can read what problems users usually meet when they are using the system 
and what the solution is.  
The data will not be used as a main source of user research but they can be supplementary 
information to support the ethnographic studies. For example, we take note of questions that 
users frequently ask when using the system. This can deepen the understanding of the system 
and can also be helpful when deciding the interview questions and suggesting the guidelines. 

4.3 Brainstorming 
Brainstorming can be done by an individual or a group of people (Wilson, 2013b) in order to 
generate ideas. The procedure of brainstorming includes: Select a group of people with 
different backgrounds; pose the problem and present the brainstorming technique to the 
group; generate ideas according to the problem without criticism and judgement; discuss and 
analyse the ideas. The procedure of brainstorming seems to be simple, but it is not as easy as 
it sounds like. Good brainstorming sessions are rare (Wilson, 2013b). There are reasons why 
people cannot speak their minds freely, such as shyness, cultural differences and informal 
relationships with the other members. 

Brainstorming is usually used in the early stage of design process. When new requirements 
are explored and new ideas are needed, brainstorming can be done by a group of people who 
come from the same or different areas. Brainstorming can help to generate wild and unusual 
ideas; however, it can also be chaotic and mute shy people.  



  20 

4.4 Affinity diagram 
Affinity diagram is also known as KJ method, which is named after a Japanese ethnologist, 
Kawakita Jiro, who originated this method. There are four steps in affinity diagram, which 
include label making, label grouping, chart making and written/verbal explanation (Scupin, 
1997). In the first step, the design group is supposed to write each idea on one note card. In 
the following steps, the group has to group the idea according to their intuition and assign title 
to each group, make a chart to reflect a certain pattern that can be found within the original 
note cares, and in the last step, a verbal or written explanation should be made by the whole 
group. (Scupin, 1997). 
KJ method can achieve group consensus because it can let the group focus on one question 
(Martin & Hanington, 2012). During the process of KJ method, the group members are silent 
and everyone is given equal opportunity to express thoughts by grouping the note cards on a 
white board no matter whether the group member is shy or not. This ensures that everyone 
can “speak” at the same time which makes effective use of time (Martin & Hanington, 2012). 

4.5 Personas 
User personas are fictional characters created by the designers to represent the archetypes, 
which means personas should be specific description of a group of users (Reiss, 2012). It can 
be considered as user models which present a group of users’ behaviours, goals and also their 
communication (Cooper et al, 2014). As a designer, designing a product to give users big 
satisfaction is the goal. As users, different users have different goals when using a tool, a 
service or a system. How to satisfy these users is the major issue, and creating user personas 
is a way to solve the problem. Designers need to choose a group of users whose needs can 
represent a larger set of requirements to become the primary users, and then prioritize these 
users so the designers do not need to compromise to meet the secondary user’s needs (Cooper 
et al, 2014). Personas can help to set the goal of a product, and communicate the design 
concept with stakeholders.  
Personas is a strong design tool which is a simple concept but designers have to apply this 
method with sophistication. It is not the same as user profiles which simply put a photograph 
and a list of the user’s basic information which is unrelated to the task. Instead, personas are 
synthesized according to a great deal of user research results. 

4.6 Experience mapping 
Different people have different life experience, however, they have one thing in common that 
they have critical interactions and emotions and they have to make decisions everyday 
(LUMA Institute, 2012). Experience map is a way to visualize what a user have been 
experiencing during the time when they are using a service or a product by analysing the 
notes transcribed from user research results. For example, from in-depth interview and 
ethnographic research. Designers have to extract what people are doing feeling and thinking 
from a user’s point of view (O’Connor, 2016).  
Experience map can help to deepen the empath for users and discover the user’s pain point. It 
is a way to analyse the data from previous user research in the process of divergence, and it 
can inform subsequent design process in convergence, because it can clearly show the 
complexity and difficulty people have faced and struggled (LUMA Institute, 2012). 



  21 

4.7 Sketching 
According to Wilson (2010), not all people who are involved in a design process are 
designers, especially during the participatory design process. A sketch might be nice to have 
during the process, because it is quick to create and inexpensive. Wilson (ibid.) also discussed 
some attributes of sketching, such as timely and minimal detail. Sketches are provided when 
needed, and include only key features.  

4.8 Prototyping 
Prototyping is a way to visualize the design concept. A prototype can be any form of 
expression from a paper-based storyboard to executable digital mock-ups (Preece, Rogers and 
Sharp, 2015). In this section, we will introduce two prototypes that are going to be used in the 
thesis which include a low-fidelity prototype that is going to be created with Balsamiq and a 
high-fidelity prototype that is going to be built with Sketch. 

4.8.1 Low-fidelity prototype 
Creating low-fidelity prototypes is very useful in the early stages of the design process. Low-
fidelity prototypes are easy, quick and cheap to build and will not cost more than enough to 
modify the prototypes. Low-fidelity prototypes are able to visualise the preliminary design 
concept and design alternatives. According to Preece, Rogers and Sharp (2015), low-fidelity 
prototypes are useful to evaluate multiple design concepts with a lower development cost, 
however in the meanwhile, design details are limited. 
There are many ways for low-fidelity prototyping which include sketching, paper 
wireframing, storyboard, wizard of OZ and similar. Low-fidelity prototyping can be regarded 
as a way of concept prototyping and throwaway prototyping since the purpose of which is to 
explore more design alternatives instead of to be integrated to the final product (Lidwell et al, 
2010 & Preece, Rogers & Sharp, 2015). 

4.8.2 High-fidelity prototype 
High-fidelity prototyping can also be called as evolutionary prototyping as Lidwell et al 
(2010) suggest. These prototypes are similar in look and feel rather than in functionality to the 
anticipated final product (Benyon & Moody, 2004). During this process, the prototypes are 
developed, evaluated and refined continuously until they evolves into the final product 
(Lidwell et al, 2010). According to Benyon & Moody (2004), there are features in high-
fidelity prototypes, such as useful for detailed evaluation as aforementioned and important 
design document which clients must agree to before final development. 
High-fidelity prototypes are similar to the final product. It means they are more expensive and 
time-consuming to create and it will cost more to make changes (Preece et al, 2015). 
Therefore, in this phase, designers will become reluctant to change things they have crafted 
for hours (ibid.).  

4.9 Usability testing 
“If you want a great site, you’ve got to test.” (Krug, 2014, p.114), which is why it is one of 
the main focus methods in this project. According to Krug, the only way to make sure that a 



  22 

site works is to watch people try to use it. That is what Usability testing is; watching people 
use something to detect and fix things that are confusing and frustrating for them (ibid.). 

Rubin and Chisnell (2008) has developed a handbook for conducting usability testing and it 
consists of 8 parts: 

1. Develop a test plan 
A test plan is good to make when planning for a usability test. It addresses the why, 
what, when, where, who, and how of your test and is the foundation of the whole 
process. Rubin and Chisnell suggests that the test plan should be written as soon as 
you know you are going to test, and then refine it as the project proceeds. 

2. Set up a testing environment 

To conduct a usability test, you need a location and space. Therefore you need to 
decide on if you are going to do the test in a lab or somewhere else. To decide on what 
is suitable for the test, there are some factors which should be considered. The test 
design and measures, logistics, public relations within your company, and lastly, 
availability of participants. These factors will help you to decide on an appropriate 
setting for the usability test. 

3. Find and select participants 
This step is crucial to the success of the test, because testing with people who are not 
close to the typical user of a product will give bad results with limited value. For best 
results, the selected participants should have backgrounds and abilities as close to the 
intended users of your product as possible. To do this a user profile needs to be set up, 
describing the target audience’s knowledge, skills and behaviour. When that is done, 
an effective way to recruit people from the target audience needs to be done within 
your constraints of budget and time. 

4. Prepare the test material 
Materials vary from test to test, but nonetheless they should be prepared well 
beforehand to better structure and organize the tests. The materials will be used to 
collect data, satisfy legal requirements and to communicate with participants. 
Common materials which are usually developed for usability tests are for example, 
orientation scripts, questionnaires, task scenarios, debriefing topics guide amongst 
other things. 

5. Conduct the sessions 

The sessions can vary a lot in amount of time and participants, but the most typical 
one is the “one-on-one” test where the participants are individually observed and 
questioned by a test moderator being in the same room. The moderator will lead the 
session and do everything from for example, training the user or explaining the 
product to distributing or reading the task scenarios and later on also debrief the user.   

6. Debrief the participant and observers 

After the tasks are done, debriefing is done to review and explore a participant’s 
actions. It is here that the problems are discussed to find out why they occurred and 
how to fix them. Rubin and Chisnell mentions that debriefing sessions do not need to 
be formal or extensive for the pieces to come together, a simple debriefing session will 
help you understand “motive, rationale and very subtle points of confusion” (Rubin & 
Chisnell, 2008, p. 229). 



  23 

7. Analyse data and observations 
When all of the tests are done and the data has been collected, it needs to be analysed. 
A preliminary analysis is done first to quickly find the worst problems and discover 
larger trends and patterns. After that, a more comprehensive analysis is done to deliver 
all findings, the previously found and new ones that were not covered in the 
preliminary analysis. 

 
8. Report findings and recommendations 

This is the last step and this is where the findings from the analysis is documented into 
a final report. In this report you will also with the help of fellow designers create 
recommendations on how to fix certain problems. 

4.10 Heuristic evaluation 
Heuristic evaluation is one of the most common inspection methods when trying to find 
usability problems and is often used because it has a very low cost while revealing many 
usability and design problems (Wilson, 2014a). The method is used by evaluating a system or 
interface against a list of guidelines (Wilson, 2014a; Preece, Rogers & Sharp, 2015). A list of 
nine heuristics was developed by Nielsen and Molich (1990) to use for evaluation which was 
later revised and made into ten heuristics by Nielsen (1994). The list is following: 

1. Visibility of system status 
The users should be aware of what is going on and where they are in the system. That 
is, the system should provide enough information about system status to the users. 
This information could be system feedback, which should be clear, accurate and non-
misleading. For example, users should be able to see the login status in the system. 

 
2. Match between system and real world 

This means the system should use a language which the users can understand, because 
the system should be user-centred, and the user-friendliness is to a large extent related 
to how easily the user can understand the system. The reasons why users cannot 
understand the system can be varied. For example, it could be the users are not 
familiar with the terminology in the system or the users misunderstand the metaphors 
used in the system.  

3. User control and freedom 
Users can be mistakenly doing some actions. Before making some irreversible and 
significant decisions, there should be enough warnings shown to the users. Also, the 
system should support undo and redo. They should have the freedom to exit the page 
as their wish. 

4. Consistency and standards 
The system should follow some “general standard”. Within the system, if it means the 
same meaning, different words should not be used in order to keep it consistent. The 
users should not be confused because of the words, sentences or icons which have the 
same meaning.  

5. Error prevention 
The system should have the ability to inform the users how to do actions in a correct 
way so that errors can occur less often during the working process. For example, when 



  24 

setting password, the users should know what is the correct format of setting 
password, and the system should inform the users where is clickable and where they 
are supposed to input information.    

6. Recognition rather than recall 
If a system is too complicated, it usually requires the users’ energy to remember how 
to finish a task, but this problem can to some extent can be solved by the system itself. 
It would be easier for the users the recognize an icon than remember an icon. In this 
way, understandable information on the interface and easy language of the system 
should be considered when designing a system. 

7. Flexibility and efficiency to use 
The system should be able to perform some tasks automatically. This can save some 
time and energy for the users. For example, the users should not select a value which 
is supposed to be default and the users should not adjust the window size when it 
should be automatically adjusted. 

8. Aesthetic and minimalist design 
The visual effects is an important factor that can influence the user experience. For 
example, old people might have some special requirements on the size and style of the 
font. Also, every page or dialogue should not include information that is irrelevant and 
rarely needed. 

9. Help users recognize, diagnose and recover from errors 
When an error occurs, the system should be able to help the users realize there is an 
error, learn the reason why there is an error and give the solution to the error. The 
system should provide accurate error message in a proper way. For example, the 
message should be written in a plain language and should not make the users 
confused. 

10. Help and documentation 
Help and documentation should be provided even though the designers think the 
system is perfect. The information should be easy to search and understand.  

4.11 Perspective-based UI inspection 
Perspective-based UI inspection is used to evaluate a product from different perspectives and 
is a good way to broaden the problem-finding ability (Wilson, 2014a). Different perspectives 
can be for example different types of users, like old, young, color blind and more. If you were 
to look at a product from an elderly’s perspective, the issues being highlighted might be for 
example readability or terminology which is hard to understand by elderly (Wilson, 2014a). A 
list of questions or heuristics are usually developed to have something to evaluate against.  
Wilson (2014a) states that the method is good to use in situations where you have limited 
access to users or you are lacking time to recruit users for a full-scaled study. The method can 
be extremely fast and is therefore optimal when the budget is low and access to users is 
lacking. 
  



  25 

5 
Design Process 

This chapter contains our planning and the different phases of the project (See Figure 5.1). 
Here we describe how the project was divided, what methods we used in the different phases 
and explicitly how everything was executed. The first part shows the general design process 
while the other two parts goes in-depth on the two major phases of the project and the 
methods used.  
 

 

Figure 5.1. Design process 

We had two phases in the design process. In the first phase we focused on research and 
analysis. The purpose of our research and analysis was to find out as many usability problems 
as possible, so we used different user research methods such as ethnographic stud and 
heuristics evaluation. We split the second phase into two iterations where we applied the 
design alternatives by creating a low-fidelity prototype and did usability tests on it in order to 
get feedback and then we made a high fidelity prototype in the second iteration.   

5.1 Phase I - Research and Analysis 
In the first five weeks of the project, the focus laid on finding out usability problems in the 
system and which parts of the system to focus on. We had to find out which perspective we 
wanted to go with, school administrators, Praktikplatsen.se administrators or business 
administrators and to do that we started out with an ethnographic study in the form of a 
combination of observations and interviews. After that we used three methods to find out 
usability problems, the methods were: data analysis, usability testing with school 
administrators and then heuristic evaluation in two iterations. Lastly, when the problems had 
been found, we did a KJ evaluation, also called Affinity diagram to categorize the problems, 
to decide on which parts to prioritize. 



  26 

5.1.1 Ethnography 
To decide which parts to focus on and to learn the workflow of the users, we started out with 
doing an ethnographic study. The study was a combination of observation and interviews and 
included seven users in total, one Praktikplatsen.se administrator, three school administrators 
and three business administrators. After just one interview with an Praktikplatsen.se 
administrator, we could exclude them from the main focus, since we learned that they were all 
experts of the system and also the ones who handled and solved the support errands. They 
were also the ones who conducted training courses, which is why their workflow would not 
be disrupted from usability problems as much as the other users. So, after that, we met with 
the school and business administrators and interviewed them which resulted in a lot of 
qualitative data about what they did and how they experienced the system. The study showed 
that school administrators used the system more frequently, and they used a bigger part of the 
system. Even though the main purpose of the ethnographic study was not to find out usability 
problems, we could already see there that the school administrators experienced more serious 
problems than the others which is why we chose to put focus on them.   
How we conducted the study was to first make up a script template which included the goals 
of the study, wide questions which could produce good qualitative answers and also some 
small guidelines on how to proceed with everything (See Appendix A). The study always 
took place at the user's workplace and we started every session by introducing ourselves, 
getting agreement for audio recordings which would be done with our phones and then asking 
the user to show us how they perform their daily work, thus starting the observation. 
The observation session did not have clearly stated questions to be asked, but instead we 
asked questions depending on what they showed us and we kept them on track by using 
leading questions like for example “what do you do after that?”, “do you do anything else on 
this page?” to stay focused on the goal of the observation which was to find out the workflow 
of the users. Finding out the experience of the users among other stuff came afterwards in the 
unstructured interview. 
Unstructured interviews were executed directly after an observation was done to further learn 
about the workflow and the other goals we had set for the sessions, which were, usability 
problems, pros and cons with the system, the user experience, and lastly the usage of the 
Praktikplatsen.se support. These goals were covered with open-ended questions which means 
that instead of many smaller questions we had few wide questions which would make the user 
go more in-depth on the topic at hand.  
After ending a session we would partly machine transcribe the whole recording with the 
software Pop Up Archive and then correct and add the remaining information manually. Some 
parts were done manually because the software could usually not transcribe everything, 
because of accents, Swedish words and so on. The software helped shortening the 
transcription time a lot and was used for every recording in this and other methods used. The 
transcription, when done, was then combined with notes taken and resulted in a list of quotes 
which were related to usability problems (See Appendix B), and would act as a base for the 
Affinity diagram (See Chapter 5.1.5). The transcription also helped to make clear the 
workflow which would be used as a base for making scenarios for the usability tests (See 
Chapter 5.1.3). 

5.1.2 Data analysis 
The data analysis was done on two kinds of data, they were both quantitative, and both 
supplementary to support the findings in the ethnographic studies. The first kind of data was 



  27 

found after doing an analysis and summary of the Google Analytics statistics (See Appendix 
C). The data showed how many sessions certain pages in the system had and with that we 
could determine which pages were most frequently visited and which ones were more 
infrequently visited. Thereafter, together with the results from the ethnographic study, we 
could decide on which pages to focus on and which pages to put on the low priority list. The 
second kind of data came from analysing 200 support errands from Prraktikplatsen.se’s 
support portal. The support errands were categorised based on problem type and area in a 
table (See Table 1 in Chapter 6.2) and could later be used as a supplement in other methods, 
for example in Chapter 5.1.3 where the data together with the ethnographic study results 
would support the scenario making process and decision making of which areas and which 
tasks to test in the usability tests.  

5.1.3 Usability test 
Usability testing was done in two periods and with two different contexts. The first one was 
done right after the ethnographic study and data analysis, and the goal was to find out 
usability problems in the unchanged system with the school administrators, while the second 
test was done to test the lo-fi prototype together with domain experts who are the 
Praktikplatsen.se administrators. The second test can be read about in Chapter 5.2.1.6. This 
chapter will be about the first test.  
Both quantitative data and qualitative data was collected during this usability test. The goals 
of the test was to assess the effectiveness of the system for the users with different levels of 
experience, to identify obstacles when completing common task, to evaluate the common 
problems that appear in support errands. Therefore, different categories of daily tasks were 
identified through support errands, and according to these categories, the common tasks were 
decided. We integrated these tasks into different scenarios to provide the test users a smoother 
process to do the test. We were supposed to assess how easily and successfully the users can 
finish each task, and also we collected qualitative data which came from the verbal protocol 
and debriefing interviews after the test session so that we can know why they were confused 
and help us set priorities on potential changes to the system. 
The process we followed was the one described by Rubin and Chisnell (2008) which was also 
mentioned in Chapter 4.9. The steps were: 

1. Develop a test plan 
The first thing we did was to make a test plan to know exactly how everything was 
going to proceed and what we needed to prepare and do (See Appendix E). The test 
plan was created in the beginning of the preparation process but was revisioned and 
filled in as we proceeded, since some of the information in the plan was decided in 
later steps. 
  

2. Set up a testing environment 
We had more freedom and time to move around than the users, so we decided to do 
the tests at the user's’ workplaces for their comfortability and also to have a normal 
context of usage. 
  

3. Find and select participants 
Since we already knew what kind of users we were focusing on, it was easy to get a 
hold of the correct type. The users’ contact information was provided to us by GR so 
we did not have to recruit them, because it was done for us. All we had to do was to 
book the time for testing. The testing was done with three different users at different 



  28 

times. We originally planned to test with five school administrators but the availability 
of the users was not very good which made it hard for us to stick to the planning if we 
were to proceed in the pace we wanted, so we stopped at three. Nielsen (2017) 
suggests that with three users, you can find about 65% of the usability problems in a 
system (See Figure 5.4), so combining those 65% with the problems we found from 
our ethnographic study, heuristic evaluation and data analysis, we deemed it was 
enough. 
 

 
Figure 5.4. Number of users needed to find Usability problems (Nielsen, 2017). 
 

4. Prepare the test material 
The first material we had to prepare was scenarios that we could use to guide the users 
through the system (See Figure 5.5). The scenarios were based on the information 
gathered from the ethnographic study and data analysis about the workflow and 
commonly used pages. We also considered the pages with a lot of already found 
problems seen in Table 1 in Chapter 6.2. This resulted in four different scenarios 
which covered almost everything a school administrator would do in the system and 
most of the problem areas found. 

 
 



  29 

 
 
  Figure 5.5. Scenario chart for Usability testing.  
 
Another thing that had to be prepared was a way to record the sessions for further 
analysis. We considered several options with video cameras and microphones or USB 
programs since we initially wanted to use the users own computers, but in the end we 
decided on using our own MacBook laptops which had QuickTime with built-in 
screen recording installed. With QuickTime we could set it to record the screen and 
take in audio from the computer's microphone. It could also indicate where the users 
were clicking which was really helpful for analysis.  

The last thing to prepare was the data in the systems. We were working in a test 
environment, so our changes and tests did not affect the real system, which is why we 
could create and manipulate everything in the system freely. We created fake schools 
with fake user accounts which had administrator permissions that the participants 
could work with. We also created fake students and changed some information on 
existing internship places so that our students could apply for them. All of the data was 
created or changed directly in the system except for the students which we added to an 
Excel file and was to be uploaded to the system by the participants as a part of the 
scenarios we created.  

5. Conduct the sessions 
When conducting the sessions, we split the responsibilities into two tasks. One would 
be the moderator and lead the participant through the scenarios while asking and 
answering questions, trying to keep the participant focused on the tasks. The other 
person was the note taker and would take notes of interesting situations, reactions, 
answers and actions of the participant which would could later be used in the 
debriefing part for reviewing the session. 

6. Debrief the participant and observers 
After going through all scenarios with a participant, we had a short debriefing session. 
In this session where we looked at all the scenarios and repeated orally what they did 



  30 

and what we saw. We then asked questions based on the notes taken and let the 
participant answer and ask their own questions. 

7. Analyse data and observations 
When the sessions were done and all the data had been collected, we had to analyse 
the data and turn it into useful information. This was done in two steps: compiling 
then summarising (See Appendix F). In the compiling part we looked through videos 
and noted what kind of mistakes they did and how often they did it, and in the 
summarising part, we made a table counting and combining all of the problems for all 
users so that we could get a good overview of the usability problems found. 

8. Report findings and recommendations 
The findings are a part of the usability problems and guidelines in the result section 
(See Chapter 7.1 & 7.2). 

5.1.4 Heuristic evaluation 
The heuristic evaluations were done with two studies, the first one at the beginning of the 
project with ourselves and two other interaction designers, and the second one was done by 
ourselves after becoming fairly used to the system. The sessions were divided into two 
phases, first an inspection part and then a discussion part. The discussions resulted in lists of 
problems in both studies (See Appendix G) and we chose some of the problems we thought 
were critical and added it to the list of problems. (See Appendix D). 

5.1.4.1 Study 1 
The first evaluation was done at the very start of the project and was done by four interaction 
designers including us, and it was done randomly in all parts, following no scenarios or tasks. 
We did this inspection to get an initial feeling of the system and to find any obvious usability 
problems that could occur to anyone using Praktikplatsen.se. The inspection was a simple one 
and all we did was to compare the different processes in the system to the heuristic in Chapter 
4.10. 

5.1.4.2 Study 2 
The second evaluation was a lot more in-depth and complicated than the first one. We still 
used the same heuristics, but this time we used the same scenarios as the usability tests (See 
Chapter 5.1.3) which covered most parts of the system that a school administrator would use. 
By going through the system ourselves with the scenarios, we could confirm the found 
problems the users experienced in the usability tests but also find problems which the normal 
user would not think about.  

5.1.5 Affinity diagram 
For the affinity diagram (See Figure 5.6), we used the quotes and problems found in the 
ethnographic study (See Chapter 5.1.1) to find out problem types, to make a priority order of 
the different types and to know what to focus on for Phase II (See Chapter 5.2). The session 
started by individually and quietly categorising all of the quotes. The different categories 
were then named and some of the quotes were relocated to fit into the different categories. 
The categories were then named after different problem types or areas such as “cannot find 
the function” or “system errors”. These categories were then ranked after a few criteria which 
where; “how serious is the problem?”, “will we be able to give a good solution to it?” and 
“how much does it disrupt the workflow?”. The final result of the affinity diagram was a 



  31 

color-coded list of problem types in the order to prioritise them in. Red was for the must-fix 
problems, yellow was for the medium-serious problems and green was for the problems 
which was non-serious or we could not give a solution to. The list was formed like below: 

1. Cannot find functionalities (Red) 

2. Complexity (Red) 
3. Memorability (Red) 

4. Language (Yellow) 
5. User interface (Yellow) 

6. Export/import (Yellow) 
7. Missing functions (Yellow) 

8. Titles (Green) 
9. System errors (Green) 

10. Other problems (Green) 
The red and yellow problem types are used as a base to show our final results in the Usability 
problems and design solution chapter (See Chapter 7). The different areas will be explained in 
detail there, except for the green ones, which were about titles for users, technical errors and 
error messages, and lastly, other problems like out-of-date information. 

 
Figure 5.6. Affinity diagram on a whiteboard. 

5.1.6 Experience mapping 
Experience mapping is a way to visualise what the users do and how they feel when 
interacting with a product. The materials for making an experience map came from the 
ethnographic study and data analysis. 

We first put the transcripts into a table (See Appendix H). The table consisted of four parts, 
which included the transcript and information extraction of what they were doing, feeling and 



  32 

thinking. After that, the workflow become clearer and more detailed information of user 
experience was more clarified by sorting out behaviours and feelings. The behaviours were 
corresponding with some feelings from different people (See Figure 5.7).  
In the figure, the yellow colour means behaviour. The green colour represents the positive 
feeling while doing the behaviour and red colour is about their negative feeling. As shown in 
the map, it was very rare that people show some positive feelings when they were interacting 
with the website and their negative emotions tended to be confusion and frustration. Also, we 
summarised the objectives for a series of behaviours which is represented in purple in the 
figure.  
The blue colour shows each stage that the users will be at during the interaction with the 
system. The stages were categorised as following, according to the scenarios and problem 
areas in the usability test: 

● Managing places: Includes the views where the users handles place orders. 
● Managing groups: Covers the views where the handling of groups are done. 

● Managing applications: Covers the view that where the users handles the internships 
and applications of their students. 

● Managing users: Includes the views of creating a new user and managing the user’s 
personal information and permissions. 

● Viewing: Includes the views of placement list, planned period overview, place 
overview where the users can look through different kinds of data. The users can 
export data from the overviews. 

For example, at the stage of managing application (blue), if the users want to add a group 
(purple), they have put in information first and then upload the student file (yellow). They feel 
frustrated because it is time-consuming to upload multiple groups (red) and there is no 
positive feeling (green). 



  33 

 
Figure 5.7. Experience map with examples 

The results from experience mapping was together with the heuristic evaluation made into a 
list of critical usability problems which was used in the Phase II as a base for design 
(Appendix D). The problems on the list was categorised in the same way as in experience 
diagramming. 

5.2 Phase II - Design and Evaluation 
In the following five weeks after the research and analysis, the focus was on designing the 
prototypes and doing evaluations on them. There were two iterations in this phase. In iteration 
one, we mainly focused on how to converge the problems that we found in the first phase in 
order to extract more concrete visualisations such as personas and the low-fidelity prototype. 
In the second iteration, the focus was on improving and perfecting the visualisations. That is, 
a high-fidelity prototype was made to achieve the goal and a perspective-based UI inspection 
was done regarding the prototype. 

5.2.1 Iteration 1 
The first iteration started with collecting solutions to the list of problems and ended with the 
second usability test. During the process, two personas was made to visualise the user’s 
workflow and user requirements that we collected and summarised in the research and 
analysis phase (See Chapter 5.1). After that, a brainstorming session was conducted by us, 
and the usability problems list helped to generate ideas. Sketches were created with pen and 
paper according to the ideas, and there were discussions on them in order to select better 
solutions. Low-fidelity prototypes were designed in the form of wireframes after that, and the 



  34 

wireframes were created in Balsamiq. Finally, the low-fidelity prototypes were tested with 
domain experts, and feedbacks were gathered to improve them. 

5.2.1.1 Personas 
Personas can be used to describe a group of users and what their needs are (See Chapter 4.5). 
On the basis of the users research results, we found out that the users fall into four groups, 
which include new user, old user, frequent user and infrequent user. However, old users can 
be infrequent users, which make them lack of familiarity to the system. Likewise, if new users 
who receive training courses in the beginning and keep using the system everyday, they can 
get the hang of the system in a short time. Therefore, two personas were created according to 
aforementioned features. One of them is a new and frequent user, the other one is an old but 
infrequent user (See Figure 5.8). The personas not only described a picture of how people 
work in different user groups but was also a visualisation of the user needs that we gathered 
by using the user research methods. 

 
Figure 5.8. Users personas (Freepik, 2017) 

5.2.1.3 Brainstorming 
Brainstorming was done after personas. The purpose of the brainstorming session was to 
come up with ideas which could solve the usability problems and improve the usability of the 
system. Therefore, the list was used as inspirations for brainstorming. The ideas were 
generated according to each category on the list. 



  35 

There were two sessions in this step. First, we wrote down ideas for one category individually 
within a time limit. Second, we discussed the ideas with neither criticism nor praise and put 
them on the whiteboard, and they were sorted according to each category. After that, we 
moved on to the next category until we finished brainstorming for the last category (See 
Figure 5.9).  

 
Figure 5.9. Brainstorming session 

5.2.1.4 Sketching 
Sketches were made in order to visualise the initial ideas that we had come up with in the 
brainstorming session. The same with brainstorming, this session was also done category by 
category. The sketches were made in parallel so that thoughts would not be interfered. Both 
good and bad aspects of each other’s sketches were discussed thoroughly in order to select the 
essential parts from each sketch, or come up with new ideas together.  

Many design choices were made in this step. In the process of managing group, the flow of 
uploading a group was simplified and optimized. In managing places, the flow of ordering 
places was made smoother, such as some redundant steps were reduced or combined with 
other steps. In managing applications, the features of timeline were discussed and we decided 
on using number to show the step-by-step concept of managing applications. In viewing, the 
detail of how to make the timeline clickable was settled and how other functions on the start 
pages should be like was carefully considered. All of these would lead to low-fidelity 
prototypes which was be created in the next stage. 



  36 

5.2.1.5 Low-fidelity prototyping 
The low-fidelity prototype was created in Balsamiq (see Figure 5.10), which is a really 
convenient tool for creating wireframes with a great amount of handy components. In this 
step, what the interface would look like in reality came into consideration, even if it would 
just be black and white wireframes. The real size of the window and the font size were 
considered because they would affect the layout of the interface. Many other factors were 
under consideration as well. For example, consistency, the flow of adding, editing and 
removing. 
Low-fidelity prototyping could be regarded as a summary of what we had done in the 
previous stages. From analysing the website and collecting user feedbacks to coming up with 
ideas, all the results were integrated into the low-fidelity prototype, which lead to the 
agreement between the designers and the stakeholders so that we all were on the same page.    
 

 
Figure 5.10. Low-fidelity prototype made in Balsamiq 

 

5.2.1.6 Usability test 
The second usability test was done with the domain experts who are currently working at 
Praktikplatsen.se as administrators. The reason why we chose to test with domain experts was 
because they have more knowledge of the system than the regular users, since the system is 
complicated. Praktikplatsen.se administrators are the staff who work with support errands and 
provide training courses, so they know what problems the regular users would generally meet. 
In this way, they could be critical towards the new design and provide positive or negative 
feedback that could be considered in the next iteration. 

Different from the first usability test (See Chapter 5.1.3), we did not adopt scenarios to go 
through the whole test. Instead, we designed different tasks for each process (See Appendix I) 



  37 

and a goal for each task. For example, in managing users information we designed tasks as 
below: 

● Go through the process of adding a user and giving permission 
○ Add user 

○ Give permission 
○ Edit permission 

○ Save permission 
○ Remove permission 

The purpose of the task was to test whether the user could find the functions and to find out 
whether the process was logical and smooth. The users were asked to “think aloud”. That is, 
they were required to talk about what they were thinking and feeling at the moment. After 
going through all the tasks, some follow-up questions were asked in order to get some 
additional information. Also, the usability tests were recorded by QuickTime during each 
usability test, we transcribed it to the form of text after that. 

The domain experts gave us more professional suggestions on different process, for example, 
they suggested to use better names for the steps in booking management. They gave valuable 
feedback on the shortcuts, which they thought had too much information in it and looked like 
a big menu. They had insightful ideas on how the system should work according to their years 
experience of working on the system and interacting with the school administrators, but 
overall impression on the low-fidelity prototype was positive.  

5.2.2 Iteration 2 
The second iteration started with making a high-fidelity prototype in Sketch and ended with 
doing a perspective-based UI inspection to evaluate the prototype. The inspection was 
conducted based on the personas we created in the previous step and heuristics suggested by 
Nielsen (1994). After this, more improvements were applied on the high-fidelity prototype. 

5.2.2.1 High-fidelity prototyping 
The high-fidelity prototype was created in Sketch (See Figure 5.11), the whole process took a 
week. In this step, more design details were considered. Not only window size and font size 
were considered, but also the alignment and the balance of the interface. The prototype was 
made according to each process. In each process, it was designed with clickable interactions, 
and the interactions were made in InVision so that it could be shown to the stakeholders. 
High-fidelity prototyping is a method that can visualise more design details, so aesthetic 
comes into consideration. Colour-coded information can be shown. For example, red colour 
shows alarming information and yellow colour represents warning information. The result 
from hi-fi prototyping is as close to the real product as possible, and this can reduce 
misunderstandings when communicating with the stakeholders. 

The result from high-fidelity prototyping will be discussed in detail in Chapter 7.1.  



  38 

Figure 5.11. High-fidelity prototyping 

5.2.2.2 Perspective-based UI inspection 
A perspective-based UI inspection was done after creating the high-fidelity prototype in order 
to improve and perfect the current prototype in a higher degree. We made use of the personas 
we created in the previous step (See Chapter 5.2.1.1) in order to inspect the UI from the 
perspectives of each persona based on the 10 heuristics suggested by Nielsen (1994).  

For each persona, there was different focus on heuristics. For example, from the perspective 
of Karen who is a new user but works with the system every day, her focus would be more on 
the flexibility and efficiency of use, and aesthetic and minimalist design, while for Chris who 
is not a very frequent user, the focus would be more on the match between the system and real 
world and recognition rather than recall. We summarised the problems found from each 
perspective to a list (see Appendix J).  

As aforementioned in Chapter 4.11, this method is good use when the budget is low and there 
is lack of time. Due to the time limit, we could not recruit real users to do another round of 
usability test. Therefore, we used this method from the perspectives of the personas to find 
problems so that we could get results quickly and efficiently.  

  



  39 

6 
Results from user studies 

and data analysis 
In this chapter, we will present the results from the user studies and data analysis in the thesis. 
The first part of this chapter is the results from ethnographic study which will be presented in 
accordance with the structure of affinity diagram. The second part is about the analysis of the 
200 support errands as well as Google Analytics. The last part, we will describe the results 
from usability tests, which include the usability test in the first phase and the usability test on 
the low-fidelity prototype. 

6.1 Ethnographic study 
From the ethnographic study that we did with 7 users, we extracted a certain amount of quotes 
which were connected to workflow and problems. The amount of problems and complexity of 
the workflow made us choose to focus on School administrators. So here we will only present 
some of the data from their studies. The full study for all administrators can be found in 
Appendix B.  
There were in total 3 school administrators. User 1 and 2 are admins for adult educations and 
handles their internships while user 3 is the internship responsible for an elementary school. 
Even though different education levels, the system works mostly the same for all of the 
school administrators. The results will be presented according to the categories of affinity 
diagram we made after the study and one quote and one explanation will be presented in each 
category below. 

1. Cannot find functionalities (Red) 
 “I know that last time two of my students want to switch places and the whole system sort 
of went berserk. And that was very very tricky thing to do.”  

The user did not know how to switch places between students, and he had to get help 
from the administrators at Praktikplatsen.se so that they can help him finish the task.  

This category is about the user complained it is hard to find the functions. Although 
there is a function in the system, but they might not use i