User Experience Design at Immowelt

(1)

Friedrich-Alexander-Universität Erlangen-Nürnberg

Technische Fakultät, Department Informatik

Rebecca Reuter

BACHELOR THESIS

User Experience Design at Immowelt

Submitted on 30.6.2014

Supervisor: Prof. Dr. Dirk Riehle, M.B.A., Drs. Ann Barcomb Professur für Open-Source-Software

Department Informatik, Technische Fakultät

(2)

Versicherung

Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet.

_______________________________________ Röttenbach, 30.6.2014

License

This work is licensed under the Creative Commons Attribute 3.0 Unported license (CC-BY 3.0 Unported), see http://creativecommons.org/licenses/by/3.0/deed.en_US

_______________________________________ Röttenbach, 30.6.2014

(3)

Abstract

Human needs become increasingly more important and technology will be more and more pushed into the background in the future. Thus, User Experience (UX) and in this regard User Experience Design (UXD) become very common in today’s businesses. This also holds for the Immowelt platform. This thesis presents a Harvard Business case study, which casts light on the design of the “Note Taking” feature with respect to User Experience Design. Especially in the spotlight of this study is the balancing act between given stakeholder requirements and good user experience that influenced the design decisions for the “Note Taking” feature. Moreover, the thereby necessary iterations for gathering the user experience in various forms are displayed. The thesis further introduces concepts approached in the case study regarding the involvement of user experience design in the feature design iterations, which range from UXD methods in the development phases to testing forms before and after the launch. At last, a guideline for teaching the case in a student class is provided.

(7)

Introduction

“To involve user experience into software development- that is different than writing code.” (Nestler, 2014)

Human needs become increasingly more important and technology will be more and more pushed into the background in the future. Thus, User Experience (UX) as term is very common today. Functionality keeps important but developers have to consider new processes. Questions like, who is using the software, why and how or what is the difference between users open a new view onto software products. Considering this perspective is the job of a user experience engineer. The person behind the computer does not profit from all the technique and features. “For the end-user, the interface is the system” (Hedge, 2009). The developed feature or product is only successful and effective if it is useful for its user. Effectively the difficulty is to make the consequences tangible, objective and measurable for software developers (Nestler, 2014).

This thesis explains the concept of user experience design and show up the difficulties with the users’ needs. Therefore, initially the hand of a real world example faces the challenges between stakeholder restrictions and developing a feature, which has good user experience. The thesis is divided into three main parts: A Harvard case, case concepts and teaching guideline, whereas the leading question through these parts is “How to design a feature?” It focuses on user experience design. The case should show up how a feature is designed in a real world company. This implies that certain challenges within the development process of a feature design involving user experience design. The second part describes case methods that are signified in the case. Besides questions and their answers, the teaching guideline provides an approach to a lecture concept for the case.

(8)

(9)

1 Teaching Case

In the following part I the Harvard Business Case is provided.

1.1 The “Note Taking” Feature at Immowelt AG

Markus Teschner is head of Immowelt product management team. Inga the senior product manager for Internet development and Stefan the senior product manager support him for User Experience (UX) and Usability. Let’s say, they are the core team.

The core team met together regularly to discuss new ideas to improve their web platform. At one of these meetings, they discussed a newly proposed feature, which should support users to note important information about a property of interest in an easy readable manner. This proposal resulted from an idea of stakeholders (let’s say a potential user story), where users take a notification for a property of interest.

Doing data analysis and user surveys about users to note information on a property has shown that many of these users (without access to the new feature) took notes on extra sheets of paper by hand or additional devices like computer or smart phones but independent from Immowelt platform and of course independent from the property of interest.

This led the core team to questions like: How can we present these property related notes on our platform? What is the information we can use from such “notes”? How could such “notes” be persisted to use the data? How could the new feature build up customer retention? How become these “notes” profitable for Immowelt? Alternatively, where are the benefits for the Immowelt platform?

To understand what this means, designing the feature at a platform like immowelt.de, it is useful to understand: What are the steps to get ready to design the feature (the factors of influence)? What are the steps to design the feature? What are the steps to handle the lifecycle (bug fixing and updates) of the proposed feature? In addition, what is the target (business) of the company?

(10)

1.2 The Company

The content of the following section is mainly taken from the Immowelt website. The Immowelt AG, which was former the Data Concept GmbH, was founded by Carsten Schlabritz and Jürgen Roth in 1991. They wanted to offer simple usable software for real estate agents, which saves time and expenditure day for day.

Already one year after foundation 1992 the company was represented at CeBIT.

Until 1993 the succeeding software Makler 2000 Office was placed in Germany, Austria and Switzerland. After five years, Makler 2000 has been one of the five best software solutions for property software. Twelve employees develop the software constantly further. Data Concept presented itself at MIPIM in Cannes for the first time and offered with Makler 2000 Pro a special solution for the needs of commercial real estate agents. The start of the property portal www.Immowelt.de in 1996 was the reason for constantly further growth. As being one of the first online-marketplaces for flats and houses, Immowelt.de opened a new era in the property market. A new chapter started in 2000. The publishing group Georg von Holtzbrinck participated as strategic partner. As a result, there was a re-branding from Data Concept GmbH to Immowelt AG.

In 2002 WAZ and Münchener Zeitungs Verlag participated in the Immowelt AG and enabled the start of the succeeding Immowelt Media Network. The first Online Print Products arise in collaboration with Münchner Merkur and WAZ. 2005 the portal ferienwohnung.com was started, formerly known as fewoanzeigen.de. Further established portals like wohngemeinschaft.de and bauen.de also belong to the Immowelt family. Two years later an additional innovative software solution was established: the web based software Immowelt i-Tool. It offers first class administration of properties to real estate agents on the Internet. Besides the TÜV Süd honored www.immowelt.de with the certificate s@fer-website. Since 2008 users of www.immowelt.de can search a new home from a mobile website. With the first, immowelt.de App for apartment search for Android smart phones the Immowelt AG consolidated the mobile offer in 2010. By now Apps for all common smart phones and tablets as well as Windows 8 complement the offer. Since 2009 www.immowelt.at represents Immowelt AG at the Austrian market. Already one year after the launch, the property portal belongs to the leading providers in Austria. A relaunch of the portal www.immowelt.ch in Switzerland, also online since 2009, ensured a more modern design in 2012. 2011 the Immowelt AG obtained for the second time the award Bayerns Best 50. This is an award from the Bavarian state government for increasing companies, which generate jobs. One year later,

(11)

the company was awarded with Top Job for the second time. This is an award for excellent personal management in medium-sized companies. Today the Immowelt AG engaged more than 270 employees. In November 2012 the enterprise moved into additional bureaus and occupies with this more than 4500 square meters office area on the company headquarters in Nuremberg.

1.3 Design of the “Note Taking” Feature for

www.immowelt.de

Platform

As already written in the introducing chapter about the “Note Taking” feature, the team started with a proposal. The proposal has risen up from business and/or users’ needs, which were established by stakeholders of the platform.

1.4 Developing a Vision for the Proposed Feature

Markus and his team created a user story after they have carried out interviews with potential users of the platform, have checked best practices and have done a fellow applicant analysis. They examined the responses to their survey and weighed them. To do so, they wrote a detailed description. The information resulted in a list of properties of the feature and how the feature should work.

“A challenge for the team was to outline a feature that fits seamlessly into the other functions of immowelt.de. It should not interfere with the search process of a user. To sum up, the feature should be findable but not showy”, explained Stefan, “but, we expected the feature to be quite useful for our customers”.

The behavior of the new feature was written down in a storyboard and the design team developed design prototypes of the feature.

1.5 Recording Detailed Requirements

The team considered how the characteristics of the feature should work, what the constraints (business and technical) were and how its development could be done profitable.

Markus and his team defined the following basics for the feature in the first slides of the storyboard: Users who are logged in at immowelt.de should be supported in their property searches. It should be possible to set up notes for every property listing and/or to complete the address and/or to enter viewing dates and/or any other free text annotation.

(12)

Furthermore, some actions a user makes should be recorded relating to the property listing (automatically i.e. contact request or manually i.e. phone calls). One of the main goals of the feature was customer connectivity, which should be resolved by the requirement that only signed in users could take a note. Notes for a property listing of a logged in user should be visible on the wish list, on the results’ list and on the respective exposé. Editing notes should be possible on the exposé and on the wish list1_{. If a property listing is deleted from the wish}

list, associated states and notes will also be deleted.

Additionally, the team has to respect some extra requirements to embed the feature into the platform in a consistent way.

Beside the basic data, the team defined some common requirements: A first requirement they constituted was that users would have to sign in to take notes. All collected data has to be written to a database. The usage of the feature has to be tracked by Adobe Analytics, which is the common tool for usage tracking at immowelt.de platform.

Markus summarized all requirements in slides in the storyboard. The storyboard is painted out in PowerPoint®.

A few of the detected functional requirements are exemplary presented below: Notes contain:

•An input field for notes

• The state history (which states the user has realized with this property listing)

• Input fields for the property address (suppliers often conceal the street, thus a searcher can add the address)

All comprehensible steps a user executes with a property listing are recorded in the note field with the date. For example, “[Date Time] contact request sent”. Furthermore, the carried out step is presented with an icon. Comments and reference of a contact request are also transferred into the note field. If a user takes notes at the property listing, sends a contact request or contacts the supplier of this property listing by telephone, the property listing in question will be added to the wish list automatically (for a detailed description see:

“Experience with the “Note Taking” Feature”). In a later version, tips should be presented

1The wish list is one view the portal offers: If a user takes notes to a property listing, this is put on the wish list automatically. Furthermore, the user can put a property listing from the results’ list to the wish list by a click on the button “Merken” (engl.: bookmark).

(13)

on the site relating the actual state of the property of interest, such as calling a company for the move.

The owner of all of this information was Markus (as head of product management.). The resulting artifact was called storyboard. A Storyboard is a visual way to demonstrate the interactions of a user with the product and contains some extra information as seen above. One slide of the storyboard is shown in Figure 1. Storyboards at immowelt.de platform are also a technique to present developers the GUI behavior of the feature.

Depending on this information, the team had to decide how to design the feature.

Figure 1: This storyboard extract shows the steps a user has to follow to take a new note if he/she is signed in or not.

1.6 Design Decisions for the “Note Taking” Feature

Markus and his team made decisions about the “Note Taking” feature depending not only upon usability but also upon balancing various factors.

The stakeholders and the team considered how useful the system would be, whether they felt that it was suitable and they would like to use it. How much it would cost, both financially and in terms of personal, social and organizational consequences.

(14)

To support decision-making, the team used several strategies and tools: First, the storyboard was created and updated in several more or less lasting meetings, as well as click dummies. Depending on technical and stakeholder requirements, the team visualized users and stakeholders’ needs using these tools in several meetings.

Markus and his team used several screen mockups to display their ideas of the placement of the feature (see: Figure 3 - Figure 14).

Extra non-technical requirements for the “Note Taking” feature were: The feature had to be findable but not showy. Users have not to be kept off from the search process and from reading the offers. In the view of the wish list, notes could not be edited.

1.6.1 Visualize the Users’ and Stakeholders’ Needs

To begin with, to visualize the users’ needs, the storyboard mentioned above, is used. Markus painted out several GUI behaviors and bullet points in slides of it. The storyboard, therefore, is one of the main sources for developers to realize a possible solution.

Design prototypes, such as click dummies or graphical mock ups, were a second technique, which were used by the team to present the visual behavior of the feature. For developing click dummies they used Axure (Axure is a tool to create interactive wireframes and/or mock ups). A HTML- click dummy was also used to iterate through requirements with the stakeholders and to support the development team in creating a first design prototype. Examples of mock ups can be seen in Figure 3- Figure 7.

By developing click dummies and mock ups, preferences of the companies style guide had to be in mind, as well as positioning and presence of the feature on the web site and the integration of the feature in the existing canon of functions.

Every big design decision had to be verified and be discussed with stakeholders, for example chairpersons, support team and of course the users.

1.6.2 Verification of the Design Decisions

Based on the user analysis, fictitious user groups which stand in for the actual users were used to verify decisions, called Personas. For developing this feature, Immowelt used five Personas called Ben, Wolfgang, Daniel, Bianka and Sonja. Every one represents a group of people searching a property listing. Persona Ben is exemplary shown in Figure 2 (see the rest of them in the appendix).

These Personas had common information about personal dates, a motto, a background history for details and a selection of wishes and goals. Especially goals helped Markus and his team

(15)

to get a better assessment of the Persona (Note: Personas were present for all team members in design meetings to discuss pro’s and con’s for design decisions).

Figure 2: Persona Ben (www.usability.de, 2010)

An external company developed the Personas. This company takes care of usability testing for the feature and the immowelt.de platform.

As soon as Markus and his team got green light from stakeholders, they could say, “we have an acceptable design”. Following this, the development team had to implement the feature on the platform based on the suggested design.

(16)

1.6.3 Release of the “Note Taking” Feature

After the development team, which is part of the team, implemented the feature as designed, executed some tests and usability tests with the Personas, the team did expert interviews to discuss the feature. During these interviews, the design team and experts discussed the used terms for buttons and labels of the feature, for instance. This step was necessary to fulfill the requirement that the feature should be embedded in a way that the whole platform was kept consistent.

A new version of the Immowelt platform with the now integrated feature was then deployed; the feature was presented online.

In a next step, the team did some analysis about the behavior of the users using the feature. If the team recognized conspicuities regarding the usage rate of the “Note Taking” feature, they have reacted with e.g. new versions for the feature, with other behavior or design.

Tests were important for the team concerning the technical functionality, but also for recognizing the user experience with the feature.

1.6.4 (Usability) Tests

After having deployed the feature on the platform, the team processed user analytics. Subsequently the results are discussed. Based on these results of the team develops variants, if the results weren’t as expected. Ensuing, they are analyzed with the tool Maxymiser® for automated, multivariate testing. Every user gets randomly one variant of the website. For representativeness aspects, this is done at the same time and every variant is chosen at the same rate. Using this test they could observe the user behavior in a quantitative way. The tests were processed on the live system, where the feature was deployed.

If there have been any observations, a new version was developed and deployed in a further iteration. An external company has been engaged to process usability tests to verify complex observations the team has detected by tests with Maxymiser®. In contrast to multivariate testing, usability test produce qualitative results.

The following screenshots (see: Figure 3-Figure 7) show different versions of the placement of the feature in the exposé view, before the deployment on the website:

(17)

Figure 3: „Note Taking“ feature in exposé view- version 1. This was a draft in the first phase of the design process and was discarded.

In Figure 3 the user could take notes with two buttons that were located at the description of the property and at the detailed information of the property.

(18)

Figure 4: „Note Taking“ feature in exposé view- version 2. This was again a rough draft. The team created some scenarios and tested the version with every Persona. This version was also discarded.

Figure 4 shows a next version of the exposé view. To take notes the user could either press the button “Notizen hinzufügen” (engl.: add notes) before the description of the property. This could be possible if the user has taken notes before. If not there was additionally the possibility to choose the tab “Notizen” (engl.: notes) to take notes.

(19)

Figure 5: „Note Taking“ feature in exposé view- version 3. This was again a rough version, which was discarded.

The next version (Figure 5) shows again a tab to take notes and if the user has taken notes before, the notes appeared below the picture of the property and above the description of the property. In this version, the notes were displayed directly on the page in a yellow box and not with a symbol as in Figure 3.

(20)

Figure 6 shows the exposé view with the feature again with the tab on the right site of the website. The difference to the further versions is that the text or symbol below the picture of the property is now omitted.

(21)

For the next version, which can be seen in Figure 7, the tab was omitted but there was the symbol “Meine Notizen” (engl.: My Notes) below the picture of the property. The already taken notes were also not displayed in this view.

(22)

Figure 8: „Note Taking“ feature in actual exposé view

In the final version, shown in Figure 8, the feature is placed again below the picture of the property. A user has to click onto the link “Machen Sie sich hier eine Notiz zu dieser Anzeige” (engl.: Here you can take a note to this property listing). In this version, the symbol has been changed to a line with the above text in it. Furthermore, there is no additional tab available. This version was the first live version of the feature at immowelt.de platform. As seen here, as well as in the following figures, view and behavior of the feature were changed often. New iterations were necessary if there have been any design issues, before the tests with Maxymiser®, after the deployment of the feature, if there were observations in user analysis and after the usability test concerning the user experience.

(23)

The next Figure 9 and Figure 10 show the different versions of the results’ list. In the first shown version in Figure 9, it was also possible to take notes in the results’ list. This is not possible in the next version (see: Figure 10) and not in the current one (see: Figure 11).

Figure 9: The „Note Taking“ feature in results' view, a rough version of the result’s view.

(24)

(25)

Figure 11: The "Note Taking" feature in actual results' view in May 2014.

Figure 12 and Figure 13 show the different versions between August 2013 and May 2014. The view of the wish list has not changed regarding the „Note Taking“ feature since August.

(26)

(27)

Figure 13: The „Note Taking“ feature in actual view of the wish list.

Imagine this is everything you know for now without any further thought and imagine for the next section that a user called Bob tries to use the “Note Taking” feature.

(28)

1.7 User Experience with the “Note Taking” Feature

Assuming Bob is a new user of the immowelt.de users and he is looking for a new property. Bob only has to put in a city and the type of property. He has to press the “Suchen” button (engl. search button). As a result, Bob is linked to a list of properties, which fulfills his search criteria. He will be able to select one of these property listings. By doing this, the platform will show him the details of the selected property listing.

In the exposé-view, seen in Figure 8, Bob is allowed to add notes. A little field below the picture of the property is presented. The other option to see this field is that Bob has created an account prior and has signed in yet but has not taken any notes to this property listing. Let’s say Bob has an account.

There is now the possibility that he has not signed in, but he has taken some notes before. A hint to sign in arises. If he then clicks at the field, the “Meine Notizen” (engl.: My notes) panel in editing mode is shown (see: Figure 14).

In this mode, he is able to take new notes or edit existing notes prior added. The view is still the exposé view, as you can see in Figure 8.

(29)

Figure 14: The feature in May 2014 after pressing the button "Machen Sie sich eine Notiz zu dieser Anzeige" (engl.: Take a note for this property listing); a user is logged in.

(30)

Figure 15: Editing mode: A user can take notes in the text field or click the button “Schnellnotiz” (engl.: fast note). A user can enter the address if he already knows it.

As shown in Figure 15, Bob is allowed to edit the content of the field. At the button “Schnellnotiz” (engl.: fast note)2_{(see: Figure 18, Figure 19) the process state of the}

acquisition is displayed. Additionally, there are some input fields for editing the address. This is a free text input, and there is no validation of the address.

The entered address is shown on the map (with a colored pin) in the latest version, if a supplier has specified it for the property listing. Usually this is not the case.

Figure 16: Reading mode: A user can read all notes ever entered.

The exposé view has also a reading mode where all taken notes are displayed (see: Figure 16). With the button on the right hand sight, Bob can edit the notes, if he clicks on the button “bearbeiten” (engl.: “edit”). He is then again linked to the editing mode.

The address will only be displayed, if it is available.

(31)

The button “Schnellnotiz” (engl.: fast note) is a dropdown menu. The content is different for objects for rent and for sell (see: Figure 18, Figure 19).

As seen before, Bob is able to click on the text field below the picture of the object, if he is signed in or not. If he is not signed in, he is linked to a sign in screen, which is shown in Figure 17.

Figure 17: Sign in Screen

If Bob then has signed in, he can choose between taking new notes and inspecting already taken notes. If he wants to bookmark an object, he can do this in the exposé view (see: Figure 8) and in results’ view (see: Figure 11). If he isn’t signed in and he presses the button “Merken” (engl.: bookmark), he will get a sign in screen (see: Figure 17). If he has already signed in, he can press the button and the object will appear on the wish list. Additionally, the button turns into “Gemerkt” (engl.: bookmarked). If a property listing is deleted from the personalized wish list, the notes and states are also deleted.

It is also possible to print notes. If Bob is signed in, he is able to print his notes related to the property listing in exposé- view.

He can also choose the view of the wish list. In this view, the notes that have been taken to a bookmarked object are displayed (see: Figure 13). Every object to which he takes a note will be bookmarked automatically. If a supplier deletes an object, Bob cannot edit or take new notes. The property listing will then be shown in gray.

The results’ view also displays notes, if Bob has taken some notes before (see: Figure 11). The equal objects are shown on the wish list and marked as “Gemerkt” (engl.: bookmarked). He cannot take new notes in this view. This view is only a reading mode. If he wants to edit the notes, he has to click on the link of the object.

This was the story about how Bob could use the feature.

The above describes the “Note Taking” feature as its functionality was.

(32)

With the weekly deployment, the website gets a different complexion very often.

Figure 18: "Schnellnotiz" (engl.: fast note) for property listings for rent.

Figure 19: "Schnellnotiz" (engl.: fast note) for property listings for sell.

Markus and his team found answers to the questions mentioned above and implemented the feature on the Immowelt platform.

1.8 Summary: User Experience Design for the “Note Taking”

Feature

Markus and his team developed the “Note Taking” feature in a highly agile environment, the Immowelt platform. Tools and strategies used in the process gave Markus the possibility for a

(33)

quick response, in a high quality, to the proposal of the “Note Taking” feature, but also some limitations.

Limitations were not only derived from the process or came out of the complexity of the feature, but also out of the business (e.g. stakeholders).

Regularly deployed versions of the “Note Taking” feature, after iterations with changes in lookout and feature behavior (inconsistences in platforms behavior for non-important features are accepted), led to the fact that the feature is not used as expected. However, in the development and the design of the feature, it was accepted in prior iterations. The design team, the stakeholder and the development team tried to animate users to use it more often. They accepted several iterations to improve the feature in behavior and design, so that users will accept the feature and use it in future version.

To sum up, if somebody designs a feature with UXD the first design hardly ever wins. What we have seen at Immowelt is an iterative approach to design the „Note Taking“ feature with respect to user experience design.

(34)

(35)

Figure 20: Persona Wolfgang (usability.de, 2010)

(36)

(37)

Figure 22: Persona Daniel (usability.de, 2010)

(38)

(39)

Part II

(40)

2 Literature

We now have seen how the “Note-Taking” feature has been designed at the Immowelt platform.

2.1 Overview of “Literature”

The following part will focus and cast light on the theoretical basis, which concepts are used or at least partially used for designing the feature at immowelt.de. Furthermore, the concepts are discussed and possible extensions of the methodology are explained within the scope of designing the “Note-Taking” feature by using user experience design (UXD).

Therefore, this part is structured as follows: User experience design being the leading part of the case is elaborated first. Thereby I will point out the characteristics of UXD in the feature design process for the “Note-Taking” feature, with special respects to roles for UX-design, personas, prototypes, user acceptance criteria and various testing techniques. At least I will do a prospect of integrating UX with an agile development framework as well as some testing aspects, which could support developing a small feature like the “Note-Taking” feature to be successful.

2.2 Designing a Feature with UXD

In this paper I will discuss the task “how to design a feature” by using the core concepts of user experience design for developing a software system.

The key words are “user” and “experience”. In the context of the case above it could be discovered in terms like customer experience, interaction experience, user interface, general experience, usability, user interface … with respect to customers as well as business users of the software system (Roto et al., 2010).

Designing a feature has to satisfy one or more or all of these experiences. 2.2.1 User Experience Design

There is not one scientific definition of user experience design (Roto et al., nd). The term user experience (design) in my thesis will focus on user experience design for a (small) feature, which is part of a greater software system where the development team considered user experience in their design iterations.

(41)

“User experience design is the creation and synchronization of elements that affect users’ experience with a particular company, with the intent of influencing their perceptions and behavior” (Unger, 2012).

Jakob Nielson and Don Norman (2014) sum up user experience following: “’User experience’ encompasses all aspects of the end-user's interaction with the company, its services, and its products” (Nielson, 2014).

The two definitions have in common that the users interaction with a product is influenced by the design.

Figure 24: User Experience Design

Figure 24 describes my understanding of user experience design. This understanding aligns with the given definitions. The users’ needs are to the fore. The second component not less important than the user’s needs is the particular company with its particular perceptions. The intersection between users’ needs and business needs describes the user experience design. This intersection can also cover all business needs and all user needs in best case.

The result of a design process that includes user experience and of course further development steps is a product or feature that conforms to users’ and business needs.

The user experience design process is explained in a later section. For now, it is important to have in mind that the UXD process puts the user experience in the center of environment. It is arranged variable and depends on the company. Therefore, it is important to collect the expectations of the users and to create a fitting and innovative product. The way in which this objective is achieved, is most widely irrelevant for the solution. This is why user experience

(42)

design can be integrated into any iterative or agile development process easily. The process has to be complemented to certain activities, like surveys, tests and roles (Moser, 2012). 2.2.2 Significance of UXD

A good user experience is reflected in good product reviews.

Poor reviews will result in a greater workload for helpdesk or troubleshooting in general. Users will be frustrated and the platform might be used less frequently or not be used any more.

A good user experience is important for a successful platform and for establishing a continuous customer relationship.

Believing Burchell (2013) Maura O’Neill is of the opinion that it is important to create a user experience that achieves a user returning to the product or feature. In her opinion, the experience must be enjoyable and rewarding (Burchell, 2013).

Harvey (2013) in general is also of in the opinion of Maura O’Neill: Good user experience influences the user to come back instead looking somewhere else for the same product. Good user experience is very important for customer connectivity. Often there is only one chance for that because users decide in between seconds whether they stay or not (Harvey, 2013).

Figure 25: Honeycomb model of user experience from Peter Morville, Semantic Studios LLC

However, Peter Morville introduces a honeycomb (Figure 25) to represent the influencing factors of user experience. Primarily the users have to find the feature valuable for their usage.

(43)

In addition, the product, respectively the information the product provides, has to be useful, usable, findable, credible, accessible and desirable (Morville, 2004).

2.2.3 Roles and Responsibilities for UX – Design

In this section, I answer the question, who actually does the “user experience design”. The most popular role is the so-called “UX Designer”. A “UX Designer” could also be an information architect or/and interaction designer additionally to the role as user researcher.

Figure 26: Overview to roles of a UX Designer

Some overlapping roles could be Brand strategist or steward, business analyst, content strategist, copywriter, visual designer, front-end developer (see: Figure 26). Which roles are taken depend on the particular project. Relating to UX it is the task of an information architect to design the navigation using a product user-friendly. Additionally the role ensures that categories and subcategories of information are distinct and user- friendly (Unger, 2012). Consequently, the overview picture can be extended by the role of a UX-designer. The position is outside because it is the job of a UX- designer to do the UX- design.

(44)

Especially important for designing a feature is the interaction between the Product Manager and the UX Designer. Therefore, the tasks for the two roles are listed below (Treder, 2013):

Product Manager UX Designer

Makes sure the product goes in the right direction

Designs UI Coordinate the work of the different

departments

Applies arts & science of UX Design to the Product

Maintains proper communication in the team Studies Users

Deals with budgets and stakeholders Experiments and Optimizes Products

Table 1: Tasks of the Product Manager and the UX Designer

2.3 User Experience Design Process of a Feature

This section describes a user experience design process within the development of a feature. During each development phase of a product various UX practices are proceeded.

Figure 27: User Experience Design Process, whereas the text fields in brown are important for the leading question (Moser, 2012)

First, an idea for a product is needed. The idea can emerge within meetings with stakeholders or workshops or be suggested from outside. Ideas have to be elaborated, filtered and weighed since not every idea is profitable for the company. Thereto the expectations of the users, the goals and parameters of the stakeholder, opinions about competitive products and services and current processes and shortcoming of those processes (own strengths and weaknesses) are examined within this concept phase. The artifact of this first analysis is the product vision (Moser, 2012), (Arbor, 2014a).

(45)

For the development of a product, additional information about potential users of the product is needed. This information includes goals, proceeding, and way of thinking, style and environment of the users and is collected within user research by UX researchers. These facts about the environment of the users are collected by tracking, survey or data analysis to establish functional and usability objectives. To handle this plenty amount of information, simplified models like Personas or scenarios are created which represent users and their environment (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

From product vision, circumstances of the stakeholder and insights of the user research, requirements are derived. They are collected in the requirements document. The requirements phase also includes workflows comprising key tasks, daily tasks, rarely performed but necessary tasks, task contexts, constraints, safety issues, required knowledge and skills, and attitudes towards tasks, “Nice-to-have” features and functions (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

After that, the initial design phase begins. Within this phase, ideas that cover the requirements (users and business needs) for the design are sketched and tested (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

Following this phase is the design refinement phase is proceeded. In this phase, the design should be finalized and tested (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

By the arise of new insights during the elaboration of an idea the development is addressed step by step in short iterations where few of the requirements are implemented and runnable pre versions are created. Users can test these versions. Insights slip into the next step of development (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

At the beginning of each iteration it is planned which requirements have to be implemented (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

Moreover, the different disciplines of the design develop solutions: The interaction design arranges an interaction and places control buttons on the screens. The information architecture cares for understandable structure and the visual design defines colors, fonts and graphics for the appearance. If the design has finished the development of the product starts. The development works one iteration after the design (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

Wrong assumptions, compromises or technical restrictions can lead to mistakes. These mistakes can happen from user research to implementation in every step. This may affect that the produced solution does not fit to the users’ needs. Hence, in the post release phase usability tests are proceeded which detect such mistakes and slip corrections into the next

(46)

iteration. Furthermore, real- time use statistics can be produced and improvements for future releases can be identified (Moser, 2012), (Unger, 2012), (Arbor, 2014a).

2.3.1 Gathering Requirements for a Feature

During the requirements phase UX researchers gather requirements by investigating the stakeholders, other products and most important, the users. Besides analyzing tasks, also the method of user modeling is proceeded.

2.3.1.1 Business Analysis

As written in the case, a vision for the feature was created. Therefore, the team weighed their ideas in doing a stakeholder analysis and a competition analysis. Both methods are typical research methods to uncover user requirements and unmet needs (Moser, 2012), (Arbor, 2014b).

Another method to gather information on creating a vision is to research the target market or customers (Moser, 2012), (Arbor, 2014b). A market research provides best starting information about competitiveness and competitors where the new feature is embedded in as well as users’ needs for a feature.

2.3.1.1.1 Competition Analysis

A competition analysis is proceeded to develop a feature, which has unique characteristics. Therefore, the UX researchers investigate products from competing companies especially for strengths and weaknesses. The characteristics of the investigated products are listed and should match to the characteristics used by customers to differ between the products (typically 5-20) (Moser, 2012).

Before starting an own data analysis so called secondary data could also be helpful for researchers. Secondary data is already existing data, which is instantly available and mostly already analyzed, but the analysts have to watch out for the actuality of the data (Moser, 2012).

To complete the missing information from the use of secondary data, primary data is needed. Therefore, counterparts are identified and surveyed by interview and/or survey. In addition, exhibitions and congresses can be important to get these data (Moser, 2012).

After analyzing, adjusting and visualizing the data the artifact is a comparison, which helps to develop the strategy for the product (Moser, 2012).

(47)

2.3.1.1.2 Stakeholder Interviews

Stakeholder interviews are proceeded to clarify the role, the interests, the influence and the requirements of the stakeholders to the feature. Therefore, different forms of interviews (single and group interviews) are executed whereas the interview form differs between the importance of the stakeholder for the project (Moser, 2012), (Arbor, 2014b).

The project leader and the main sponsor have a single interview since the main sponsor who has approved the project has some conditions for the project regarding business goals.

After the single interview with the main sponsor, group interviews with the most involved stakeholder follow to discuss contradictory opinions. This form of interview is chosen as it has three side effects: The stakeholders get to know each other, they discuss their opinions and the project leader knows instantly the view of each them (Moser, 2012), (Arbor, 2014b). For the remaining stakeholders single interviews are proceeded since these stakeholders are mostly from various departments and hence have different expertise. These interviews should afford the opportunity to frame concrete wishes regarding technology, architecture, methodology or procedure. Beside this, interviews offer an occasion to get to know all project members and to clarify information about resources and competences (Moser, 2012), (Arbor, 2014b).

2.3.1.2 User Research

Besides analyzing stakeholders and competitor products it is especially important to investigate the users concerning their goals, needs etc., for example via tracking.

User research examines how users behave during performing a task and derives facts, which should help the design team to take design decisions throughout the product design and the development process. It should lead to a deeper understanding of the users’ needs and in later iterations whether these needs are met. Doing user research seeks to get a better understanding of the requirements and goals for the product (Moser, 2012), (Arbor, 2014b), (Bowles, 2010). From the collected facts, which can be abstract and plenty, simplified models are derived, e.g. Personas, scenarios or storyboards. Personas and storyboards are explained in a later section of this thesis (Moser, 2012), (Arbor, 2014b), (Bowles, 2010).

User research collects every information from in-depth individual interviews to large-sample surveys (observations, interviews and assumptions). This implies that no exact results are produced. The derived solutions should therefore be approved by usability tests (Moser, 2012), (Arbor, 2014b), (Bowles, 2010).

(48)

User research for innovative products is more difficult, since the product is not known on the market. User do not know the feature or product. For example, the method wizard of Oz might help in this situation. This method let users experience the future with this product. Thereby the behavior of the users can be observed (Moser, 2012).

2.3.1.2.1 Analysis of the target audience

It is important to develop a feature concerning a focused target audience and their needs. To find out the different existing user groups, their needs, values and goals an analysis of the target audience is proceeded.

This analysis segments the participants on the market by the hand of product relevant characteristics. There are quantitative and qualitative approaches. A quantitative approach could be basic characteristics like socio-demographic features or objective characteristics describing the living situation. Qualitative approaches could be studies about the mindset. The focus group are identified out of this segmentation (Moser, 2012), (Bowles, 2010), (Unger, 2012).

2.3.1.2.2 Tracking

User tracking, also called Web tracking describes the tracking of the user behavior using a product. This method analyzes cookies and log files. Conclusions about the login location of a user, the landingpage3_{, the visited websites and the exit page where he left the website, can be}

drawn. Furthermore, the number of Page Impressions can be tracked and how long the user visits single sites and which offers he used. Resulting are conclusions about the attractiveness of offers presented by the feature.

Companies use user tracking to place personalized offers and advertisements (Lipinski et al., 2014).

2.3.2 Generating Ideas and Visualize the Feature

2.3.2.1 Design principles

“Design principles are a set of pithy, memorable statements that embody the desired experience of your website. They provide a set of criteria against which all major design decisions can be measured, so you keep the individual parts moving in a similar direction.” (Bowles, 2010)

(49)

Design principles are stated to define a unique character for the product. They help designers making critical decisions about the product. Furthermore, with the help of design principles design decisions need not to be discussed with all stakeholders as the principles act as agreed reference point between stakeholders, e.g. managers and designers (Moser, 2012), (Bowles, 2010), (Unger, 2012).

Additionally, they help in generating ideas or proposed solutions can be assessed on how well they support the design principles. They even help to make appropriate decisions in defining the functional requirements, building the interaction, during the visual design or at the choice of the communication style (Moser, 2012), (Bowles, 2010), (Unger, 2012).

Ideally, they are elaborated between the analysis and the design phase, when the objectives of the product, the users’ needs have been clarified, since the principles influence the design of the product from the beginning. The elaboration can take place within a workshop, where the design team and important stakeholder participate (Moser, 2012), (Bowles, 2010), (Unger, 2012).

The design principles are basis for every decision und must be present permanent for example on posters in the office. Where personas are used to test appeal of a feature, design principles are used to approve how well these features support the user experience. (Moser, 2012), (Bowles, 2010), (Unger, 2012).

2.3.2.2 Storyboards

“Storyboards are user stories with visual accompaniment such as wireframes.”(Arbor, 2014c) User stories are the basis for a storyboard. It illustrates how a Persona uses the system in a specified situation. Therefore, the user story with the Persona is cut into scenes. The scene changes if the setting changes or the Persona navigates on another site in the product. For the illustration of the scenes scribbles, screen-shots or pictures are used to communicate the idea (Moser, 2012), (Quesenbery, 2010), (Bowles, 2010).

Consequently, storyboards are a visual way to demonstrate the interactions of a user and the product, whereas user stories are the theoretical basis. Storyboards include images in chronological order and captions or spoken words. They are used to illustrate workflows of the user without the product or present the thoughts of a user or reactions to the product. They are also used to think through a design problem or first user tests (Moser, 2012), (Quesenbery, 2010), (Bowles, 2010).

Storyboards have some advantages over user stories: They are easy understandable for everyone since they are visual and concrete. Furthermore, no prior knowledge is necessary.

(50)

They show unexpected things to the design team, further to which they can embed them into the design to have the product grounded in the real environment of the users’. Moreover, storyboards illustrate the user interface in reality. That is more effective than describing it verbally. At last, they help to think in workflows of the users and not too detailed in the designing of the user interface without any context. In contrast to prototypes they communicate, they show the interaction with the product in context and events (Moser, 2012), (Little, 2013), (Quesenbery, 2010), (Bowles, 2010).

Concluding the section storyboards show typical actions of the user groups in an illustrative, narrative way and explain the connection between use cases or user stories and Personas (Moser, 2012), (Quesenbery, 2010), (Bowles, 2010).

Overall storyboarding is a method for:

 “Visually presenting an idea

 Comprehensively showing activities, including timing and sequence

 Involving different audience groups

 Removing international and language barriers

 Facilitating audience recognition of an idea

 Enabling immediate audience feedback

 Helping to think clearly through an action

 Improving organization through establishing relationships

 Having fun—storyboards are simply fun to create and share

 Creating interest in the information by using an eye-catching communications medium” (Quesenbery, 2010)

2.3.2.3 Style guide

During the development of a product, many design decisions regarding visual elements (aesthetic, brand, business, interactivity and usability) are taken. Since every design decision bases on various preliminary clarifications and considerations, they are summarized to ensure a sustainable and consistent design. This summary outlines the last task in the visual design process, whereas the artifact is called style guide. The goal of this living document or online is to offer guidelines that contain design principles. It explains project members by hand of

(51)

figures, tables and examples the frame in which they can develop their solution. Consequently, it should as be as easy accessible as possible (Nichols, 2014), (Moser, 2012). Style guides are only effective if they are formulated briefly and concisely, provide justifications to decisions contain positive and negative examples, structured clearly and update. Further, the style guide serves as a reference manual for the design of the user interface. Suitable thereto are leaflets on the tables, posters on the walls of the bureaus or a wiki on the project website. The wiki has the advantage that color values, symbols or code examples can be copied directly but the paper forms are more present e.g. in meetings (Nichols, 2014), (Moser, 2012).

2.3.2.4 Prototyping

“A prototype is a simplified but functional model of a system, used to explore, communicate, and test a design. Users can move directly through a prototype, with pages following each other in chronological order.” (Bowles, 2010)

2.3.2.4.1 HTML click dummy as interaction prototype

A prototype is a deliverable of the design phase. A HTML prototype such as a click dummy can be seen equal to a paper prototype. It can be created by hand or by the help of a tool. The prototype is created to show or test the navigation through a site. If a design mock-up or wireframe is created before, pages of it can be set up as clickable images in the HTML prototype. With clickable screenshots in a browser, a user can click and gets a new view (Unger, 2012).

Tools like Axure, Visio or Adobe Fireworks support in creating the sort of interaction prototype that is needed for the project, from basic prototypes to advanced ones (Unger, 2012).

(52)

2.3.2.4.2 Graphical Mock- ups as visual design prototypes

Figure 28: Overview user experience design with focus on prototypes

Graphical Mock-ups are prototypes that have an elaborated visual design in every detail, but the elaborations of all other aspects like interactivity, function or data are waived (Moser, 2012).

The purpose of graphical mock-ups is to present the appearance of the finished product (see: Figure 28). They can be created with a graphic program like Adobe Photoshop or Illustrator (Moser, 2012).

While the design of a mock-up some further factors should be considered, for instance if the design shall not necessarily change in a different language or because of varying amount of data. Such factors might be irrelevant for the first draft but can cause bigger problems in more elaborated stadiums. In worst case, unpleasant problems can require that the whole concept has to be revised (Moser, 2012), (Nestler, 2014).

(53)

2.3.3 Modeling the Human – Computer Interface

For simplifying testing with users, a definition is needed, which users will interact with the computer system. One common technique is to model a user, which will represent a target group using the computer system. Such users will be developed as so-called personas.

2.3.3.1 User Story

User stories have been developed for the acquisition of requirements in agile software projects. They describe requirements from the user’s perspective in one sentence. To distinguish them, Personas describe who the users are and user stories describe what they do. They contain only the minimal information and are elaborated when necessary but then they give a detailed description of how personas interact with the product. (Working on details in an early stadium where this is not necessary should be avoided). In development personas should be created before user stories since the personas can act for the user stories to highlight tasks (Zimber, 2014), (Cohn, 2010), (Arbor, 2014c), (Moser, 2012).

All in all user stories actually consists of three parts: a story card with the written description, discussions about the story to elaborate it in details and acceptance criteria to define when a user story is finished (Cohn, 2010).

The wording of user stories can, for example, take place within in a story-writing workshop. Participants of this workshop are all important stakeholders of the product (i.e. testers, product manager, real users, and design team) (Cohn, 2010), (Moser, 2012).

By the hand of the product vision, which has been developed before, all types of user roles of the intended product have to be considered. Thereby it is helpful to use, if developed before, personas. After that, the basic goals are formulated for every user role. Since these would be too big for user stories, they are elaborated as so-called “Epics”, that are superordinate user stories and written down on cards. The epics are split up into user stories later (Cohn, 2010), (Moser, 2012).

Typically, user stories are written down on so called “story cards”. Due to the limited space, the writer has to formulate his story short. Moreover, this procedure is very uncomplicated and fast, but it is important that customers and developers have discussed the story and its value before. Additionally, stories should be independent from another so that they could be implemented in any order (Cohn, 2010), (Moser, 2012).

One suggested format writing user stories short on the card is the pattern: “As a [role], I can [feature] so that [reason]”. The story card furthermore contains a distinct identifier, a concise

(54)

title, acceptance criteria and additional information beside the functional description (Cohn, 2010), (Moser, 2012).

A story needs to be testable. Hence, the acceptance criteria are needed to check whether a user story is implemented correct. Suitable therefore are concrete positive and negative examples, which are written on the backside of the story card. Sometimes additional information is needed to explain the story (for developers) (Cohn, 2010), (Moser, 2012).

2.3.3.2 User Acceptance Criteria

User Acceptance Criteria are subjective factors that depend on the project. They are derived from user stories that are defined at the very beginning of the development of a product. The user story is accompanied by acceptance criteria. User acceptance criteria should be defined on the backside of the story card (Cohn, 2010).

Figure 29: Overview user experience design- focus User Acceptance Criteria

The user acceptance criteria are connected to the whole user experience design (see: Figure 29), because based on the design the users accept or not accept a feature or product.

At last, a robust feature maximizes compatibility with current and further user agents, including assistive technologies (Caldwell et al., 2008).

2.3.3.3 Personas for Requirements Management and

Usability Tests

(55)

Figure 30: Overview user experience design with focus on Personas

Personas are fictional people who are representatives for a category of users with similar needs. That is why Personas are connected in Figure 30 to the users’ needs. Developing Personas is a technique to represent user groups that are relevant for the product. They help when making design and development decisions (Moser, 2012), (Unger, 2012), (Usabilla & Mifsud, 2014), (Bowles, 2010).

A part of the team, especially the UX-Designer, determines them at the beginning of the development of the product. Therefore, a workshop is established where important stakeholder and design team participate (Moser, 2012), (Unger, 2012).

The before proceeded user research provides the necessary data to create them. The data is analyzed, visualized and collected group wise with similar needs, which are relevant for the product. The Personas were developed from the identified facts and can be exemplary described by the following items (Moser, 2012), (Unger, 2012), (Bowles, 2010):

• Attractive name

• Realistic photos from the users in context

• Profession and functions

• Demographic data

• Skills, knowledge and experience

• Preferences, motivation and hobbies

• Objectives, expectations and wishes to the product

• Short quotation

Figure 31 is exemplary one of the used Personas at Immowelt. For the “Note Taking” feature, Personas have been created by an external agency (usa, 2010).

(56)

As it can be seen for the Persona called Wolfgang, the above listed attributes (name, photo, profession etc.) have been created.

(57)

Figure 31: Persona Wolfgang (usability.de, 2010)

(58)

The developed Personas are introduced to the whole team. For example, they are spread as cards on the tables in a meeting. Thereby, the objective is to present all Personas in every discussion, at every decision and every meeting so that every team member has the same understanding of the user requirements represented by them (Moser, 2012), (Unger, 2012), (Bowles, 2010).

Personas represent the needs of standardized users. Consequently, they can be used for detecting requirements of the feature. Additionally, they are used to do first usability tests, such as example scenarios (U.S. Departement of Health & Human Services, 2014).

Personas have limitations and should be supplemented by the additional surveys (Bowles, 2010).

2.3.4 Testing the Design

There are many possibilities for testing the user experience design. However, the goal is to improve the usability of a product to achieve a good user experience design, as the focus in this thesis is user experience design.

Figure 32: Overview user experience design - focus Testing

Figure 32 shows the position of the tests in relation to user experience design. It is placed outside because the tests base on the usability of the design.

To process a usability test first a prioritized set of tasks for the website has to be created. The (potential) users have to be engaged to fulfill these tasks and thereby the users are observed. It has to be examined and noted where the users have issues and successes. On this way, the actual usability of the product can be derived and according to that, which steps include problems and ambiguities. The test can be executed with a prototype during the development process or with the finished product (Unger, 2012), (Moser, 2012), (Bowles, 2010).

(59)

During the development so-called formative tests are conducted on the unfinished system to gain insight on how to improve the design.Thereby the methods are not quite formal but last to reveal the most important weak spots (Unger, 2012), (Moser, 2012), (Bowles, 2010).

Near the end of development or with existing products, so-called summative tests are conducted as analysis of the website or as a prelaunch check. The usability is measured in a (very) realistic situation and the market maturity of a feature or product can be declared (Unger, 2012), (Moser, 2012), (Bowles, 2010).

For the weak spots that are revealed by the usability test, approaches are acquired, which slip into the next circuit. In doing so, a natural control circuit arises which corrects the mistake that occurs by the various steps of the design. During the execution of such a test, weak spots can be revealed. Therefore, approaches have to be acquired which slip into the next development circuit. Thus, a control circuit develops that corrects mistakes, which occur by the various design steps (Unger, 2012), (Moser, 2012).

2.3.4.1 General Process of a Usability-Test

In the following, the process of a usability test is described.

Therefore, the clarifying of objectives, the preparation of suitable tasks, the choice of suitable evaluation methods and the outcome of the evaluation have to handled step by step.

“What you test depend on when you test.” (Unger, 2012) At first, the goal and the purpose of the test have to be determined and according to the test form, the test objects have to be defined. Consequently, designs that should be tested have to be selected. Next suitable tasks have to be created. These tasks should be representative for users using the system in reality (Moser, 2012), (Unger, 2012), (Bowles, 2010), (Rubin, 2008).

In addition to the evaluation method, the time schedule and the planned participants have to be considered (Moser, 2012), (Unger, 2012), (Bowles, 2010), (Rubin, 2008).

Participants can be recruited after preparing the tasks. Doing the recruiting it is important that users be chosen from every user group, whereas existing customers are recommended, (their opinions are of interest to the company) (Moser, 2012), (Unger, 2012), (Bowles, 2010), (Rubin, 2008).

If a quantitative evaluation is done, it is important that a sufficiently large random sample of users be chosen. It is recommended to proceed as many tests as possible, but in just one test five users can uncover the most important issues (Unger, 2012).

For the time schedule, it is recommended to plan three times as long as a team member, who knows the system, for the tasks (Unger, 2012).

User Experience Design at Immowelt

Friedrich-Alexander-Universität Erlangen-Nürnberg

Technische Fakultät, Department Informatik

Rebecca Reuter

BACHELOR THESIS

User Experience Design at Immowelt

Versicherung

License

Table of Contents

Abstract

Introduction

1 Teaching Case

1.1 The “Note Taking” Feature at Immowelt AG

1.2 The Company

1.3 Design of the “Note Taking” Feature for

www.immowelt.de

Platform

1.4 Developing a Vision for the Proposed Feature

1.5 Recording Detailed Requirements

1.6 Design Decisions for the “Note Taking” Feature

1.7 User Experience with the “Note Taking” Feature

1.8 Summary: User Experience Design for the “Note Taking”

Feature

Part II

2 Literature

2.1 Overview of “Literature”

2.2 Designing a Feature with UXD

2.3 User Experience Design Process of a Feature

2.3.1.1

Business Analysis

2.3.1.1.1 Competition Analysis

2.3.1.1.2 Stakeholder Interviews

2.3.1.2

User Research

2.3.1.2.1 Analysis of the target audience

2.3.1.2.2 Tracking

2.3.2.1

Design principles

2.3.2.2

Storyboards

2.3.2.3

Style guide

2.3.2.4

Prototyping

2.3.2.4.1 HTML click dummy as interaction prototype

2.3.2.4.2 Graphical Mock- ups as visual design prototypes

2.3.3.1

User Story

2.3.3.2

User Acceptance Criteria

2.3.3.3

Personas for Requirements Management and

Usability Tests

2.3.4.1

General Process of a Usability-Test