
Chalmers University of Technology

Bachelor Thesis at The Department of Computer
Science and Engineering

DATX02 - Group 56

Positive User Experience - Redesigning
Chalmers’ Studentportal

Authors:
Johan Davidsson,
Oscar Forsberg,
Mohammad Jamal Basal,
Thomas Jinton,
Alice Olsson,
Johanna Wiberg

June 16, 2021


Positive User Experience
A Redesign of Chalmers’ Studentportal

JOHAN DAVIDSSON
OSCAR FORSBERG
MOHAMMAD JAMAL BASAL
THOMAS JINTON
ALICE OLSSON
JOHANNA WIBERG

Supervisor: Olof Torgersson, Associate professor, Interaction Design division,
Department of Computer Science and Engineering.

Examiner: Morten Fjeld, Professor, Interaction Design division, Department of
Computer Science and Engineering.

Bachelor’s Thesis DATX02-21-56
Department of Computer Science and Engineering
Chalmers University of Technology
University of Gothenburg
SE-412 96 Gothenburg
Sweden
Telephone +46 31 772 1000

Typeset in LATEX
Gothenburg, Sweden 2021

1


Abstract

By doing a redesign of Chalmers’ Studentportal the goal was to create a positive user experience
while increasing the prototype’s efficiency compared to the existing website. The new design was
developed in the web-based prototyping tool Figma.

The first prototypes were designed after the collection of a wide range of data gathering meth-
ods; multiple structured interviews, a questionnaire, an expert analysis, multiple literature reviews
and a meeting with employers working for Chalmers’ Studentportal, the project’s stakeholders.

The process evolved by carefully selecting design patterns to reduce navigation issues discovered by
stakeholders and user tests. Rapid prototyping was used to progress the prototype, with user tests
included in each iteration. An important aspect was the inclusion of emotional charts in every user
test, which enabled one to track how users felt about various features and functions in the prototype.

The process resulted in a well established prototype, which was presented for the stakeholders
together with the evoked emotions associated with the product. The results showed an increase of
positive emotions when comparing the first user tests about the current Studentportal to the final
prototype.

Something that had to be considered was whether the users liked the prototype more because
they were dissatisfied with the current Studentportal. If this was the case, a minor improvement in
the prototype could stand out tremendously, even if the improvement is objectively considered as
tolerable. Nonetheless, in the final user test, only one participant experienced a negative emotion,
a slight sense of being overwhelmed, associated with the product. However, it is something that
could be expected. A brand new user interface will undoubtedly take some time to adapt to and
learn, which is why it is not regarded as a problem.

2


Sammandrag

Genom att konstruera en ny design av Chalmers Studentportal, var m̊alet att skapa en positiv
användarupplevelse och samtidigt f̊a en högre effektivitet p̊a den nya prototypen jämfört med den
nuvarande Studentportalen. Prototypen tillverkades i det webbaserade verktyget Figma.

De första prototyperna p̊abörjades efter ett flertal olika metoder av datainsamling hade utförts;
strukturerade intervjuer, ett fr̊ageformulär, en expertanalys, flertalet litteraturstudier och möten
med de som är ansvariga för Chalmers Studentportal, projektets intressenter.

Processen utvecklades genom att noggrant valda designmönster användes för att reducera bland
annat navigationsproblem, upptäckta av b̊ade intressenterna och i användartester. Metoden Rapid
prototyping användes för utvecklandet av prototypen där användartester genomfördes i varje itera-
tion. En viktig aspekt var användandet av känslodiagram i alla användartester för att kunna sp̊ara
och först̊a vad testpersonerna kände rörande bland annat prototypens funktioner och utseende.

Projektet resulterade i en väl etablerad prototyp som presenterades för intressenterna tillsammans
med de känslor som användarna upplevt under testerna. Resultaten visade p̊a en stor ökning av
positiva känslor jämfört med det första användartestet kring den nuvarande Studentportalen med
det sista användartestet p̊a den slutgiltliga prototypen.

Slutligen s̊a uppkom diskussion om användarna föredrog den skapade prototypen mer endast för att
de var missnöjda med den befintliga Studentportalen. Om det är fallet skulle det kunna betyda att
en liten förbättring av prototypen kan ge starka positiva känslor, även fast förbättringen objektivt
kan anses vara av det minsta laget. Dock, i det sista användartestet upplevde endast en deltagare
en negativ känsla, en känsla av överväldigande associerad med produkten. Men detta är n̊agot som
man skulle kunna förväntas sig. Ett helt nytt användargränssnitt kommer utan tvekan att ta tid
att anpassa sig till och lära sig, vilket är varför det inte betraktades som ett problem.

3


Acknowledgments

We would like to begin by thanking our supervisor Olof Torgersson, for his support and advice
throughout the process as well as our examiner, Morten Fjeld, for giving feedback throughout the
project. We would also like to give a big thank you to our Stakeholders at Chalmers’ Studentportal,
Ingrid Claesson, Ulla-Karin Drakeskär, Helén Rosenfeldt, Pär Svensson and Johan Wetterberg, for
cooperating with us and sharing statistics from the website and for reviewing the finished prototype.
Your support has been very motivational for us.

Finally, we would like to thank our test participants for taking part in our user tests, your feedback
was crucial for the prototyping process.

4


Contents

1 Introduction 8
1.1 Purpose and goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Related Work 9
2.1 Re-design of a room-booking system . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Analysis of the implementation of the Studentportal . . . . . . . . . . . . . . . . . . 9

3 Theory 11
3.1 Positive User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Design principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Affordance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Escape hatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Feature, search, and browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Fat menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4 Sitemap footer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.5 Breadcrumbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.6 Visual framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.7 Grid of equals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.8 Right-left alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.9 Input prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.10 Prominent done button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.11 Hover or Pop-Up tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.12 Module Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.13 Accordion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.14 Carousel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.15 Pagination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Web Accessibility Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Method 18
4.1 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 Expert Review of the Studentportal . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Personas and Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Constraints and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5


4.3.1 Paper prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Think-Aloud-Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Emotion Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Data Gathering 22
5.1 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Analysis of the Content of the Studentportal . . . . . . . . . . . . . . . . . . . . . . 24

5.3.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 User Requirements 26
6.1 Constraints and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.1 First Scenario - Robert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.2 Second Scenario - Klara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.4 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Prototyping 30
7.1 Paper Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.1.1 Reviewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2.1 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.2 Reviewing - User test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.3 Refining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.3 Iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.1 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.2 Figma Memory Usage Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3.3 Reviewing - User test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3.4 Refining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.4 Final Touches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.5 Presenting the Prototype for Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Result 38
8.1 Users’ Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.1.1 Final Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1.2 Evoked Emotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.2 Guidelines for Maintenance of the Website . . . . . . . . . . . . . . . . . . . . . . . . 42

9 Discussion 43
9.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2 Users Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.3 Design Decisions to Ensure the Positive User Experience . . . . . . . . . . . . . . . . 44

9.3.1 Aesthetics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6


9.3.3 Ease of Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.4 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.4.1 Iteration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.4.2 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.5 Obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.5.1 Covid-19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.5.2 Figma Memory Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.5.3 Human Factors in Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9.6 Social-Ethical Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.6.1 Web Accessibility Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

10 Conclusion 49

A Questionnaire 53

B Interview 55

C Paper Prototypes Frontpage 56

D Figma Prototypes Frontpage 58

E Emotion Chart 60

F User stories 61

7


1 Introduction

While using a product, one will seek a positive experience. As known, emotions are essential to
humans beings. People seek positive experiences through contact with other humans, events, new
experiences and the choices that one makes. Humans have created many of the things that one sees
and uses everyday, making it impossible to ignore the fact that the product experience consciously
or unconsciously tries to reach a positive experience [1].

The project’s main focus has been to create a positive user experience by following design principles
and to discover what users believe to be positive design choices. For instance, using emotional charts
in every user test will make it possible to keep track of the feelings experienced when interacting
with the prototype.

The project began with discussions regarding which application or website that could be redesigned
for the purpose of achieving a more positive user experience. When Chalmers own Studentportal
came to mind and the group discussed their own experiences with the website the choice was ob-
vious. Redesigning a website that provides students with information regarding their studies was
found to be both relatable and motivational.

1.1 Purpose and goal

The purpose and goal of this project is to redesign the current version of Chalmers’ Studentportal
[2] to raise its efficiency as well as to deliver a positive user experience. The project will result in a
prototype which will work as a proposal for how Chalmers can refactor the current Studentportal.
The prototype will strive to satisfy the users’ needs, minimize negative responses and to increase
the positive emotions occurring when using the prototype. To accomplish this carefully selected
design patterns and user tests were utilized with emotional charts to cover the emotions of the
participants.

1.2 Limitations

Since this project mainly focuses on positive design as well as design choices for redesigning
Chalmers’ Studentportal, it is difficult to also include the process of implementing the program-
ming required to create a new completed website. This simply because there is not enough time.
Therefore, the project only focused on the design process and the implementation of a prototype,
in order to create a respectable design suggestion for the administrators at Chalmers Studentportal.

To make the prototype more accessible, a translation button was implemented in the header of
the prototype. However, the choice was made to not present a throughout translation due to it
not having an impact on the design of the prototype itself and therefore that function is not in the
scope of the project.

Also, not all pages and views from the current Studentportal will be included in the new de-
sign, due to the lack of time and namely that many of the subpages on the Studentportal nearly
have the exact same layout. Although subpages of importance will be included.

8


2 Related Work

The idea of improving programs by redesigning is something that has been discussed before, even
as specific as the Chalmers Studentportal itself. However, when trying to improve a product it
has been seen that users can find themselves confused due to losing their familiarity of the older
product, even though the newer one objectively could be seen as superior. Nonetheless, it has
been shown that Chalmers’ Studentportal lacks functionality and that students find it difficult to
navigate through the website, causing mostly negative association towards the Studentportal.

2.1 Re-design of a room-booking system

Redesign of a university associated website has been done before, as seen with Jonasson, Fjeld,
Yamashita, 2007 [3]. Although the authors did a redesign of a room-booking system and not a
Studentportal, similar methods were conducted in order to achieve respective goals. The authors
wished to understand the factors that have part in a redesign and then evaluate the user interface
for the newly constructed system. To gather data about the user group (students) open interviews
were held which made it possible to set up future requirements. The authors came to the conclu-
sion that they should stay as close to the previous design as possible but with one exception for a
specific feature to satisfy the users’ actual needs. A method called rapid prototyping was used in
paper form, and later tested on the authors themselves. The information gathered was analyzed
and utilized to refine the prototype which led to a final user test on five individuals.

In the end, Jonasson et al. came to the conclusion that small changes to an application with
already experienced users could be crucial and something to keep in mind. The authors mention
so-called power users, who are users that have learned to power through an application’s difficulties.
Because of that there was a shortage of enthusiasm towards the newer design despite the known
issues with the original. “A main contribution to our understanding of re-design and paper proto-
typing of existing UIs was the finding that even a bad UI may have “committed” users. As such,
a re-design may not be as simple or beneficial as initially hoped for“. This issue led the authors
into a conversation about what basic information in the design the users must have in order to
successfully test the prototype. A “no teaching” approach was conducted and the authors could
observe how 66% of the novice users, with no prior experience of the original application, performed
superior in contrast to the two users with prior experience. To finish off, the authors mention that
they would have liked to consider involving the aspect of emotional attachment if the project had
been redone as well as an involvement of a more substantial group of individuals in order to achieve
more established results.

2.2 Analysis of the implementation of the Studentportal

In 2012, the Bachelor thesis “Kundens vilja - programmerarens lag? - Om beställning och utveck-
ling av Chalmers Studentportal” written by Linnea Fritz, Victor Karlsson, Johan Höglund, H̊akan
Andersson and Steven Teng [4], discussed the Studentportal from the perspective of students. With
background from the project management and the economic terms regarding the project, the report
covers the development process of the Studentportal to understand why the Studentportal is what
it is today. The safety and the performance of the website was analysed in sync with user tests on
students studying at the Chalmers University of Technology.

9


A questionnaire was created to gather quantitative data and the responders answered questions
related to how often they visit the Studentportal, if they found it to live up to their standards
and which three functions they use the most. The results showed to be highly negative. Inter-
views were performed and the feedback corroborated the results from the questionnaire in that the
overall perception was negative. Navigation problems, functionality failure and confusing design
were some of the comments. The user tests consisted of for example, navigating the Studentportal,
finding information regarding master studies and booking a group room, where a majority of the
participants had difficulties in succeeding the tasks.

The authors concluded that the project of implementing the Studentportal was an expensive and
poorly executed pursuit and points to the failure of functionality and disappointment among the
users. Lastly they present some design improvements and suggestions, for example constant and
calculated menus, more graphics, additional icons and avoiding dead links.

10


3 Theory

The debate of emotions and their role in design have in the last 20 years grown exponentially [5].
The effort to promote positive emotions through design properties of both services and products
have been discussed by Donald Norman, a member of the National Academy of Engineering [6].
He concluded that emotional design can be identified by two main approaches, both related to
technology design. The first one being based on the modification of an object’s appearance or
interface, and the second one on inviting and encouraging interactions. One way of achieving this
is by the appliance of design patterns.

3.1 Positive User Experience

In research, user experience (UX) refers to a systematic study of targeted audience preferences
and their needs to apply to design processes, practical contexts and observations. UX researchers
use different approaches to identify challenges and design possibilities. The most formal definition
comes from the ISO FDIS 9241-210, which defines UX as “a person’s expectations and reactions
resulting from the anticipated use of a device, system or service” [7]. The standard definition of UX
was introduced by Norman (1999): “all the facets of consumer engagement with the product: how
it is interpreted, understood, and used defines user experience” [8]. This concept indicates that UX
is above the user interface architecture and the usability of a product or service.

Designing a positive user experience is a process that incorporates services or tools in the process
to provide users with meaningful and appropriate experiences. It includes designing and optimizing
the entire product chain, including branding, architecture, usability and other functional aspects.
The ”perception and response of an individual arising from the use and intended use of the com-
modity, device or service is termed as user experience” [9]. It contains all the emotions, convictions,
desires, attitudes, physical and psychological reactions, actions, and achievements of the user be-
fore, during, and after use. However, a positive user experience is affected by the dynamic software
environment or interface, usability, and the contextual settings based on user demand [10].

Furthermore, a software’s user activity also affects UX [11]. Since there is a machine-user in-
teraction, a software activity must be carried out involving time-based input or output commands
and experiences; for example, the higher the user activity with a certain software is, the higher the
user understanding and user satisfaction is. Therefore, if the activity is underestimated the system
will however not be successful in guaranteeing a positive user experience.

According to research, a positive user experience can be defined or estimated using two concepts;
Subjective Well-Being - SWB [12] and Psychological Well-Being - PWB [13]. Psychological well-
being applies to the inter- and intrinsic stages of healthy functioning, including individual rela-
tionships with others and self-referential behaviors that include a sense of self-control as well as
personal development. Subjective well-being represents life satisfaction decisions based on positive
and negative emotions. According to SWB concepts, a good or positive experience can be defined
by three components: positive emotions, absence of negative emotions and satisfaction assessment
[14]. Meanwhile, according to PWB concepts, a good or positive user experience can be defined by
six components, including mastery (such as managing user interaction demands without surpassing
system capacity), self-acceptance, growth, autonomy, purpose and involvement of positive emotions

11


during the web or software use [15].

In addition, a person’s feelings and moods can change frequently and this is something that can
affect the interaction with a product [16]. An emotion that stays with the user for a long time can
change the overall experience with the product especially if it is an interaction that requires the
user to be using the product for a long time. Furthermore, an emotion that stays with the user for a
short time can also have a significant impact on the user experience. These two classes of emotions
have been described by researchers to be either the short-lived automatic type or the long-lasting
conscious type [16]. In addition, it is crucial to understand emotions when designing for the users.

3.2 Design principles

Designers of a product are free to create anything they want, for example if there are a couple
of icons that should be put on a website the designer has the freedom to position them at any
place on the screen. However, there are unique guidelines that can help a creator to improve their
designing solutions and they are known as design principles. They are not mandatory to follow but
they can be seen as essential suggestions that are there to help and aid the designer’s thinking [16].
If the principles are not followed then that will complicate the whole designing process which can
be disadvantageous for a creative team. There are several design principles that can be used by
interaction designers.

The five most common principles, written below, are all described in the book Beyond human-
computer interaction [16].

3.2.1 Visibility

The principle that focuses on how visible and distinguishable the elements as well as functions are
is called visibility. The desired outcome for the designer is that the user completes their goal and
can fulfill the desired usage of the product. An unfavorable result would be that the user becomes
frustrated and aggravated which in turn leads to a bad experience with the product. Therefore it
is relevant to keep all information and elements as visible as possible so that a user knows how to
move to the next step of the interaction.

3.2.2 Feedback

This principle is related to the visibility principle to some extent. When the user has performed
an action or interacted with a specific element, there should be some sort of confirmation provided
to the user, making sure that they have achieved their goal. There are multiple kinds of feedback
for interaction design including audio, tactile, verbal, visuals etc. For instance, if the user presses
a button one would want to confirm this action, either by making a sound or changing the layout
of the page or the button.

3.2.3 Constraints

Constraints is the concept of constraining the interaction when the user is using and experiencing
a design. Some user interactions can be restricted and reduced while others can be completely
eliminated and inaccessible. The principle is especially important in graphical user interfaces and

12


the constraints are of paramount importance in order for a user to accomplish their goals without
making a mistake in the process. For example, if you are using a word processing program and your
goal is to be as efficient as possible then constraints could prevent the user from selecting incorrect
alternatives in the design.

3.2.4 Consistency

The principle focuses on having similar operations and using similar elements across the entire
interface. It is important that a consistent interface follows a certain order and that the structure
is clear. A simple example would be action buttons on a webpage. Buttons with similar purpose
should have the same name, same shape and by clicking them the user performs the same type of
action. However, if some buttons have different colors that will make the user confused and question
if the buttons with different colors act the same. In addition, when using your mouse to navigate
the webpage it is crucial that the input actions of the mouse are consistent as well. There are many
advantages with this principle and that is why it is regarded as one of the most important design
principles. In addition, the navigation will get more effective when users realise that elements on
previous pages act the same as elements on the current page.

3.2.5 Affordance

This principle refers to an attribute of an object that allows the user to know how to use it.
Especially in an interface it is essential that the elements and actions that are presented have a
clear purpose and affordance. A simple definition for “to afford” would be “to give a clue”. For
instance, on a website you have graphical elements that will allow the user to get to the next
page or complete a task. Then it is essential that those elements have a visual style as well as an
interactable appearance so that the user knows that the elements are there to be used. The design
of the elements has to be clear and engaging in order for a person to understand the purpose of it.
A simple text button without any visual design would be very ambiguous.

3.3 Design patterns

Primarily, patterns capture common solutions to design forces and an implementation of one pattern
can differ from the implementation of another one. Furthermore, the patterns will not establish
design decisions and they are also not rules or simple heuristics [17]. In addition, patterns are
structural and behavioral features that improve the “habitability” of something[17], for instance a
user interface. They can also help capture the design experience and a pattern is often seen as a
solution to a problem. One unique feature of a design pattern is that it can be implemented in
several different ways [16]. They also make things easier to understand and they can also make
things more beautiful. Furthermore, with the help of patterns tools become more useful as well
as usable [17]. Patterns work with human senses and psychology and the design patterns come
from the ways people perceive and use software. In addition, the design patterns form the building
blocks for user interfaces [18].

The patterns described below are all from the second [17] or third [18] edition of Tidwell’s De-
signing Interfaces.

13


3.3.1 Escape hatch

The escape hatch is a pattern which enables the user a safe way out of the page that the user
is currently on and navigates them back to a more familiar page, for instance the homepage on
the website. As a result the users are less likely to feel trapped on the website which promotes
safe exploring. The escape hatch could consist of a link, a button, or the most common approach,
having a clickable logo in the header which navigates the user to the homepage.

3.3.2 Feature, search, and browse

The pattern consists of three elements; a feature item, a search box and multiple items that the
user can browse through. The combination of these three elements works well for different kinds
of users. The users who know what they are looking for can use the search box, while others can
browse through the content that is presented on the page. The feature element can be a visual
or something else that captures the users interest. Its purpose is to directly engage the users by
presenting something interesting to make the page feel more inviting. The pattern is well suited for
websites where one presents a lot of information as well as when one wants to engage the users.

3.3.3 Fat menus

Fat menus is a pattern where a website’s subpages are placed in a fly-out or a drop-down menu.
The menu can contain all subpages of the website or just a few sections. The content of the menu is
sorted into categories and the pages hierarchy is often visualized. Fat menus suit well for websites
with many pages and when the hierarchy of subpages are larger than two levels deep. By usage of
a fat menu one can present many navigation options to the user which might have gone unnoticed
otherwise. The pattern provides a simple way to explore a website further and gives a quick and
easy overview of what the website contains without needing to navigate through it. As a result
comes the decrease of unnecessary or additional steps and an efficient navigation.

3.3.4 Sitemap footer

The concept of the sitemap footer is categorization of links at the bottom of the page. The most
common information located on the footer are the websites most visited pages, contact information
and other resources connected to the site, for example social media. The sitemap footer provides
users with further navigation options which in itself enables the site to become more explorable.
Since every page on the website has the sitemap footer it creates continuity on the entirety of the
website and gives the users an effective one-click option to navigate to different popular or important
pages.

3.3.5 Breadcrumbs

Breadcrumbs are a way of showing previous navigation steps users have taken by writing out the
name of the last pages the user has visited. The pattern suits sites or applications where the
architecture has hierarchy and tries to counteract the feeling of getting lost. Not only does it
provide clarification for where the user is located in the hierarchy, but it also provides the user a
different way to navigate backwards to a familiar page. A common way of executing this pattern is
by the use of the greater-than sign. For instance, “Start page > Summer Olympics > Rules”. The

14


breadcrumbs indicate that the user is located on the page “Rules” and that it is deeper down in
the hierarchy. The purpose of the pattern is to give the user context to the page.

3.3.6 Visual framework

By having all pages or screens throughout a site or application follow the same layout, style and
characteristics, one is said to follow the visual framework pattern. It provides familiarity to the
user which leads to a faster learning process and a more effective and comfortable user experience.
Furthermore, if one repeats the same layout throughout the website the visuals that are constant
across pages blend into the background thereby making content of importance stand out better.
This directs the user to what they find attractive.

3.3.7 Grid of equals

When content is placed in a grid, or matrix, where all items should be of similar and visual weight
the grid of equal pattern is applied. This clarifies to users that the items are comparable or of equal
importance. The grid could contain items such as blog posts, news articles or products which are
all selectable. Visually it gives a neat and calming experience.

3.3.8 Right-left alignment

When making a two-column table of some sort one should make sure to have the text labels at the
left right-aligned and the other item that is placed on the right left-aligned [17]. The pattern makes
it easier for users to connect the label to the associated item without white space in between. If
the labels are of a longer sort, one should consider not using right-alignment since it is harder for
the human eye to perceive where the beginning of the line is.

3.3.9 Input prompt

The pattern input prompt makes use of prompts in various items such as text fields or drop downs
when wanting the users input. The purpose of the pattern is to give the users some sort of hints
to what is expected of them, by the use of a prompt. For instance, when filling out one’s name
in a registration form there will sometimes be two boxes next to each other. By using a prompt
that says “First Name” in the first one and “Last Name” in the last one the user needs next to
little time to complete the task. The use of input prompts may have such effectiveness that the
correlated labels are not needed from time to time.

3.3.10 Prominent done button

The prominent done button is a great way to offer some sort of closure to the user at the end of a
process. It is a clearly visible button, often designed with a color that stands out and with defined
borders. It should be placed at the end of the visual process that is portrayed on the screen and
close to the last text field. This makes the user connect the association with the button and the
text fields easier. Lastly the button should have a concise and short label, for example “Done”,
“Send” or “Submit”. By the use of a prominent done button one diminishes the risk of having the
user being confused by if their inputs were taken effect after all.

15


3.3.11 Hover or Pop-Up tools

By the use of hover tools designers get a cleaner interface by hiding information, such as text labels
or buttons, on items [18]. These stay hidden until the user hovers over said items, with a purpose
of decluttering the screen and decreasing the risk of users being overwhelmed. The pattern is often
used when the interface, often a list of items, handles a lot of smaller items, such as pictures,
messages etc.

3.3.12 Module Tabs

If you have a website with a lot of information and text that you want the user to interact with
it is crucial that the content is visible as well as approachable. Especially, if the information is
important you want the user to see it directly but it is difficult to put all information on one screen.
By using module tabs this problem can be solved and assist the user to be more effective. Each tab
represents a different new screen and when you press on one of the tabs you get to a new screen
with new information and the tabs will always be in static positions and not disappear. Often the
content of the modules are related or similar to each other.

3.3.13 Accordion

This pattern can be very similar to the module tabs pattern and both of them are used when it comes
to grouping a page’s heterogeneous content. If you have a lot of text and additional information
on your page and the amount of available room is limited then the modules are significant. By
clicking on one of the panels the user can view the additional content that is connected to that
panel. Compared with tabs the panels can be closed and opened independently of each other. The
accordion modules can be arranged freely by the user depending on the situation. Perhaps all panels
should be opened so that the user can see all the content or perhaps only some of the panels should
be opened so that the user can be more efficient. Conclusively, all of the extensive information of a
page can be enclosed within one element where parts of the information can be viewed separately.

3.3.14 Carousel

This pattern is an engaging visual design and especially effective if one has many items or elements
that the user could interact with. The items are placed horizontally and can be viewed from side to
side via scroll or swipe. Compared with other solutions the list of items can not be moved vertically
and instead the user has to browse through the elements back and forth. A user can easily navigate
and explore the different items. The common structure of the elements is that they are represented
as images or thumbnails. The content of the items should be of interest to the user and be relevant
for the situation.

3.3.15 Pagination

A common pattern that is often used to take a lot of information and split it up on several pages
is called pagination. To assist the user’s navigation and exploration of the content the pattern
provides a control element where the user can choose which page to view. The pattern is made up
of buttons with numbers that indicate the available pages and in addition two buttons you can click
to see the previous or next results. Arrows or pointers are common tools to help the user navigate
the different pages by clicking on them. The current page will be highlighted in the control area.

16


3.4 Web Accessibility Directive

On the 23 of September 2018 the Web Accessibility Directive became a law in Sweden and in the
EU. The law was created to handle requirements regarding accessibility on the internet and applies
to public sectors, state and municipal companies [19]. The background of the implementation of the
law is that everyone no matter disability should be able to navigate the internet [20]. To follow the
accessibility standards there are four principles to uphold, the first one being Perceivable, meaning
that the content provided should be presentable to the users in ways that they can perceive [21].
The next being Operable, the webpage navigation and components must be operable. Understand-
able refers to the information on the website being understandable, and lastly the Robust principle
meaning that the website should be able to perform across different platforms.

The law handles the entire process of implementing a website, from stakeholder demands, plan-
ning, designing, developing to maintaining the website [22]. From a design point of view, the law,
for example, requires that information on a website should not rely on color schemes. Taken in
consideration that multiple people experience color blindness and information can easily be missed
if the colors of a text is too similar to the background.

17


4 Method

In order to achieve a positive user experience by the end of the project, a myriad of methods were
used in the process. The process itself is divided into three main sections: Data Gathering, User
Requirements and Prototyping. The information gathered from the users was used to create project
requirements, which were then used as guidelines for prototyping and designing. All participants
were informed beforehand that the data gathered would be anonymous and non traceable back to
them.

4.1 Data Gathering

At the beginning of the project a questionnaire was distributed among students to collect quanti-
tative data, and some structured interviews were performed in conjunction with smaller user tests
to collect qualitative data about the intended users. The decision to combine both approaches was
made in order to provide a more detailed account of the observed behaviors and feelings [16]. In
addition, an expert review of the Studentportal was written, and Chalmers employees responsible
for the Studentportal were contacted to initiate a potential collaboration.

4.1.1 Interviews

A structured interview is an interview with a predetermined set of questions as opposed to an
unstructured interview where the questions are improvised during the interview [23]. It is most often
done one-on-one with one interviewer and an interviewee and possibly an observer who documents
the procedure. The data gathered from both structured and unstructured interviews is considered
to be qualitative data because of the interviewers ability to ask follow-up questions and dig deeper
in subjects where it seems as if there could be valuable information.

4.1.2 Questionnaire

A questionnaire is a form filled with questions about the domain or product that is distributed
amongst users as well as potential users to be answered and returned [16]. There are many ways
of doing this but the most common is an online document due to its simplicity. Questionnaires are
easy to distribute which means that there will most likely be a substantial amount of responses. In
contrast to interviews the data gathered from questionnaires is considered quantitative data rather
than qualitative because it is difficult to write questions that give good answers or follow-ups on
something the users noted. When analysing the data from questionnaires you are looking at overall
trends instead of individual answers.

4.1.3 Stakeholder

In the beginning of the project the responsible staff of the Chalmers Studentportal were contacted
and they became the stakeholders of the project. Stakeholders are groups or individuals that can
either influence or be influenced by the outcome of a project [16]. The project’s stakeholders
contributed with statistics as well as information about the state of the current Studentportal and
in return they received results from the project’s process.

18


4.1.4 Expert Review of the Studentportal

An expert review is an evaluation method where people who have good knowledge of user experience
and user populations reviews a product to look for possible problems or errors [16]. To comprehend
the problems of the current Studentportal an expert review, created by the developers of this
project, was directed at the content as well as the visual elements of the entire webpage. The
purpose was to find areas on the current webpage that are confusing and unclear. This method is
helpful because when a problem is found in the early stages of the project, the sooner a solution
can be designed to solve the problem.

4.2 User Requirements

The reason behind the user requirements was to be able to see the project through the intended
users’ eyes and to know which direction to take the design. With personas and scenarios the needs
of the users could be captured, and the structure of the work process was built upon requirements
and user stories.

4.2.1 Personas and Scenarios

A character based on a target demographic is called a persona and is created to help developers and
designers to be able to identify a group of users [24]. The persona is given a name, age, occupation,
interests and usually includes a chart representing different levels of characteristics, for example
optimism, patience or technical knowledge. By using personas the needs of the users can be shown
graphically along with their preferences. The usage of personas is a good way to make objective
design decisions that will benefit the later users.

A scenario is a made up story regarding a user’s tasks or activities. It is common that a sce-
nario shows an existing situation, but it is more commonly used to picture an imaginative scenario
to be of support in the design process [16].

4.2.2 Constraints and Requirements

Limitations on a design is called constraints, it can be both constraints made by the designer to
make a way to improve the design or constraints that the designer has no control over [25].

Requirements are written based on results from data gathered to be able to turn concepts into
design features [26]. Requirements specify what should be required of the final product in order
to ensure that it meets the needs of the intended users. For example, by dividing requirements
among developers the process can be made smoother and timelines can be more easily organized.
A requirement may look like this:

”The frontpage of the prototype should have categorized information and content to ease the nav-
igation”.

4.2.3 User Stories

The growing prevalence of user stories legitimizes the notion that software experts view them as
valuable tools to identify and reflect accurate user-based requirements [27]. User stories are com-

19


mon approaches to classify requirements, often using a basic template like:

“As a ... (describing role), I want ... (describing goal), so that ... (highlighting benefit).”

According to Lucassen et al., the inclusion of user stories is increasing and it is significant in
research, particularly in the sense of agile development of software applications [28]. The user sto-
ries served as guidelines throughout the entire process to make sure that any design decisions are
based on the future users and that the purpose of the project is not lost along the way. A small
selection of the user stories used in the project can be found in Appendix F.

4.3 Prototyping

The entire prototyping process was based on the method of Rapid Prototyping [29], a cycle that
consists of three phases: Prototyping, Reviewing and Refining. Prototyping revolves around the
creative process of making some sort of a design, reviewing handles the process of testing on users
and gathering data, and refining identifies the problems that need to be fixed or clarified in the
next cycle. This project consists of two cycles, called iterations 1 and 2. Before iteration 1 could
begin, a series of paper prototypes of a frontpage were created and reviewed to establish some sort
of foundation of the design for iteration 1. As with data gathering, the feedback from users after
testing were anonymous and the participants were all made aware of this.

4.3.1 Paper prototyping

As previously mentioned, the foundation was built on a series of paper prototypes, which is a
technique for sketching designs on paper with a pen. The method is fast, accessible to everyone,
and does not require any special equipment, [29] which was the primary reason for its use. This
process was also an iterative one. Each person sketched individual ideas to later be shown and
discussed in the group. The feedback from others laid ground for the next individual sketching
session where other people’s ideas were further explored.

4.3.2 Think-Aloud-Protocol

The Think-aloud-protocol refers to the practice of participants freely speaking to whatever is on
their mind [23]. The method was utilized in all user tests to gain a complete picture of the user’s
actions of the product. Throughout all the user tests, a series of scenario-based questions asked
users to complete specific activities, for instance to navigate to different pages or describe thoughts
and feelings about different features and elements. It is an effective tool because it accurately
represents participants’ thinking processes, offers useful insight into which challenges that occur, and
demonstrates how people handle website activities [30]. However, there is an underlying possibility
that the subject will become mute and lose the energy or motivation to continue speaking [23]. To
diminish the risk of this happening the group decided to complement certain cases with a series of
follow-up questions if necessary. Everything expressed by the participants was written down in a
document and compiled to later compare all answers and make a conclusion of what features need
to be arranged, removed or implemented.

20


4.3.3 Emotion Chart

To conclude the user tests in iteration 1 and 2, an emotional chart with system descriptive adjectives
were shown to the participants. This technique is based of another method that uses emotions
written on cards [31], but it was implemented differently to fit the project’s user test format.
The chart used in the user tests consisted of three different tables. Each table was either filled
with positive emotions, see Figure 1, negative emotions or system descriptive adjectives (additional
figures can be viewed in Appendix E). Participants were asked to circle or underline the emotions
and adjectives they experienced throughout the entire user test. The purpose of the chart was to
provide insight to if the prototype enhanced the user experience, hopefully making it a positive one.
To establish if there had been improvements in the overall user experience the emotions perceived
during iteration 1 were compared to iteration 2.

Figure 1: Chart showing 25 positive emotions a person can potentially experience. If the participant
felt any of the 25 options, it was to be filled out in the chart.

21


5 Data Gathering

Two methods of operation were conducted to gather information about the users’ feelings and
issues regarding the user experience of the Chalmers Studentportal. The two methods consisted
of a questionnaire and some interviews combined with smaller user tests. Based on the results,
requirements, scenarios and personas could be developed to set up some sort of guidelines for
future work, and as a reminder that it is the users’ needs and issues that must be the project’s
main focus.

5.1 Questionnaire

To get a better understanding of what the overall opinion of the Studentportal is among students at
Chalmers, a Google Forms questionnaire was created. The questionnaire mainly focused on what
students think of the Studentportal in its current state, what they believe the website lacks, what
they find positive about the website, the navigation and appearance of the Studentportal and lastly
what they value in a good website. Since this questionnaire’s purpose was to collect quantitative
data the questions were limited to yes, no and rating questions, to make it easy to view the results
and get a clear overview of the opinions regarding the Studentportal. Additional questions and
answers from the questionnaire can be seen in Appendix A.

In total, 107 students answered the questionnaire ranging from first year to fifth year students. Re-
garding the program range, Software engineering was at a big majority with 70,1% of the responses.

The answers showed that 61.7% of the students state that they visit the website less than once
a week and based on the questionnaire the overall opinion is negative. One question proving this
theory was regarding the overall rate of the Studentportal, from functionality to user experience,
the results can be viewed in Figure 2.

Figure 2: Shows the responses of the question from the questionnaire: “How would you rate
Chalmers Studentportal as a whole? This includes anything from functionality to the user expe-
rience”

When asked if the participants knew where to find information regarding Scholarships, 61% did
not know where to look, 27.1% stated that they were not sure and 15.9% knew where to find the
information.

22


For the question “What do you value most in a website? Choose multiple if desired.”, the re-
sults show that navigation, readability and content were of importance to the participants, as seen
in Figure 3. This was taken further into consideration in the design process and the results were
valuable when designing the firsts prototypes.

Figure 3: Shows the answers on the question “What do you value most in a website? Choose
multiple if desired.”. The table’s choices was modified to show the categories clearer.

5.2 Interviews

To advance the data gathering process, interviews followed by a small user test on Chalmers Stu-
dentportal were conducted with a total of 11 participants. The sole purpose of the interviews were
to identify problems with the current Chalmers Studentportal and to get a better understanding of
the users’ needs, which will later help to produce such things as requirements and scenarios. The
user group consisted of students from different programs at Chalmers, but most of them from the
Software engineering department. All questions can be found in Appendix B.

To begin the participants were shown the already existing website and were asked open-ended
questions to explain their use and feelings towards it. This with the intent to not steer the partici-
pants in a specific direction and to receive a deeper understanding of underlying issues and needs.
Questions like ”What do you feel is important to achieve a positive user-experience?” and ”What
do you use Chalmers Studentportal for?” were asked in order to reach the aforementioned goal.

Afterwards the participants were subjected to three small navigation tests of the Studentportal
and were asked to locate crucial information that every student at some point in time needs to be
able to find, such as the contact information of their programs’ student counselor, or all mandatory
courses in the second semester. Think-aloud, a method of data gathering, was used to let the
speakers communicate freely to whatever is on their mind. One downside of this method is the
possible unnatural situation that might occur [32]. Most people do not talk to themselves everyday,

23


which could make it harder for participants to constantly speak their minds without a second party
to discuss with. To diminish the risk of this happening, the previously mentioned interviews were
held in the beginning to loosen up involved participants, as well as the use of situational follow-up
questions if necessary. Participants performed as mentioned three navigation tests on the website
and were lastly asked some conclusive questions about the entire process.

After the results were compiled and compared, it was possible to see two main areas that were
brought up by the majority of the participants. First, the mostly negatively experienced emotions
but also some key general thoughts they had about design overall. The results can be seen in the
list below.

Emotional experiences

• Irritation

• Frustration

• Confusion

• Stress

• Feeling of fulfilment when completing tasks

Key parts of the design

• Effective navigation

• No abundance of information

• Consistent design

• Clear structure

5.3 Analysis of the Content of the Studentportal

When the results from the questionnaire and interviews were compiled, a complete expert analysis
of the content on the Studentportal was conducted [2]. This was done to get an understanding of
the information currently on the Studentportal and to know what information to use in the coming
prototypes

5.3.1 Approach

The analysis was done in the swedish version of the Studentportal because there is more informa-
tion in that version, an example being that there are five main titles in the Swedish version, and
only four in the English one. The English version is missing the subject “Studies abroad” which is
logical since exchange students are already studying abroad from another school.

The Studentportal was divided into seven parts, “Studier” (Studies), “Utlandsstudier” (Studies
abroad), “Studentliv” (Student life), “Karriärkollen” (Career check), “Kontakt” (Contact), the
search function and lastly the frontpage. Each page and subpage got investigated throughout and
every detail was being noted and commented on in a document along with short comments regarding
the information on the page.

24


5.3.2 Conclusions

There are many flaws in the current Studentportal, both regarding information and structure. Some
examples are sections having different titles than what is shown on the side menu which could cause
confusion. There are multiple occasions where shortcuts on a subpage leads back to the same sub-
page.

On top of this there is an overwhelming amount of information that is duplicated across multiple
pages which sparked conversation regarding whether this is a positive or negative thing. However,
the conclusion came to be that together with the confusing navigation the duplication of informa-
tion would be unnecessary if the navigation was easier.

Questions regarding the structure emerged. It is clear that there are too many administrators
for different pages. Every page at the bottom has the contact information for respective adminis-
trators. If too many people have access to updating the website which is using different techniques
to present information, it is plausible that the core structure across subpages becomes non-existent.
This is possibly one of the reasons why many students find it messy and unstructured.

5.4 Stakeholder

To get more insight in the work and state of the current Studentportal a meeting with five people
from Chalmers External Communications department and Student and Alumni relations depart-
ment was held online. Their roles were, Unit manager for the External Communication depart-
ment; Ingrid Claesson, Unit manager for the Student and Alumni relations department; Ulla-Karin
Drakeskär, Communicator for the Student and Alumni relations department; Helén Rosenfeldt,
Brand strategist for the External Communication department; Pär Svensson and lastly webmaster
at the External Communication department; Johan Wetterberg. To make this process easier to
comprehend this group of people will in the future be referred to as the stakeholders.

After the project was introduced, conversations regarding the current Studentportal’s state was
held. The stakeholders confirmed the problems regarding the maintenance of the Studentportal,
and stated that there are multiple people updating the information on the website, which can cause
confusion among users.

The feedback was positive and the stakeholders were excited to hear about the project and wanted
to receive later user tests made on the current Studentportal. A reason for their excitement was due
to the fact that the Studentportal in the near future needs to be reconstructed due to its current
framework being outdated.

The stakeholders provided statistics on what pages the users use the most together with recommen-
dations on websites covering inclusion and web guidelines. Additionally the stakeholders provided
the project with images and gave permission for the use of images that can be seen on the website.

The contact with the stakeholders was held during the whole project and the finished version
was later presented to them.

25


6 User Requirements

When the first round of data gathering, surveys and interviews was finished the work on guidelines
that could be followed throughout the project to ensure a positive user experience began. This by
making sure that the users are in focus by the use of Requirements, Constraints, Personas, Scenarios
and User-stories. Specifically, requirements and user stories have been updated along the way to
make sure that the project is adapting to newly discovered data or information.

6.1 Constraints and Requirements

The constraint ”The last iteration of the prototype should be finished before summer 2021” was the
only one made for this project. The reason for having only one constraint was due to the project
only consisting of designing a prototype. Therefore many of the common constraints that you may
encounter when actually implementing a website were not relevant.

To have a moderate and precise direction for the future of the project, requirements were es-
tablished to be looked back upon. They were written based on the understanding of the newly
discovered problems with the Studentportal, for example, navigation and unpleasing or cluttered
design. Listed below are a few of the requirements that are needed to be fulfilled in order to see
the outcome as a success.

• The finished prototype should give the users a positive user experience.

• The finished prototype should allow the user a quick overview of the homepage.

• The finished prototype should allow the user to navigate to important student websites such
as Ladok, Canvas and TimeEdit.

• The finished prototype should view relevant program information for a logged in student.

• The finished prototype should categorize information and content to ease the navigation.

• The finished prototype should have a calendar that is precise and universal.

• The finished prototype should have eye-pleasing colors for the content and elements of the
pages.

6.2 Personas

In order to discover the requirements it is important to understand the users’ motivations, behaviors
and needs. Creating personas is a suitable method to exemplify and define these factors to help
designers keep focus throughout the process [16]. Two personas were created, one primary persona,
Robert 24 (Figure 4), and one secondary persona, Klara 19 (Figure 5).

The personas were created based on the data from questionnaires and the first interviews. The
”Goals” section, as seen in Figures 4 and 5, is a representation of what the participants said that
they used the Chalmers Studentportal for during the interviews. The section of ”Frustration” is a
representation of a mix between what the users said irritated them during the first interview and

26


what the users answered on question six ”What do you value most in a website?” in the ques-
tionnaire. To confirm the quality of the personas it was argued that it is appropriate to have two
different sets of characteristics to be able to cover a larger group of students at Chalmers.

The concept of personas was utilized to create a concrete and realistic picture of a user. This
was helpful throughout the process by motivating all stages of design decisions, functionality and
prioritization of elements in the prototype.

Figure 4: The persona of Robert 24, including a biography, his skills and goals.

27


Figure 5: The persona of Klara 19, including a biography, her skills and goals.

6.3 Scenarios

Scenarios were written after the initial data gathering which yielded much information regarding
how the students use the Studentportal and what for. Scenarios were done in order to clarify what
the users might experience and to visualise problems and solutions. Ten scenarios were created
in order to cover as many instances as possible, two of which can be seen below. The scenarios
are based on the previously mentioned personas. The information in the scenarios below regarding
navigation are from [2].

6.3.1 First Scenario - Robert

Robert, one of the personas, does not know which master program he wants to apply for. He has
never contacted his section’s student counselor before but decides that now is a good time to do
so. He does not remember the counselor’s name and decides to log into the Studentportal to find
out. The first view he sees is the ”Mina sidor” (my pages) and a lot of menu choices are seen, he
quickly finds the ”Kontakt” (contact) button. There he finds the ones being responsible for different
errands and their emails. He scrolls through the page and finds a link to student counselors and
clicks it, getting a bit annoyed due to the time it takes. A question pops up asking if he studies at
Bachelor studies or master studies, after choosing Bachelor studies he is taken to a page where all
of the programs at Chalmers are listed without the contact information to the student counselor.
By this time Robert has almost lost his patience, finding it hard to believe that it would take this
long to find the information. He finds his program in the list and clicks it and the page jumps down

28


to the student counselor of Mechanical engineering where the email address can be seen. Overall
he did not find the information difficult to find but the time it took was frustrating.

6.3.2 Second Scenario - Klara

Klara, the second persona, is studying her third year at the institution of Software engineering at
Chalmers and wants to find information about the available programming courses. She sits down
on her couch at home, opens her computer and logs into Chalmers Studentportal. When logged
in, Klara is navigated to a page with multiple menu options. She gets somewhat frustrated that
there are too many choices, many of which she sees as unnecessary. After a minute of hesitation,
Klara presses the menu ”Sök Kurser” (search courses) which brings her to a page which asks her to
manually fill out information about the course she is looking for. She gets a bit confused since she
does not know exactly what she is looking for. Instead she navigates to the link ”Sök program och
utbildningsplaner” (search programs) at the top of the page. She ends up at a similar page as the
one before, but this time she finds her institution faster and clicks on it. She feels unmotivated to
keep going since her motivation for her studies overall is quite low, but she tries to be optimistic.
The page Klara is located on shows her all courses that are both mandatory and elective. She
would have liked to get rid of all courses not related to programming but as she is quite good at
computers, she figures out that it either would have taken too much time to do, or the functionality
does not exist. Instead she writes down all courses she could find on a paper.

6.4 User stories

The user stories used ranged from being able to quickly access shortcuts, being reminded of impor-
tant dates, to the implementation of hover tools. A few of the user stories used in the project can
be found in Appendix F.

Hence, from the user stories, almost every student needs a modified website or menu on the Stu-
dentportal to navigate their courses, finding new resources, getting timely details or information
regarding their progress, upcoming courses and so forth. Five of the user stories used were:

• As a student I want specific information about my program and my year to be shown as a
default so I don’t get shown unnecessarily information that I don’t care about.

• As a student I want an accordion in the menu so I don’t get overwhelmed with too much
information and can find the right page easier.

• As a student, I want to be able to reach Ladok from the Studentportal so that I can check
my finished courses and my grades.

• As a student, I would like to be able to see what future courses I have so that I know what I
will be studying.

• As a student, I want to be able to find information about mandatory or elective courses so
that I can plan my curriculum to the best of my ability.

29


7 Prototyping

The prototyping process began with paper and pen and continued in the prototyping tool Figma.
The project progressed iteratively by brainstorming and creating design alternatives, user testing
and lastly analyzing the answers from user tests in order to change and update the prototype. The
user tests were performed in Swedish due to it being the native language of the participants which
hopefully diminishes any risk of confusion in translation.

7.1 Paper Prototypes

Instead of determining which specific direction the design would take early on, a brainstorming
session was held, meaning each person quickly sketched their own idea individually for a frontpage
to later be compared and discussed. An example can be seen in Figure 6 and more examples can
be found in Appendix C.

Figure 6: Initial idea for a front page for the new Chalmers Studentportal with prominent features
such as shortcuts to Canvas and Ladok, a calendar and a smaller news feed.

These prototypes were then remade in the prototyping tool Figma to be more appealing, see Ap-
pendix D. For one of the prototypes a few subpages were created to show a little bit of framework
and also to have more material to present to the participants.

7.1.1 Reviewing

A presentation of all the prototypes were created and shown to a group of 10 people to receive
feedback regarding the frontpage and framework for the Studentportal. The most popular frontpage
can be seen below:

30


Figure 7: The participants’ favorite front screen.

7.2 Iteration 1

After receiving the results from the first user test, regarding the frontpage and the information
gathered from the first interview, see Chapter 5.2, the first iteration began by using the most liked
prototype frontpage as a foundation.

7.2.1 Prototyping

The process began by looking into what the users liked about the leading prototype, as seen in
Figure 7 and it was the shortcuts, the clear view and the symmetric elements. When the prototype
expanded the things the users liked were continually kept in mind. A lot of focus was put on the
header and footer of the page since these would appear on every page. The main color was changed
from a clear blue to a more soft blue version. Since there is a lot of information to cover it was
decided to start with information regarding ”Studier” (studies). This was due to the statistics pro-
vided from the stakeholders showing that studies are the most viewed pages on the Studentportal.
To achieve a more efficient navigation than in the current Studentportal an accordion was created
where the links for the subpages were categorized into three sections, see Figure 9b. By analyzing
the previous expert review, see Chapter 5.3, a new arrangement of the subpages could be established.

To have more material for the users to test, a few of the user stories were implemented, see Ap-
pendix F, such as a contact page for the Software engineering department together with a page for
important dates and finally a page for the program specific courses. By the use of patterns like
right-left alignment, grid of equals and visual framework the subpages became structural as well as
intuitive.

7.2.2 Reviewing - User test

An important part to test was the navigation and therefore the accordion was of importance. In
total, 10 people from different programs took part in the user test. The questions covered mainly

31


navigation and the organization of the information on the pages, since aesthetics and visuals had
not been in focus thus far. The test involved the same questions as the first interviews regarding
the current Studentportal, in order to compare new difficulties that might have occurred due to the
newly established design. The feedback was positive and a majority completed the tasks without
problems and the visual contact page was appreciated, see Figure 8. One thing noted by the
participants was that the alignment as well as the symmetry of elements in a few pages was a bit
off.

Figure 8: Newly designed contact page, showing contact information for the Software Technology
Institution and Chalmers in general.

To finish off the user test, the participants filled out an emotion chart. The chart is filled with
positive, negative and system descriptive adjectives to further help the understanding of the user
experience involved with the prior navigation tests. If an emotion was experienced during the nav-
igation tests it is supposed to be filled out in the emotion chart.

The most perceived positive emotions were ”relaxed”, ”satisfied”, ”pleased” and ”enjoyment”.
Only one negative emotion was experienced among the participants, this one being ”uninterest-
ing”, stated by one participant. Some of the system descriptive adjectives mentioned were ”useful”,
”fast”, ”structured” and ”understandable”.

7.2.3 Refining

With the feedback provided, discussions regarding the navigation, alignment and the accordion
occurred. To further enable easy navigation, breadcrumbs and an escape hatch were implemented.
The structure of the information under the menu ”Studies” was to be further discussed with dif-
ferent approaches to make it more clear and easy to navigate through. Since not all of the pages
were implemented in the prototype at this stage, discussions regarding further subpages were held
to establish scenarios. The previously written requirements were investigated once more together
with the personas, this in order to receive inspiration and to focus on the user experience. The
bugs found in the prototype were corrected.

32


The emotions experienced by the participants were at a majority positive responses. Since navi-
gation was of importance at this stage, feelings such as ”fast”, ”understandable” and ”structured”
were appreciated. The feeling ”uninterested” was concluded to not have anything to do with the
navigation of the prototype. However, to avoid later prototypes from being uninteresting imple-
mentations such as a carousel on the frontpage was considered together with the feature search
browse pattern.

New requirements were written covering how information was to be presented and the structure
of new subpages as a result of newly gathered information. The personas and their scenarios were
observed once again to remember elements that were of importance when prototyping.

7.3 Iteration 2

With background from the previous user tests and the written requirements the second iteration
proceeded, mainly focused on the implementation of subpages and the visual framework of the
prototype. A drop-down menu was implemented, functioning as a module tab, to be able to
navigate between different subpages.

7.3.1 Prototyping

To be as efficient as possible, a template for the subpages was created so that every subpage had
the same framework and distance from other elements. The prototype was divided into three parts
for the purpose of separating the content and to follow the pagination design pattern. These three
were; Studier (studies), Utlandsstudier (studies abroad) and Studentliv (student life), where studies
can be viewed in Figure 9b. With the template, the subpages were divided among the group and
could be worked on individually. User stories were distributed and patterns used for the subpages
were for example prominent done buttons, breadcrumbs, hover tools, grid of equals and accordion.

There were three goals with the design of the subpages; making the groupings and titles more
clear to aid in navigation, making it more clear where the user is in relation to the rest of the
website and reducing the time and clicks required to find certain pages.

Finally the frontpage was updated with the implementation of a new and more discrete header, as
seen in Figure 9. Further new implementations included a carousel, a calendar page and a news
page, which followed the grid of equals-, pagination pattern among others. To follow the feature
search browse pattern, a search page was made which was reachable from the header on every page.
The input prompt pattern was used to create a user profile page, see Figure 10, with functions for
changing the student’s program and which program to be set as default across the different pages.

33


a) b)

Figure 9: The second iteration of the frontpage with features such as a carousel and links (a) and
example of the accordion used in subpages (b).

Figure 10: The prototypes profile page covering personal settings.

34


7.3.2 Figma Memory Usage Problem

When prototyping large files in Figma a project can reach the active memory limit at 2 GB. The
higher the percentage is, the higher the chance of losing data becomes. When the active memory
limit reaches 100% Figma will lock the file, if this happens one must close all the Figma tabs and
reload the page. Figma may let the user open the file to restore it to a previous version, however
it is very unstable [33].

When the final implementations of the last subcategories were created, a Figma alert started to
appear, implying that the file was almost out of memory. The first alert came when memory was
at 60%, the warning alert was:

“This file is almost out of browser memory. Remove content to lower memory use to 50% or
less. This will ensure you can continue to work in this file safely.”

After removing a few frames in Figma the work continued, however, later a new alert appeared,
when the memory was at 75%,

“Adding content is no longer safe as data may be lost. Remove content to reduce this file’s memory
use or restore a previous version.”

As a result, it was unsafe to continue adding views as well as connections, and the work needed
to be paused. After further discussion it was decided that only one person should work in the
Figma file since it was discovered that when several individuals simultaneously worked in Figma
the memory usage increased. As a result, pages and views that were found to be unimportant were
moved or deleted, to be able to have more memory access for the improvements of the prototype
after later user tests. After feedback from the supervisor, elements such as the sitemap footer were
remade into components with the intention of saving memory, however the memory usage stayed
almost the same as before.

7.3.3 Reviewing - User test

The user test followed a similar structure to the first iteration by utilizing the same emotional charts
and many of the same tasks were reused in order to compare. In addition, the test also contained
more assignments to investigate features that had been added since the first iteration as well as
questions about stylistic choices. New test participants were scouted to reach a larger group and
seven people participated in total.

The user tests started with questions about stylistic choices by showing the participants images
of different options and asking them to pick the most appealing one. They were asked to focus on
aesthetics and the first choice was between three different fonts. The second test was between four
different color palettes, see Figures 11a and 11b. The final test was between two different menus,
one called a fat menu, see Figure 12a, and a smaller drop-down menu, see Figure 12b.

35


a) b)

Figure 11: The green color palette visualized on the prototype (a) and the three other options (b).

a) b)

Figure 12: Two examples of a menu tested on participants, a fat menu (a) and a drop-down menu
(b).

The second part of the user test the participants were given tasks to complete identical to the
previous tests. Some examples of recurring tests are finding a student counselor or finding what
date the exam week starts. Some new ones were for example finding contact information to the
people responsible for studies abroad in America or finding information about how to arrange
an event at campus. Once completed the test persons had to answer a few questions regarding if
the prototype followed design principles, ranking the principles with either a low or high mark (1-5).

Lastly, the participants were once again asked to fill out the emotional- and the system descriptive
charts. The results showed very positive emotions such as ”satisfied”, ”happy”, ”interested” and
”relaxed”. A negative emotion that came from one of the participants was ”overwhelmed”.

36


7.3.4 Refining

Once the results were summarized a few conclusions could be drawn. The second font style, Arial,
was voted the best. Regarding the color palettes, the opinions varied and it was decided to keep
the current palette since it had a high rank among the users. The most popular menu became the
fat menu, since the participants found it to be the most practical.

From the tests and rankings it could be concluded that the prototype functioned as intended
and the users had no trouble navigating it. Most of the friction that occurred during the tests was
due to of bugs and not design flaws and the participants gave a rating of around 4.5 out of 5 on
almost all of the alternatives.

For the emotions perceived, this time focus was not only on the navigation but the overall sense
of the prototype. Previously, in the user test of the first iteration, the negative emotion ”uninter-
ested” was mentioned, however, it was not mentioned during this user test which was seen as very
beneficial. Regarding the negative emotion ”overwhelmed” it was considered it could depend on
the participant seeing the prototype for the first time and recognizing elements but not the new
framework, something that also the specific participant could confirm. However, the critique was
examined and reviewed.

7.4 Final Touches

In the final stage, the main focus was put on last changes and small updates to get a well rounded
prototype. The font of the text was changed to Arial but the color scheme was preserved. The
previously mentioned fat menu was implemented and the drop-down menu was deleted. For the
frontpage, new pictures were used in the carousel, because previous ones had copyrights attached
to them. Minor bugs like connections not working properly were fixed and some final touches like
extra hover or pop-up tools were implemented. By this time, all of the user stories chosen to be
created had been implemented and the requirements fulfilled.

7.5 Presenting the Prototype for Stakeholders

The final prototype was presented to the stakeholders whilst walking through and comparing all user
tests and results. The Figma prototype was shared with the stakeholders so that they could walk
through it themselves later. The font, color scheme, and the use of a fat menu instead of a drop-down
menu were discussed, and the response was positive. As they soon will be remaking the current
Studentportal, the stakeholders were both excited and interested in the results. Furthermore, the
accordion, which categorizes menu subcategories into colorized blocks, was well-received. Some
questions arose from the stakeholders’ side, for instance why users felt overwhelmed by the use of
pictures on the current Studentportal and not in the prototype. It was discussed that this might
be because of the utilization of grid of equals in the prototype. Lastly, the stakeholders expressed
high gratitude for the cooperation during the project and that the results from the user tests could
possibly be used later on to help develop the newer version of the Studentportal. In addition, there
is a likelihood of them reaching out to the authors of the thesis to participate in their user tests.

37


8 Result

With information gathered from the questionnaire, multiple interviews, and user tests serving as the
project’s backbone, combined with established design principles and patterns, the project resulted
in the final version of the prototype, see Figures 13 - 17. In summary, the final prototype could be
viewed as a suggestion for a new design for Chalmers’ Studentportal with the goal of providing a
positive user experience.

a) b)

Figure 13: Two pictures from the prototype developed with Figma. Figure a) shows the homepage
of the prototype. Figure b) shows one of the subpages.

38


a) b)

Figure 14: Two pictures from the prototype developed with Figma. Figure a) presents the syllabus
for the first three years at the Software Engineering program. Figure b) shows the page where one
searches for specific courses available.

a) b)

Figure 15: Figure a) shows the profile page for an student that is logged into the Studentportal.
Here one can view his or her personal data and change what program he or she studies. This will
enable the website to adapt to the input and only show relevant information for respective program.
Here students can also view your personal deadlines. Figure b) presents the contact page for the
Software engineering program.

39


a) b)

Figure 16: Figure a) Newly designed news page with the functionality of categorizing the news for
personal liking. Figure b) shows the calendar page with deadlines concerning courses, bachelor and
master studies.

a) b)

Figure 17: Both figures presents the use of a fat menu to navigate through the prototypes subpages.
Figure a) shows the navigation options when pressing the menu ”Studier” (Studies) on the home
page whilst Figure b) shows the options when pressing ”Utlandsstudier” (Study Abroad).

8.1 Users’ Experience

Overall the users’ experiences towards the prototype in regards to the specific design principles
and system descriptive adjectives were overwhelmingly positive. In addition, only one out of 12
emotions evoked from the emotional chart in the last user test was negative, meaning that the
finished prototype could be seen to live up to the expectations to fulfill a positive user experience.

8.1.1 Final Prototype

Participants rated the prototype in regards to the five previously mentioned design principles by
giving each principle a score of 1 to 5. The final result for each category was calculated by the
mean. On top of this the participants filled out a system descriptive adjective chart. The adjectives

40


written below were mentioned at least once by a participant.

Design Principles

• Visibility - 4.5 out of 5

• Feedback - 4.5 out of 5

• Constraints - 3.8 out of 5

• Consistency - 4.8 out of 5

• Affordance - 4.6 out of 5

System Descriptive Adjectives

• Useful

• Effective

• Structured

• Interesting

• Clear

• Understandable

• Quick

• Easy-to-use

8.1.2 Evoked Emotions

The results showed a large range of positive emotions associated with the product, specifically 12
positive ones versus one negative. Listed below are the specific emotions participants said to have
perceived during the final user test. Each emotion has been experienced by at least one individual
or more.

Positive Emotions

• Cheerful

• Eager

• Energetic

• Fascinated

• Happy

• Hopeful

• Interested

41


• Optimistic

• Proud

• Relaxed

• Relieved

• Satisfied

Negative Emotions

• Overwhelmed

8.2 Guidelines for Maintenance of the Website

To create a respectable and functional website is one challenge, but to maintain it to be of qual-
ity over time is another. After this project we can provide a few guidelines for maintaining the
Chalmers Studentportal and to make sure it holds up to standard even after updating its content.

After the first meeting with the stakeholders it was clear that the website had multiple administra-
tors that updates the Studentportal’s content without any instructions of how to do it. This seemed
to be a concern since the structure of the content varied across the pages and some information was
duplicated, resulting in the creation of unnecessary subpages. Since Chalmers Studentportal is a
large website with a lot of content and information, multiple administrators are required. However,
by establishing guidelines for updates, it is possible to avoid duplication and ensure that the content
layout is consistent across all pages.

Firstly, our recommendation is to have guidelines for how each subpage should look in terms of
font, font size, buttons, links and presentation of visuals. To prevent duplication of information,
it is recommended that there should be some sort of documentation on what content exists and
on what page it is located. Additionally, having an administrator who is responsible for the entire
website’s content can be beneficial in ensuring that each page has unique information and follows
the guidelines.

As Chalmers students, the group is aware that the Chalmers Studentportal has a bad reputa-
tion; even the stakeholders agree that the website is outdated and does not meet good standards.
It is absolutely necessary to update a website from time to time if you want to keep it interesting.
Our obvious advice is to make changes, but those changes must be thoroughly tested on users to
make sure that the changes are appropriate or not.

42


9 Discussion

This section will go over various aspects of the project’s entire process and results. First and fore-
most, the motivation for redesigning the Chalmers Studentportal, followed by the users’ experiences
with the new design, some concrete design decisions to ensure a positive user experience, improve-
ments and obstacles, and finally the social-ethical measures that had to be taken into consideration.

9.1 Motivation

The changes brought about by the Covid-19 pandemic have caused a lot of stress and frustration in
many people’s lives, including the authors of this Bachelor’s thesis. This sparked the idea of creat-
ing a positive user experience with the goal of improving the user’s mental state and reducing stress.

However, as seen with previously mentioned Jonasson, Fjeld and Yamashita, 2007 [3], the au-
thors came to the conclusion that an improved redesign might not be as beneficial as one might
have thought because some lesser user interfaces have so called “committed users”. Even if this is
true, any means of improving a product should always be welcomed, especially when it is a product
that all Chalmers students must use. The Studentportal was chosen because the group unanimously
felt that they had a negative view of its design, and every group member had been frustrated when
using it on multiple occasions. Choosing to redesign the Studentportal also meant that the target
demographic became students at Chalmers University of Technology, making it easier to contact
and set up user tests with people in that demographic.

9.2 Users Experience

The overwhelming majority of emotions experienced from the final user test were positive, with
12 versus one. A reasonable conclusion would be that the goal of providing a positive user expe-
rience has been satisfied. However, there is a slight possibility that the prototype will not meet
these standards; it all depends on what one is comparing it to. Since the majority of the project’s
participants expressed negative feelings toward the existing website, positive emotions may have
been exaggerated and developed in spite of the existing Studentportal. However, the results speak
for themselves; they simply need to be correctly interpreted. The feeling of being overwhelmed
was the only negative emotion experienced, and this by only one of the participants. A reasonable
explanation for this is that any user requires time to become acquainted with the product, and thus
this outlier may be viewed as carrying no weight.

Even if specific design principles are not directly related to emotions, there is a correlation be-
tween the two. In the final user test, when participants were asked to rate the prototype in terms
of the five design principles, the total score was 22,2 out of 25. The score is high enough that
one could conclude that it provides a positive user experience. Design principles and patterns are
standardized to some extent for a reason; otherwise, they would not appear in most literature and
online, implying that testing whether participants enjoy them may not be as necessary as one might
think. It is a fine line in user experience whether world-wide known design principles should be
determined by individuals with lesser knowledge or not. This is because user experience revolves
around what the user thinks and expresses which is why it is an interesting topic to be discussed
further in future projects.

43


According to the chart of system descriptive adjectives, all adjectives chosen by participants were
positive. Words like ”effective”, ”structured” and ”understandable” indicate that the prototype
was well-received by the participants, indicating that the project’s goal was satisfied.

When the results of the first interviews, as described in Chapter 5.2, were compared to the re-
sults of the most recent user tests, there is a clear indication that the user experience has improved.
However, as previously stated, even though there has been an improvement on paper, this could
simply be due to a bias toward the already existing website. Some participants may prefer anything
presented to them if it does not look anything like the current version. Nonetheless, progress is
always welcome and the results may be viewed as a direction for future developments of the website.

9.3 Design Decisions to Ensure the Positive User Experience

The majority of design decisions were made to support the goal of a positive user experience, with
the exception of those made to account for external constraints such as time or the Figma memory
limit. When discussing how to accomplish this, it became clear that there were three categories,
aesthetics, usability and ease of use, that could be improved in order to increase user satisfaction.
Aesthetics refers to how likeable or pleasing the overall design appears to the user when the contents
are ignored. Usability refers to how useful something is to the user in terms of whether it helps
them in any meaningful way. Ease of use refers to how effectively and effortlessly a user can interact
with and accomplish tasks within the prototype.

9.3.1 Aesthetics

Aesthetics is difficult to implement because it is subjective, which means that there is no definitive
way of making an aesthetically pleasing layout, it will always be more satisfying to some users and
less to others. Since the goal of the project was to create a design that elicits a positive response
from the users it was decided that eliminating a negative response was more important than creating
a positive or neutral. This led to the decision of implementing the design choices that gave the
most neutral response and opting away from designs that gave both positive and neutral reactions.
An example of this is the decision of a color scheme where the two palettes, see Figure 11, had both
very positive responses from some users and very negative responses from others. In this case it
was decided that the bright blue color scheme that had less positive responses and more neutral,
but no negative should be implemented.

9.3.2 Usability

Usability can also be challenging to implement, the reason being that the users of the Studentportal
are varied in their needs and tendencies. For instance, a student in the first year of a Bachelor’s
program will likely not have a great interest in applying to a master program and the deadlines
for said application. On the other hand, for a student in the third year of the same program, this
information might be critical as well as very useful. This led to the design being implemented
in a way that takes account for the needs of different students by assigning each student a login
and a profile with a selected year and program so that the presented content will be tailored to
fit the needs of each individual. This in turn helped with the implementation and improvement
of the calendar function which was a table displaying upcoming events and deadlines for students.
When discussing the current version of the Studentportal, interviewees reported feeling as if the

44


information presented there was irrelevant or uninteresting. In the new design it was decided that
less information should be displayed to make it easier to absorb what is presented and also that it
should only contain information that is deemed important, such as deadlines for exam registration
or application for courses. Users in iteration two reported that this feature felt nicer and the
information now felt relevant.

9.3.3 Ease of Use

In the data gathering phase it was discovered that navigating and finding what the user is searching
for was the biggest point of frustration in the current iteration of the Studentportal due to the fact
that the website is required to contain all information that is needed or relevant for any student,
without any filters it can become a daunting task to find specific content. Interviewees reported
that this coupled with a disorganised structure on the website caused a feeling of being flooded
with information and an inability to find anything relevant due to the extensive volume of content
presented. The new design solves this through the use of the aforementioned profile and a revision
and re-categorisation of all relevant content on the Studentportal. With the information about
the most frequently used and visited parts of the current Studentportal and inquiries about the
importance of different content during interviews, the group implemented most of these subsections
with a new structure. In iteration two of the user tests the participants gave feedback about the
new structure and reported feeling as if it was easier to navigate and find information compared to
the old version.

9.4 Improvements

There is no doubt that there will always be areas in every type of project that could be improved.
There were two major areas of improvement that emerged in this project: first, the process of data
collection and participant distribution, and second, what information should and should not be
tested on said participants. Looking at the distribution of all data gathering, it is heavily dominated
by software engineering stu