<<

Faculty of Science Chair of Media

MASTER'S THESIS

IMPROVING DESIGN MATURITY BY APPLYING OPTIMIZED UX DESIGN WORKFLOWS

Olga Davydkina MN 3757874 Chair of Media Design Faculty of Computer Science Dresden University of Technology

Robotron Datenbank- GmbH Stuttgarterstr. 29 01189 Dresden

Supervising university lecturer: Herr Prof. Dr.-Ing. habil. Rainer Groh Supervisors by Robotron: Frau Ines Hermel, Herr Dr. Hilko Donker

Dresden, 29.08.2017

NOTE OF THANKS

This research was supported by Robotron Datenbank-Spftware GmbH. I thank all the colleagues from Robotron, who provided insight and expertise that greatly assisted my research.

I express my warm thanks to Prof. Dr.-Ing. habil. Rainer Groh and Dr.-Ing. Ingmar S. Franke for their aspiring guidance, constructive criticism and friendly advice during my research. I thank all the employees of the Chair of Media Design at the Dresden University of Technology for supporting and inspiring me during all my studies.

I would like to express my sincere gratitude to my advisors from Robotron Ines Hermel and Dr. Hilko Donker for the continuous support of my master’s thesis and related research, for their patience, motivation, and immense knowledge. Their guidance helped me in all the time.

Last but not the least, I would like to thank my family: my parents and my friends for supporting me spiritually throughout writing this thesis.

CONFIRMATION

I confirm that I independently prepared the thesis and that I used only the references and auxiliary means indicated in the thesis.

Dresden,

29 August 2017

ABSTRACT

User experience (UX) describes the way a user feels when interacting with a software and plays an important role for the user’s satisfaction with a software product. However, it is often neglected in business-to-business software products in spite of the fact that these are often very complex. Since a good improves the customer‘s productivity, it can improve the economic success of business-to-business software companies as well. In this master‘s thesis, we focus on the German enterprise software development company Robotron Datenbank-Software GmbH. At the moment user experience does not play a central role in the development cycle at Robotron. Design decisions are not managed centrally, but are often made by software developers, which leads to additional costs, redundant programming efforts and limitations in the user experience. The goal of this master‘s thesis is to improve the actual situation sustainably by proposing changes to the software development cycle at Robotron. The basis for this are UX maturity models, which describe the sequence of stages companies process on the way to improve the user experience of their software. First, we analyze the actual development cycle at Robotron based on interviews that we conduct with Robotron employees. Then, we classify Robotron‘s current state into the UX maturity model by Nielsen and determine the next realistic UX maturity stage to achieve. We find out that the main requirements for this are the launch of an official user-centered design process, the creation of a centralized UX team, an development process, field studies and a stable UX budget. We develop a concept which proposes solutions for all these requirements and is based on an agile iterative design process. Moreover, we verify the concept by using it for a real UX problem in one of Robotron‘s products. For this we develop a high-fidelity which shows first improvements of the user experience.

TABLE OF CONTENTS

Abstract...... 1

1 Introduction ...... 2

2 Basics and terms ...... 4

2.1 User Experience (UX) Design ...... 5

2.1.1 Separation between and technical realization ...... 5

2.1.2 User Experience (UX) ...... 5

2.1.3 ...... 6

2.1.4 User-centered design (UCD) ...... 7

2.1.5 Usability and user experience ...... 8

2.1.6 Information (IA) ...... 8

2.1.7 (UI) design ...... 9

2.1.8 User interaction design ...... 9

2.2 Process ...... 9

2.2.1 Linear Design Process ...... 10

2.2.2 Iterative design process ...... 12

2.2.3 Usability Evaluation Methods ...... 15

2.2.4 Prototyping Techniques ...... 17

2.3 Software Development Methodologies ...... 19

2.3.1 Waterfall Model ...... 20

2.3.2 Joint Application Development (JAD) ...... 22

2.3.3 Agile Software Development ...... 23

2.4 Summary ...... 25

3 Related work ...... 26

3.1 UX Maturity Models ...... 26

3.1.1 Criteria for the choice of the UX maturity model: ...... 26

3.1.2 Jakob Nielsen maturity model ...... 27

3.1.3 Levels of UX Maturity ...... 28

3.1.4 Detailed Stages of UX Maturity ...... 31

3.2 Integration of UX design methodologies into software development ...... 37

3.2.1 ...... 37

3.2.2 Time gain for product discovery and user research ...... 37

3.2.3 Incremental and Iterative design ...... 38

3.2.4 Sprint zero...... 38

3.2.5 work one sprint ahead ...... 38

3.2.6 Inclusion of artifacts ...... 38

3.2.7 Day to day success ...... 38

3.2.8 Team collaboration ...... 39

3.3 Summary...... 39

4 Analyses ...... 40

4.1 Presentation of Robotron Datenbank-Software GmbH ...... 40

4.1.1 Product overview...... 41

4.2 Survey ...... 43

4.2.1 Preparation of the survey ...... 44

4.2.2 Interview Process ...... 46

4.3 Evaluation of the Survey Results ...... 46

4.3.1 robotron*ecount ...... 46

4.3.2 robotron*Webportal 2.0 ...... 52

4.3.3 robotron*Daphne ...... 55

4.3.4 Conclusion of the survey results ...... 58

5 User Experience Maturity Classification ...... 60

5.1 Analysis of Robotron at the low UX maturity ...... 60

5.1.1 Importance of user-centered design at the company ...... 61

5.1.2 Existence of a user interface in the development cycle ...... 61

5.1.3 Availability of funding for user experience design ...... 61

5.1.4 Conclusion of the low maturity level analysis ...... 62

5.2 Analysis of Robotron at the middle UX maturity level ...... 63

5.2.1 Analysis of the shift to stage 4: dedicated UX budget ...... 63

2

5.2.2 Analysis of the shift to stage 5: Integrated User-Centered Design ...... 64

5.2.3 Analysis of the shift to stage 6: systematic user-centered design ...... 65

5.2.4 Conclusion of the middle UX maturity level analysis ...... 65

5.3 Analysis of Robotron at the high UX maturity level ...... 67

5.4 Conclusion of the Classification of Robotron UX Maturity ...... 69

6 Concept Development...... 70

6.1 Official UX group ...... 70

6.2 Interaction Design ...... 71

6.3 Visual Design ...... 71

6.4 User Research ...... 71

6.5 User Assistance ...... 71

6.6 Design Consulting ...... 72

6.7 Field studies...... 72

6.8 Stable usability budget ...... 73

6.9 Official user-centered design process ...... 73

6.9.1 Simplified solution ...... 74

6.9.2 Complex task solution ...... 76

6.9.3 Process accompaniment and design consultation ...... 77

6.9.4 Check list for software testing ...... 77

6.10 Iterative design process ...... 79

6.10.1 UX team requirements ...... 79

6.10.2 Unpack ...... 80

6.10.3 ...... 81

6.10.4 Decide ...... 81

6.10.5 Prototype ...... 81

6.10.6 Test ...... 82

6.11 Summary ...... 83

7 Concept Verification ...... 84

7.1 Choice of the task for the verification – Ticket definition ...... 84

3

7.2 Unpack ...... 85

7.2.2 State of the Art ...... 87

7.3 Sketch ...... 92

7.4 Decide ...... 93

7.5 Prototype...... 95

7.6 Test ...... 98

7.7 Summary...... 98

8 Conclusion and Outlook ...... 100

Bibliography ...... 102

List of Figures ...... 107

Attachment ...... 110

4

Introduction

1 INTRODUCTION

User experience (UX) describes the way a user feels when interacting with a software and plays an important role for the user’s satisfaction with a software product. While software companies like Apple, Google and Microsoft recognize the high value of providing the best UX for their customers, business-to-business (B2B) software development companies very often underestimate the importance of user experience design in spite of the fact that B2B software applications are usually very complex. However, simplicity, time, efficiency and empowerment are very important factors for B2B software users as well. Therefore, B2B software development companies have a big potential for improving the success of their software products by improving the user experience.

Robotron Datenbank-Software GmbH (Robotron) is a German software company headquartered in Dresden, Saxony. The company specializes in the analysis and evaluation of large data sets and develops enterprise software products. In the current software product development processes at Robotron the questions regarding user- interface design as well as user-experience design are not considered systematically. Pending decisions for user interaction and are often made directly by the developers or in short arrangements within the development team. Currently, these decisions are neither managed nor controlled centrally. In some projects complex tasks of user-interface design are outsourced to external companies. The results of these external design concepts cannot be fully implemented into the projects. These facts lead to both, additional costs and redundant programming effort of software developers. In the overall result, this causes limitations in the usability of the software.

The objective of this master’s thesis is to analyze the current processes in software product development at Robotron. Next, based on the analysis, we want to develop a proposal for the process improvement. The main goal of the research is to sustainably improve the usability of the software for the long term. As a result, developers should be relieved of all design decisions.

2 Introduction

In Chapter 2, we present the important basics and term required for understanding this master’s thesis. One way to achieve our goals is the use of a UX maturity model. UX maturity models describe the sequence of stages the organizations process on the way to improve the user experience of their software. With the help of UX maturity models, the first step is to examine to what extent the actual processes of the product development at Robotron are user-centric, as well as to define the role of user interface and user interaction design in the software development. In Chapter 3 we discuss the topic of UX maturity models and other related work in detail. After that, we perform the UX maturity analysis of the company by analyzing and visually presenting its software products as well as its software development cycle in Chapter 4. Based on that, the company is being classified into the chosen UX maturity model in order to determine the next realistic UX maturity stage to achieve in Chapter 5.

The result of the master’s thesis should to be an elaborated concept. The concept should describe developed proposals, which include the change measures that are necessary to apply to the current software development process in order to increase the UX maturity of the company. As a result of this increase, the usability of the software products of the company is expected to be improved. Moreover, the productivity of the software developers is expected to be maximized by the relief of design tasks. We present our concept in detail in Chapter 6. Then, we verify the concept in Chapter 7 by using it for a real UX problem in one of Robotron’s software products. In the end, we provide conclusions and outlooks in Chapter 8.

3 Basics and terms

2 BASICS AND TERMS

In this chapter we explain important basics and terms that are required for the understanding of the main part of this master’s thesis. In Section 2.1 we introduce terms in the field of user experience design. Then, in Section 2.2 we focus on the user experience design process in more detail. After that, we discuss software development methodologies in Section 2.3.

A user interface (UI) is the front-end application view a user interacts with in order to use the software. The user can manipulate and control the software as well as hardware by the means of user interfaces. Today, user interfaces are found at almost every place where digital technology exists: , mobile phones, cars, music players, airplanes, ships etc.

A user interface is a part of the software and is designed in such a way that it is expected to provide the user with all he or she needs to manipulate this software. A UI provides a fundamental platform for human-computer interaction. It can be graphical, text-based, and/or audio-video based, depending upon the underlying hardware and software combination. A UI can be hardware or software or a combination of both.

High quality software products that are functional and useful require the skills and expertise of different professions. Software development processes are effective at producing software fulfilling its functional requirements, but often overlook the actual requirements of real users. User experience design focuses on the collection of the requirements of the end user to create and improve the usefulness and usability of software products. A good process requires knowledge of many design fields. A deep understanding of all the terms in software design and their difference is important to design a usable software product.

Each ordinary software company consists of developers, designers, consultants, teams, team leads and many other employees that have specific responsibilities and tasks. The work of these people has to be structured and strategically organized in order to achieve

4 Basics and terms the best results, working software and happy customers. That is why there are so many software development models that describe an organization’s work process for software development. The whole software development process consists of many internal processes inside the organization, such as analysis, back-end design, user experience design or implementation.

2.1 USER EXPERIENCE (UX) DESIGN

„…The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use….“ Jakob Nielsen [2]

2.1.1 Separation between interaction design and technical realization

According to Hußmann, during the development of interactive applications a separation into a two-stage-process is very advisable. On the one hand, there is the interaction design stage, which consists of concepts, , evaluation and stable tested design. On the other hand, there is the technical realization of the software. It comprises technical analysis, technical specification, software architecture, implementation and quality management. [1]

Following [1], we focus only on the software design process (interaction design stage) in this master’s thesis. More precisely, we focus on the design process for building a good, usable user interface (UI) that will provide the best user experience (UX) for the customers of Robotron Datenbank-Software GmbH.

2.1.2 User Experience (UX)

The term user experience was created by Donald Norman - a cognitive science researcher, who was the first to describe the importance of user-centered design [3]. He states that design decisions should be based on the needs and wants of users. By doing user research, creating wireframes and prototypes and conducting usability tests, user experience design focuses on making the product easy to use, providing users with the best experience possible. People who work on UX, so-called UX designers, study and evaluate how users feel about a system. They work on aspects such as the ease of use, the perception of the value of the system as well as utility and efficiency in performing tasks [3]. They study the software processes and write user stories [4].

5 Basics and terms

User experience is considered to be a preamble for all other design terms as many other fields are an integral part of good user experience design (see Figure 1). To provide the software user with a great user experience, a deep knowledge of the fields of human computer Interaction, psychology, ergonomics, marketing and design is required. Designing a great user experience means to understand the end user, his or her goals and needs. An understanding of accessibility, human factors and usability is required to create good software experience. Data load time, system performance and how fast the software feels is a large part of user experience and should be weighed equally with the aesthetics of the software. [3]

Figure. 1 Terms of user experience design [3]

2.1.3 Usability

Usability is a quality attribute that assesses how easy user interfaces are to use. The word “usability” also refers to methods for improving ease-of-use during the design process. [5]

To elaborate on the term usability let us take a look at the usability objectives described by Rubin and Chisnell [6].

6 Basics and terms

First, it is the usefulness of the software. The product enables a user to achieve his or her goals – the tasks he or she needs to perform.

Second, it is the efficiency (or the ease of use) of the software. This term can be quantitatively measured by the speed of performance or error rate. [6]

Third, it is the software learnability. This term is defined by the user’s ability to operate the system to a defined level of competence. It can be defined after some predetermined period of training.

The final objective is the attitude – or sometimes called likeability – of the software. It is defined by the user’s perceptions, feelings and opinions of the product.

2.1.4 User-centered design (UCD)

The philosophy called user-centered design (UCD) incorporates user concerns and needs from the beginning of the design process and requires that the needs of the user should be considered in all design decisions [7]. User-centered design is a user interface design process that focuses on usability goals, user characteristics, environment, tasks and workflow in the design of an interface. User-centered design follows a series of well- defined methods and techniques for the analysis, design and evaluation of hardware, software and interfaces. The user-centered design process is an iterative process, in which design and evaluation steps are employed from the first stage of the project, through implementation. [8] A user-centered design process is often called human- centered design process.

7 Basics and terms

Figure. 2 Two systems of software development [2]

2.1.5 Usability and user experience

User experience and usability are sometimes used as synonymous, but Grube assumes that these two fields are clearly distinct [3]. He defines user experience (UX) as how a user feels when using a system, while usability is mostly about the user friendliness and efficiency of the interface. Usability is an important part of the user experience and it plays a major role in experiences that fulfill four objectives of usability [6] (see Section 2.1.2). But human factors science, psychology, and user- centered design principles also play major roles in user experience [3].

2.1.6 Information architecture (IA)

Information architecture (IA) involves the way the software is structured and how the content is organized. The goal is to help the users to find the information they need to complete their tasks. Information architects create a structure for the software. They work on an app by categorizing everything it needs to feature. They use flowcharts and to structure content in a way that will make information accessible to users and easy to navigate. Thus, the field of information architecture is an important part of user experience design as well.

8 Basics and terms

2.1.7 User interface (UI) design

“Emotion and Design: Attractive things work better” Don Norman [9]

A user interface is the front-end application view a user interacts with in order to use the software. The user can manipulate and control the software as well as hardware by the means of a user interface. The design and aesthetics of a user interface are focused on maximizing usability and the user experience. The goal of user interface design is to make the user’s interaction as simple and efficient as possible, in terms of accomplishing user goals. However, the user interface of an application is only one aspect of the overall user experience. Other aspects of user interface design, as a part of user experience design, are not visible to the user as, for example, system performance. This aspect is integral to an application and critical to its usability including start up time, latency, error handling, and automated tasks that are completed without direct user interaction.

2.1.8 User interaction design

Interaction design focuses on the interaction between the user and the product [10]. It examines navigation components from a stylistic and functionality standpoint. User interaction design builds a bridge between user interface and user experience. Interaction designers consider how a product behaves when a customer interacts with it. A good example of user interaction is when a user hovers over a button and the system changes the button color. To summarize, interaction design involves how the system reacts on interaction and how it animates elements.

2.2 USER EXPERIENCE DESIGN PROCESS

This master’s thesis focuses on user experience design in a big software company. One of the main goals of this work is to visualize and analyze the established UX design processes in the company. To do the analysis objectively it is very important to know the concepts of the classical linear design process as well as to understand modern state-of- the-art iterative concepts. Furthermore, usability evaluation methods and prototyping techniques play an important role in every design process, so we discuss them in this section as well.

9 Basics and terms

2.2.1 Linear Design Process

While the basic principles and techniques for user interface design are common, different variations of user-centered design processes exist [11]. The following is a typical example of a linear software design process for the user-centered design of software applications. The process is graphically displayed in Figure 3. The graphic outlines the stages of the process. At none of the stages, the designers actually supposed to evaluate the result of the respective stage. However, they can iterate back to the previous stage if something went wrong [11] [12].

Figure. 3 Linear design process [11]

2.2.1.1 Analysis

At the stage of Analysis designers need to develop the list of all functional and non- functional requirements of the user interface. This can be taken from customers, end users or a previously existing software solution that has to be rebuilt. To summarize the purpose of this stage, designers analyze who is going to use the software UI [11].

User/Audience analysis

The target user matters in software UI design, as the design requirements may change according to the knowledge and competency level of the user. According to [13], if the user is technically advanced, a complex UI can be incorporated, but it still has to be usable. For a novice user, more information and hints should be included into the user interface, describing how to use the software and where to begin their work. Techniques such as field studies [14], user categories list and personas [15] can be used at this stage. [12] [13]

Task/Purpose analysis

10 Basics and terms

Designers have to analyze and understand in detail what kind of task the user should execute with the software solution. Tasks can be represented in hierarchical manner, taking one major task and dividing it further into smaller sub-tasks. Tasks provide goals for the UI presentation. The flow of information among sub-tasks determines the flow of UI contents in the software. [13]

Information architecture analysis

Information architecture analysis is the creation of a structure for the application that allows us to understand where the user is and where the information he or she wants is in relation to his or her position. Information architecture can be represented with deliverables such as the creation of a content list matrix, hierarchies, categorizations and navigation structure. [16]

Workflow analysis

According to Jakob Nielsen, the workflow is one of the most important elements of application design. Workflow analysis outlines if users can proceed through their tasks with ease or if they are subjected to irritating detours. At this stage, the UX can apply the technique of writing scenarios for the applications and creating user journey . [13]

2.2.1.2 Definition

After the analysis of the requirements, tasks and user environment, designers design the UI at this stage. They have to choose the right operating elements for the user as well as the interaction between the system and the user. At this stage designers can use techniques such as [17], wireframes [18], [19] and paper prototypes [20]. [12] Prototyping techniques are described in Section 2.2.4 in more detail.

2.2.1.3 Design

According to Figure 3 [12], at this stage designers create aesthetic for the UI elements developed at the previous stage. They choose the right colors and design of the elements and think through the animations for the user interaction and the system. At this stage designers can use techniques such as detailed click prototype design, screen design [9] or even create functional online prototypes.

11 Basics and terms

2.2.1.4 Implementation

At this stage the designed concept is forwarded to the software developer for the implementation of the feature. It is very important for the designer to communicate the implementation of the concept and consider all the design details that should be implemented according to the concept.

2.2.1.5 Evaluation

Evaluation is a process that critically examines the stage of the software design. Its purpose is to make judgments about the achieved result to improve its effectiveness [21]. According to [21], evaluations fall into one of two broad categories: formative and summative. Formative evaluations are conducted during each stage of development and are useful if designers want direction on how to best achieve their goals and improve the design iterating at each stage of the software design process. Summative evaluations should be completed once the application is well established in order to extent the program in achieving its goals. The techniques of the software evaluation will be considered in detail later in Section 2.2.3. [21]

2.2.2 Iterative design process

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a software product. Based on the results of testing the most recent iteration of a design, changes and refinements are made to eliminate usability flows before the product is designed and launched. [22]

There are some simple benefits of the iterative design approach, first and foremost its cost-effectiveness.

It allows for the rapid resolution of misunderstandings within the project team and establishes clarity early in the development lifecycle. Working together in iterations, helps the team shortcut the discussions cycle and to compress months of working time into a single week. It brings out user feedback to ensure that system requirements meet user needs. Instead of waiting to launch a minimal product to understand if an idea is good at all, the team can get clear data from a realistic tested prototype (see Figure 4). It gives the development team some certainty that their efforts are focused on adding value for the users and provides regular testing, which can provide a strong desired

12 Basics and terms performance framework for acceptance testing. It gives stakeholders better visibility of the progress at each iteration. [23] [24]

Figure. 4 Benefits of Google Agile UX design methodology [25]

2.2.2.1 Google Agile UX design methodology [25]

In order to help make the process of UX design more systematic, Google Ventures created their eminent process, used internally at Google and by several well-known companies including Airbnb, Nest and Blue Bottle Coffee. The Design Sprint framework is considered an effective way to validate ideas through rapid prototyping and customer testing and contains five stages: Unpack, Sketch, Decide, Prototype, and Validate. [25] [26]

Each phase takes approximately one day to perform (eight hours) and all five phases take approximately 40 hours to execute in full. [25]

The author of [25] assumes that – like in all good design processes – there is room for iteration in the UX design methodology by Google. Designers are strongly encouraged to make revisions based on the first sprint and then reiterate the last two phases. However, if the design team discover they do not gain the results they expected, the team can also move further back and reiterate from there.

In the following, we describe the team’s activities in each of the five stages.

Unpack

13 Basics and terms

The first day is a day of structured discussions in order to create a path for the sprint week. In the morning, the team agrees on a long-term goal. Next, they make a list or a map of the challenge on the way to the goal. In the afternoon, they are supposed to speak with the experts at the company to share what they know about the problem. Finally, the team will pick a target: an ambitious but manageable piece of the problem that the team can solve in one week. [25]

Sketch

After a full day of understanding the problem and choosing a target for the sprint, the team gets to focus on solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person works on a sketch, following a four-step process that emphasizes critical thinking over artistry. At this stage the team is going to begin planning the customer test by recruiting customers that fit their target profile. [25]

Decide

In the morning of day four the design team will have a stack of solutions. The problem is that the team needs one solid . The team critiques each solution and decides which ones have the best chance of achieving their long-term goal, put on day one. Then, in the afternoon, the design team takes the winning scenes from the sketches and weaves them into a . That will be a step-by-step plan for the prototype the next day. [25]

Prototype

After the team created a storyboard, on the fifth day they turn that storyboard into a prototype. A realistic UI is all they need to test with customers. By focusing on the customer-facing surface of the product or service, the team can finish the prototype in just one day. At this stage the team also makes sure everything is ready for test by confirming the schedule, reviewing the prototype, and writing an interview script. [25]

Test

By this point in time, the team has created some problem solutions, chosen the best, and built a realistic prototype. However, at this stage the team takes it one step further as they interview customers and learn by watching them react to their prototype. The test stage makes the entire sprint important. At the end of the day, the team knows how far they have to go and what they have to do next. [25]

14 Basics and terms

Summary

At this point of research we have considered two different methods of how a software design process in the firm may work as well as benefits and disadvantages of both methods. The evaluation respectively test phase of each method is one of the most important parts of the design process. Therefore, we continue with usability evaluation methods that may be applied while prototype testing.

2.2.3 Usability Evaluation Methods

Usability is a measure of interface quality that refers to the effectiveness, efficiency and satisfaction at which users can perform tasks with a tool. [27] [21] Evaluating the usability of software is considered an essential part of the system development process. Furthermore, it is very important for the further concept development of this master’s thesis to understand how evaluation methods work and what kinds of evaluation exist. A variety of methods have been developed to support the user experience professional team in its work. There exist multiple methods of evaluating usability depending on available resources (time facilities and labor), evaluator experience, ability and preference, and the stage of development of the tool under review. In broad terms there are the following distinctions between evaluation methods: [27] [21]

 User-based  Expert-based  Model-based

2.2.3.1 User-based methods

Testing an application with the goal to watch the users performing in a set of pre- determined tasks is generally considered to be the most reliable and valid estimate of an application’s usability. [21] Performed either in a usability test laboratory or a field site, the aim of such a test is to examine the extent to which the application supports the intended users in their work.

In a typical user-based evaluation, test subjects are asked to perform a set of tasks with the application. Depending on the primary focus of the evaluation, the users’ success at completing the tasks and their speed of performance may be recorded. After the tasks are completed, the users are often asked to provide data on likes and dislikes through a survey or interview, or may be asked to view with the evaluator a part of their own

15 Basics and terms

performance on video and to describe in more detail their thoughts and perceptions of the application. [21] In this way, measures of effectiveness, efficiency and satisfaction can be derived and problems of the UI can be identified. In this case the re-design requirements can be determined. In certain situations, concurrent verbal protocols might be solicited. In a usability lab, the complete interaction is normally video recorded for subsequent analysis of transactions, navigation, problem handling etc. [27].

However, more informal approaches are also possible. Some user-based tests are unstructured, involving the user and the evaluator jointly interacting with the system to gain agreement on what works well and what problems should be corrected in the UI design. Such participative approaches can be very useful for exploring interface options in the early stages of design where formal quantitative assessments might be premature. [21]

Ideally user testing with a large sample of the intended user population would routinely occur. However due to resource limitations, user-based tests are often constrained. As a result, there is considerable interest among HCI professionals in determining how to gain the most information from the smallest sample of users. [21]

2.2.3.2 Expert-based methods

Expert-based methods refer to any form of usability evaluation which involves an HCI expert examining the application and estimating its likely usability for a given user group. In such cases, users are not employed and the basis for the evaluation lies in the interpretation and judgment of the evaluator. There is considerable interest in this form of evaluation since it can produce results faster and presumably cheaper than user-based tests. [27]

In HCI, two common expert-based usability evaluation methods are heuristic evaluation [28], and cognitive walkthrough [29]. Both methods aim to provide evaluators with a structured method for examining and reporting problems with an interface.

The heuristic evaluation method provides a simple list of design guidelines, which the evaluator uses to examine the interface screen by screen and while following a typical path through a given task. The evaluator reports violations of the guidelines as likely user problems. [29]

In the cognitive walkthrough method, the evaluator first determines the exact sequence of correct task performance, and then estimates, on a screen-by-screen basis, the likely

16 Basics and terms success or failure of the user in performing such a sequence. In both methods, the expert must make an informed guess of the likely reaction of users and explain why certain interface attributes are likely to cause users difficulties. [27]

These methods differ in their precise focus. Heuristic methods are based on design guidelines and ultimately reflect the expert’s judgment of how well the interface conforms to good design practice. The cognitive walkthrough method concentrates more on the difficulties users may experience in learning to operate an application to perform a given task. In practice, usability evaluators tend to adapt and modify such methods to suit their purpose and many experts who perform such evaluations employ a hybrid form of methods. [27]

2.2.3.3 Model-based methods

Model-based approaches to usability evaluation are the least common form of evaluation, according to [27]. However, several methods have been proposed which can accurately predict certain aspects of user performance with an interface such as time to task completion or difficulty of learning a task sequence. In such cases, the evaluator determines the exact sequence of behaviors a user will exhibit through detailed task analysis and applies an analytical model to this sequence and calculates the index of usability. [27]

2.2.4 Prototyping Techniques

Since prototyping plays an important role in every design process, this field also deserves some attention here.

A user interface prototype is a hypothesis – a candidate design solution that is being considered for a specific design problem. The most straightforward way to test this hypothesis is to watch users work with it. [30] Knowing the prototyping techniques is very important for any software design process, as it is an integral part of the evaluation and test phase of the design process.

17 Basics and terms

Figure. 5 Prototyping techniques [30]

There are many kinds of prototypes, ranging between the following pairs of extremes:

 Single page prototypes consist of a single page and represent a piece of UI design. Multipage prototypes represent a sample with enough menus, screens, and click targets to enable the user to completely finish a task.  Realistic and detailed prototypes vs. hand-sketched prototypes on a piece of paper.  Interactive prototypes vs. static prototypes.

The choice of prototype will vary greatly depending on the goals of the testing, completeness of the design, tools used to create the prototype and resources available to help before and during the usability tests [30]. Nevertheless, whatever prototype the design team may use, testing it will help them learn about the users’ interactions and reactions, so they can improve the design. Generally, the characteristics of the groups of the range of extremes described in [30] can all be grouped into low-fidelity prototypes and high-fidelity prototypes.

2.2.4.1 Low-fidelity prototypes

Low-fidelity prototypes are simple, easy to make and use. Typically, these are sketches or printouts of a certain design. It can be a small model of an idea or a simple, fast sketch designed on a computer. An example of a low-fidelity prototype is presented in Figure 6. Low-fidelity prototypes do not allow users to interact with the product. The only interaction done is between the designer and their future design. Low-fidelity prototypes are more of an outline than a prototype. Sketches, Storyboards and Wireframes are typical examples of low fidelity prototype techniques. [30]

18 Basics and terms

Figure. 6 An example of a low-fidelity prototype [30]

2.2.4.2 High-fidelity prototypes

High-fidelity prototypes allow the users to interact via a computer. This kind of prototype is supposed to match the features of the final design. During this stage of development, the human interaction may be measured to increase the knowledge of the future project. This data can help the designers move ahead in significant ways. With high-fidelity interactivity and/or visuals, companies can test workflow-specific UI components, e.g. menus and accordions, graphical elements such as affordance, page hierarchy, type legibility, image quality as well as engagement. These kinds of prototypes can be built with modern GUI builders that allow building realistic software design prototypes. [30]

2.3 SOFTWARE DEVELOPMENT METHODOLOGIES

Each software design process must be integrated into the current processes of the company and work well with other stages of the current software development cycle. After exploring the terms of user experience and usability of the software in the Section 2.1 and defining two types of software design process in the Section 2.2, consequently we analyze common models and concepts for software development in the Section 2.3. To expand the theoretical research we are going to identify the stage or stages for each software development model where user experience design must begin and where it is supposed to end. That will define the scope of this work and help understand the differences between the approaches.

19 Basics and terms

Software development models are the various processes or methodologies that are selected for the development of the project depending on the project’s aims and goals. [31] There are many software development life cycle models. Each model represents a software development strategy. It is specified by various stages of the software development process and the order in which they are executed. Each software model has been developed in order to achieve its own project objectives. This makes it possible to use different development life cycle models within one company, depending on the project aims and goals. [8] [31]

In this section, we introduce four popular models, namely:

 Waterfall Model and its extensions  Joint-Application Development (JAD) and its extensions  Agile Software Development  Lean Development

2.3.1 Waterfall Model

The waterfall model [32] is a popular version of the systems development life cycle model for software engineering. Often, this model is considered the classic approach to the systems development life cycle. The waterfall model describes a development method that is linear. Waterfall development has distinct goals for each phase of development, where each stage of the process is required for the next stage to begin. There is no iteration possible. [8]

Figure 7 presents the basic waterfall model. It consists of five stages, namely requirements, design, implementation, test and .

20 Basics and terms

Figure. 7 Stages of Waterfall model [32]

The objective advantages of the waterfall process are that it can be easy managed and well controlled. A schedule is typically set with deadlines for each stage of development and a product can proceed through the development process. In theory, this process leads to the project being delivered on time because each phase has been planned in detail. [8]

An obvious disadvantage of the waterfall model is that it does not embrace the changes and revisions that often become necessary within the project. Once an application is in the testing stage, it is very difficult to go back and change something that was not considered in the requirements stage.

User interface design would be an integral part of the Design stage of the Waterfall model.

2.3.1.1 V-Model XT

The V-Model [32] is an extension of the waterfall model. [31] The model is built on the sequential stages order. However, it assumes that for each stage of the product a corresponding test stage exists and must be executed.

The V-Model XT [33] is an extension of the V-Model, which allows iterations in the software development process. This model has a complex structure of components, including project types, process modules and project execution strategies. These

21 Basics and terms

components are connected with others and with the ‘extended tailoring’ provide a new methodically way to develop system and project. [8]

Figure. 8 V-Model XT [33]

2.3.2 Joint Application Development (JAD)

Joint Application Development [34] is a requirements-definition and user-interface design methodology in which end-users, managers and developers attend intense off-site meetings to work out a system’s details. [8] Hence, the Joint Application Development (JAD) methodology aims to involve the client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD sessions.

JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems, but it can be used successfully for systems software. [8]

In contrast to the Waterfall approach, JAD leads to shorter development times and greater client satisfaction. This is achieved by the constant involvement of the client in all the development process in order to design the best user experience. So, the user experience designer accompanies the whole process of the JAD software development.

22 Basics and terms

On the other hand, JAD offers the traditional approach to systems development where the developer investigates the system requirements and develops an application, but with consistent client input.

2.3.2.1 Rapid Application Development (RAD)

Rapid Application Development (RAD) [35] is a variation of JAD. It attempts to create an application more quickly. It offers usage of strategies that include fewer formal methodologies and supports the reuse of software components. [8]

RAD proposes that products can be developed faster and with higher quality by integrating the user experience design aspects the following way:

 using workshops or focus groups to gather requirements  prototyping and user testing of  re-using software components  following a schedule that defers design improvements to the next product version  keeping review meetings and other team communication informal

There are many products that can be used in the rapid prototyping development process, such as requirements gathering tools, prototyping tools, software development environments, groupware for communication among development members, and testing tools.

2.3.3 Agile Software Development

Agile software development [36] is a conceptual framework for innovative software engineering projects. There are a number of agile software development methodologies, e.g. Crystal Methods [37], Lean Development (LD) [38] and Scrum [36]. [8]

The Association of Modern Technologies assumes that the most agile methods attempt to minimize risk by developing software in short iterations, which typically last one to four weeks. Every iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-version of a new functionality: planning, requirements analysis, design, coding, testing, and documentation. At the end of every iteration, the team reevaluates the project priorities. Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for

23 Basics and terms

face-to-face communication, agile methods produce very little written documentation relative to other methods. [8]

2.3.3.1 Feature-Driven Development

Feature-Driven Development assumes that a system for building systems is necessary in order to scale to larger projects. [39] Luca declares that the process should be simple enough but well-defined, where steps are logical and clearly relate to each team member. The main idea of the methodology is that the team members focus on the concrete results of their work. It provides a short, iterative, feature-driven life-cycle with initial and ongoing tasks. [8]

In detail, the methodology looks as follows:

 development of an overall model  creation of a feature list  single feature planning  single feature design  build by feature

2.3.3.2 Lean Development

Lean Development (LD) [38] focuses on the creation of change-tolerant software. This methodology embodies the notion of dynamic stability. [38] Bob Charette writes that the measurable goal of LD is to build software with one-third the human effort, one-third the development hours and one-third the investment. [8]

The main principle of Lean Development is that satisfying the customer has the highest priority. However, success depends on active customer participation. The quality of the deliverables is important as well. The best value should be provided for the money. [8] Considering these facts, we can conclude that user experience design is an integral part of the whole software development process in Lean Development.

The active team communication as well as a lot of customer participation is required for the lean project. The process is built such that everything can be changed any time [8]. The completion and achievement of the result as well as are essential in Lean Development. To be able to satisfy these conditions of the Lean Development methodology, the use of modern technology is important.

24 Basics and terms

2.4 SUMMARY

In the Section 2.1 the basic terms of UX design in the company basics and terms were presented. First, we have considered the terms of user experience design, interaction design and usability. In addition, we have discussed the differences and commonalities of the main terms of user experience design. The Section 2.2 consists of the consideration of the methodologies of software design process, evaluation methods as well as prototype techniques that are an integral part of the user experience design. Next, the Section 2.3 the terms and types of software development methods were considered concentrating on how user experience design accompanies each software development methodology.

In order to achieve high-quality user experience in a company’s offerings there must be a seamless merging of the services of multiple disciplines, including software engineering, marketing, graphical and interaction design, and the whole range of disciplines of user experience design. It is important to distinguish the total user experience from the user interface, even though the UI is obviously an extremely important part of the design. One of the greatest threats to any software project is discovering design problems late in the project lifecycle. The later the product development team makes the discovery, and the bigger the problem, the greater the risk to the whole project. Starting to build earlier in the design process and continuing to build as a part of the iterative design process, can have a great effect on the entire design effort.

25 Related work

3 RELATED WORK

This chapter discusses related work for this master’s thesis. Section 3.1 focuses on available UX maturity models, especially the model by Nielsen. After that, Section 3.2 deals with related work on the integration of UX design methodologies into software development.

3.1 UX MATURITY MODELS

Every organization has its own goals, processes, techniques, and teams with special characteristics and workflows. They are all important to consider when incorporating user experience, but it is also crucial to measure the maturity level of an organization. Typically, organizations progress through a sequence of stages as their UX processes develop, evolve and mature. Nielsen Group assumes that to truly become a user- centered organization, companies almost always progress through the same sequence of steps, gradually increasing their levels of commitment to user experience. These steps are described in a design maturity model. [40] [41]

3.1.1 Criteria for the choice of the UX maturity model:

A number of UX maturity models attempt to categorize and define UX design for organizations [40]. While there are some differences in the names and breakdowns given by these models, in general, they consist of five to seven levels and progress in a similar pattern [42]. While the models have broad similarities, they offer few details about what characterizes a mature UX. For example, what are the right methods to use, what is the best ratio of UX designers to developers, should teams be centralized or distributed and how the teams should be organized.

The following maturity models have been taken for the research:

26 Related work

 Jonathan Earthy’s Usability Maturity Scale [43]  Jakob Neilsen’s Corporate UX Maturity [40]  Forrester’s Experience-Based Differentiation [44]  The Journey to a Customer-Centric Business, by Infosys [45]  Indicators of UX Maturity, by Macadamian [46]  Institute (DMI)’s Design Maturity Matrix [47]  Danish Design Centre (DDC)’s Design Ladder [48]  Seductive Interaction Design [49]  Artefact’s Design Maturity Survey [50]

Jakob Nielsen’s UX maturity model [40] makes a lot of important points about the maturity of UX services and also of the organization as a whole. Some of the UX maturity models have been developed on the base of Jakob Nielsen’s model. This model meets the following requirements that we have defined for the choice of the model to apply to this master’s thesis.

- Literature availability: The definition of the model shall be publicly available. - Fine-grained: The model’s stages shall honor even small improvements. - Clearness: The difference between stages shall be clearly defined. - Universality: The model shall not be tailored to a specific company. - Reliable source: The model’s author shall be an experienced and well-respected UX expert.

3.1.2 Jakob Nielsen maturity model

Jakob Nielsen identifies eight levels of adoption of usability by corporations. He calls them the stages of corporate usability maturity. Nielsen assumes that there definitely is a continuum of adoption and appreciation for usability in companies today [40]. By understanding the eight levels we can determine how to best increase the commitment to usability on products of Robotron Datenbank-Software GmbH.

27 Related work

Figure. 9 Stages of Jakob Nielsen maturity model

This is a long and valuable path to move from the first stage of UX maturity to the eighth. Nielsen concludes that it can take a company 20 years to move from stage 2 to stage 7, and perhaps another 20 to reach stage 8. Some companies may understand the problem and break the trend by starting out with a high level of user focus controlling the level of maturity and consciously pushing it forward. The founders of those companies that are interested in improving their UX processes with the help of UX maturity models should benefit from previous experiences of other companies.

3.1.3 Levels of UX Maturity

For this master’s thesis, we logically divide the eight stages into three main levels of UX design maturity. Figure 10 presents a detailed overview of the defined UX levels.

 Low UX maturity level  Middle UX maturity level  High UX maturity level

3.1.3.1 Low UX maturity level

The low UX maturity level consists of stage 1 to stage 3. For organizations at this level, user experience is not treated proactively, but emerges as a consequence of certain business goals and IT constraints. The most common barriers here are ignorance and rejection of UX of the company. There are no resources with knowledge of user experience. At the completion of the low UX maturity level the company realizes the importance of UX for its business and begins performing some of the UX activities.

28 Related work

3.1.3.2 Middle UX maturity level

The middle UX maturity level includes the stages 4 to 6. At this level, employees scattered around the company or a small UX team within the organization focused on user experience emerge. At the beginning of the level it is possible that some user tests have been done, but they are rare and not methodologically strict. The completion of this level supposes the company to develop an official, centralized UX process including the application of iterative UX design methodologies. The common barriers at this level are budget, time, resources as well as formalization, and deepening of the UX design process. The UX technique that has been implemented may not become a consistent part of the design process.

3.1.3.3 High UX maturity level

The value of UX has increased by the completion of the middle level of maturity. Different departments within the organization ask for more resources and better skills, but it is difficult for the UX team to meet these demands. At the high maturity level the software company creates special software tools for tracking user experience. User experience becomes one of the key factors that define the strategy of the software company. Next, we have a detailed look at each stage of Nielsen’s maturity model to present the characteristics of each stage of UX maturity to the reader.

29 Related work

Figure. 10 Overview User Experience (UX) Maturity levels

30 Related work

3.1.4 Detailed Stages of UX Maturity

3.1.4.1 Stage 1: Hostility towards Usability

Nielsen describes the first stage of UX Maturity as the software development with ignorance of the user needs. The goal of the company is to build features and make them work on the computer. At this stage, humans are supposed to be irrelevant as users. According to Nielson, it is almost impossible to make any UX improvements without the management of the company being ready to consider usability and enter the next stage.

3.1.4.2 Stage 2: Developer-Centered User Experience

At this stage, the company realizes the importance of user experience and the value of making designs easier for humans to use [40]. At this point, the most obvious approach to use is for the development team to rely on its own intuition about what constitutes good usability. According to [40], this approach works reasonably well for one class of design problems: developing tools for professionals with minimal user interaction, such as web servers. At this stage of UX maturity there is no usability funding. Thus, the company uses internal resources and hires developers who are receptive to the field of UX. [40]

3.1.4.3 Stage 3: Stunkworks User Experience

According to [40], at stage 3, the organization realizes that it should not rely on the design team’s personal judgment of what will be easy for customers to use. Despite all the barriers, a few groups within the company initiate small UX efforts. At this point, the company may hire an external usability expert for the company’s first independent assessment of user experience quality. [40] There is no official recognition of user experience as a discipline, nor is there an approved budget allocated in advance. This is what distinguishes this stage from higher levels of UX maturity.

31 Related work

Figure. 11 Low User Experience (UX) Maturity level

3.1.4.4 Stage 4: Dedicated UX Budget

The major difference between stages 3 and 4 is a dedicated budget for UX. Although the budget is small, UX activities are planned in the same way as other quality processes. [40] Depending on the company’s size, the UX budget might cover only a percentage of a single employee’s time or it might allow for a few full-time UX specialists. In either case, the UX specialists do not use any systematic processes in place.

The main usability method at this stage is user testing, which is invariably conducted late in the development process after the user interface has been at least partially implemented [40]. After most of the software has been implemented, it is very difficult and expensive to make any changes to the software.

32 Related work

3.1.4.5 Stage 5: Managed Usability

At stage 4, the UX budget is scattered around the organization. However, these budgets can be canceled without notice, resigning the staff to work on non-usability areas of their projects.

On the other hand, at stage 5, there is an official UX group, led by a UX manager who can manage UX and usability activities and research in the company. Typically, the group starts with only a few members, but tends to grow and acquire dedicated usability lab as the company increases its user testing. [40]

Managing user surveys and test archives enhances the understanding of the company’s users, which culminates in company-specific design guidelines. Such cross-study insights are an early move towards the systematic usability processes that characterize stage 6 of corporate usability maturity. Finally, stage 5 is the first stage at which the company has a person – the UX manager – whose job it is to think about user experience across the organization and across design projects.

“If UX managers spend the most of the time fixing individual design mistakes, they will fail their most important task, as Nielson Group assumed: increasing organizational maturity and leveraging existing UX staff for more strategic purposes.” [41]

The common barrier at this level is that the UX budget is too small to implement all the recommended usability activities for all projects. According to [41], instead, the UX manager must select particularly promising projects and make them into spectacular wins for user-centered design.

3.1.4.6 Stage 6: Systematic User-Centered Design (UCD) Process

At this level, the company has recognized the need for an actual user-centered design process, with multiple activities and milestones. With important projects, the team is supposed to conduct early user research before they do any design. The company also has a user interface design standard or a centralized definition of preferred design patterns. [41]

Furthermore, the company likely has a process in place for tracking user experience quality throughout design projects and across releases. An iterative design process is more common at this stage because the company realizes that it cannot achieve the best interface quality in one round of usability fixes. Much better results come from

33 Related work

gradually refining a series of designs from early paper prototypes to the final implementation as well as from testing at each step.

Figure. 12 Middle User Experience (UX) Maturity level

34 Related work

3.1.4.7 Stage 7: Integrated User-Centered Design

At stage 7, conducting field studies and very early user research becomes more prominent. Each development lifecycle step at maturity level seven is infused with user data, including the project definition itself and the requirements phase. [41]

Beyond simply estimating user experience quality, the company begins tracking quality through quantitative usability metrics. Furthermore, each project has defined usability goals. Each design iteration must surpass these measurements for the design to be greenlighted for release. [41]

At the earlier maturity stages, usability was mainly a quality discipline that ensures ease of use of whatever the company is building. At stage 7, the company begins to employ usability data to determine what it should build. [41]

3.1.4.8 Stage 8: User-Driven Corporation

Gained user data from user research and quantitative tracking tools does not just define individual projects at stage 8. It determines what types of projects the company should fund. That is, the company employs user research to determine its overall direction and priorities. Furthermore, the concept of total user experience is extended beyond the screen to other forms of customer interactions with the company. [41]

The main difference between stages 7 and 8 is one of degree. The company uses mostly the same usability methods, but at this ultimate maturity level, those methods affect corporate strategy and activities beyond interface design. [41]

35 Related work

Figure. 13 High User Experience (UX) Maturity level

36 Related work

3.2 INTEGRATION OF UX DESIGN METHODOLOGIES INTO SOFTWARE DEVELOPMENT

Integrating UX design methodologies into software development projects can be challenging. UX design and software development should complement each other. Neil O’Donoghue suggests a list of ideas to keep in mind while integrating UX into the software process development of a company [51]. These can be later considered during the concept development for Robotron Datenbank-Software GmbH.

Neil O’Donoghue mentions a software development processes such as agile iterative project management. He assumes that the process has a focus on delivering small sets of working software features to customers as quickly as possible [51]. On the other hand, UX design methodologies – while also focusing on quick iterations of design – advocate spending considerable effort on user research, validation and analysis before development begins. [51] The organization’s planning of projects and teams, the level of communication, collaboration and the UX strategy can all hinder the effectiveness of integrating UX into software development projects.

3.2.1 Design education

A fundamental problem with many organization and individuals is the misunderstanding of the role of a UX designer, with them often being perceived and labelled as UI or graphic designers or individuals who merely create wireframes and make the product functional [51]. Neil O’Donoghue assumes UX designers’ skillset includes the ability to encapsulate what exactly the user needs are and how to validate it through in-depth user research and user testing. These mistakes can be minimized by educating employees on the role of the UX designer. [51]

3.2.2 Time gain for product discovery and user research

According to [51], the aim of product discovery is to identify what the product is, what the user’s goals are and what functionality is necessary to achieve these goals. However, user research can be extremely time consuming and is often neglected or left out. By validating user requirements through actual user research with real users it minimizes the possibility of wrong functionality and feature requests being implemented and increases the possibility of a user-centered end product. [51]

37 Related work

3.2.3 Incremental and Iterative design

Users are often unable to articulate what they need so working in increments allows for slices of functionality to be built and evaluated from sprint to sprint. Feedback from the previous sprint can be factored into future sprints. [51]

3.2.4 Sprint zero

Following on from the product discovery stage, [51] suggests reserving a sprint zero to allow for designers to create and identify a suitable design concept from the start.

3.2.5 Designers work one sprint ahead

Brhel et al. suggest UX designers should work one sprint ahead of development to conduct research and prepare designs for the next sprint. This is done such that adequate research and conceptualization of features can be explored in parallel to development. [52] Sprints can be worked forward by developers and designers negotiating together regardless of role, by asking and answering questions, keeping each other informed of decisions and involving each other in decision making [51].

3.2.6 Inclusion of artifacts

The inclusion of user stories is helpful to describe user features and document progress. Personas, and scenarios are examples of conceptualizations of user needs. Prototypes, wireframes, and mock-ups are extremely useful for communicating designs between cross functional teams. Furthermore, from a design , having a central design record for documenting design goals, decisions made, and results helps to achieve a cohesive design. [52]

3.2.7 Day to day success

Ferreira et al. [53] propose that successful integration of UX design into Agile Software Development on a day-to-day basis should rely on practices that support and maintain four principles: mutual awareness, expectations about acceptable behavior, negotiating process and engaging with each other.

38 Related work

3.2.8 Team collaboration

Another vital part of integrating UX into a software development process is a well- structured and balanced team. Usually a tea comprises of individuals with different skill sets from design and development working together on one project. [52]

3.3 SUMMARY

In the Chapter 3 we have discussed the basic terms and design methodologies of user experience design. We considered software development methodologies and took a deeper look at design development processes. Finally we discovered the variety of UX design maturity models and focused our attention on the model created by Nielsen.

Changing organizational goals involves incorporating new values into the software development process and services equation by putting the focus on users. When product and service development cycle changes, an organization begins to think about the design of products with users in the center of the process developing the UX maturity of the company. The company should actively involve the users into the discovery and research phases, through design, development, and support. In the process of UX maturity growth, the organization should understand that users are the most important variable to achieving their business goals.

39 Analyses

4 ANALYSES

In this chapter we analyze the user interface development processes in the software development cycle at Robotron. In Section 4.1 we introduce the company Robotron as well as three of its software products, which we selected for this master’s thesis. In order to gain insights into the user interface development process at Robotron, we conducted a survey with Robotron employees. In Section 4.2 we describe the methodology of this survey. Finally, in Section 4.3 we discuss the survey results in detail. The results of this analysis will help us measure the user experience maturity based on the UX maturity model developed by Jakob Nielsen in the next chapter.

4.1 PRESENTATION OF ROBOTRON DATENBANK- SOFTWARE GMBH

Robotron Datenbank-Software GmbH (Robotron) is a German software company founded in 1990. Robotron is headquartered in Dresden, Saxony. The company specializes on the analysis and evaluation of large data sets. Robotron develops enterprise software, namely individually designed database-supported information systems. One of the markets where Robotron received a high recognition is the energy market.

In May 2017 Robotron has more than 400 employees and a yearly turnover of more than 36 million Euro. Robotron Datenbank-Software GmbH is an international company. It has subsidiaries, branches and offices around Germany, Austria, Switzerland, Czech Republic and Russia. Customers all around Europe use the software developed by Robotron.

Robotron Datenbank-Software GmbH divides its range of services into three basic business units: Energy Industry, Industry and Public Services. Furthermore, Robotron offers Service, Support and individual software solutions for its customers. The company

40 Analyses owns a certified training center. Training programs by Robotron are divided into two main topics: Training in Oracle and training in Energy Industry.

For conducting this research, we have chosen three products of Robotron Datenbank- Software GmbH, namely Robotron Energy Market Suite, in particular, robotron*ecount, robotron*Webportal 2.0 and robotron*Daphne.

4.1.1 Product overview

Figure. 14 Overview Energy Market Suite [54]

Robotron*ecount is a software product developed and supported by Robotron. It is one of the main components of the Robotron Energy Market Suite designed for all purposes in energy industry management. The product completely covers all functional demands of grid operators in the energy industry. The system is designed in a modular way, represents an integrated landscape and covers all relevant market processes.

“robotron*ecount serves as central data hub. Load curve data and meter states of different media types and periods are imported and checked for plausibility. Furthermore, it serves for the creation of substitute values if the occasion arises. Data is made available to respective processes (balancing, etc.) or to authorized market participants.” [54]

41 Analyses

Figure. 15 Start screen of robotron*ecount [54]

All functional modules of robotron*ecount are based on a central EDM core. Figure 14 shows the Robotron Energy Market Suite. Further products of Robotron Energy Market Suite are based on that EDM core as well. These are robotron*ecollect belonging to Advanced Meter Reading and robotron*esmart included in Smart Metering as well as robotron*esales belonging to EDM for marketing and procurement under consideration of regulatory bundling.

Figure. 16 Mobile version of the user interface of robotron*webportal [54]

42 Analyses robotron*Webportal 2.0 is the part of the EDM Systems of Robotron Datenbank-Software GmbH. The main focus of the software is the access to the load and counter data. The web portal offers a variety of combinable module configurations for the representation of various processes in the energy industry. In addition to standard functions such as consumption analyses, the formation of key figures, target monitoring, mapping of location or organizational structures, EDM sales processes can also be called and executed via the web portal. robotron*Webportal 2.0 is a responsive browser application that works on desktops as well as on tablets and smartphones.

Figure. 17 User interface of robotron*Daphne [54]

robotron*Daphne is a software product developed by Robotron. robotron*Daphne is the software for database management of museums and collections of all kinds. It allows the capturing and management of art objects, their , manuscripts, 3D-models, animations, videos and documentations. The goals of this software are efficiency, organization and clarity in the management of a very large number of art objects. Besides that, it also serves as an exhibition management tool. robotron*Daphne@WEB enables the management staff at museums and exhibitions to post chosen pictures of the art objects to the interactive web presentation for users all around the world. Figure 17 presents an example screenshot of the robotron*Daphne software. [54]

4.2 SURVEY

The first step of the research is the analysis of the user interface development processes. The representation of the software development process should be based on

43 Analyses

objective information. Conducting a survey is an unbiased approach to decision-making. We can collect unbiased survey data and get an impression about the real state of the software development process based on analyzed results and make an objective stocktaking of the process.

4.2.1 Preparation of the survey

Robotron is a big software company with self-developed software products as well as many individual projects and services. As mentioned in Section 2.3, large software companies may apply diverse software development models in different projects. It can be possible that various software products are managed simultaneously. Moreover, the user interface design methodology may also vary depending on the project. To be objective and unbiased in the definition of the user interface development process, it makes sense to make a confined choice of products and then analyze their processes independently from each other based on the data obtained with the survey.

4.2.1.1 Choice of the software products

Because of the diversity and high number of projects managed by Robotron, we decided to concentrate only on software products which have been developed and are maintained by Robotron itself. To gain more information and a deeper understanding of the processes of the company, we have talked to the product managers of seven products. In detail, these were robotron*ecount, robotron*ecollect, robotron*esales, robotron*Webportal 2.0, robotron*SEA, robotron*Daphne and the funds management software. Then we selected three main products for the further consideration: robotron*ecount, robotron*Webportal 2.0 and robotron*Daphne. We have already introduced these in Section 4.1.

4.2.1.2 Choice of the survey participants

The survey aim is to reproduce the interface design process at Robotron Datenbank- Software GmbH. Based on the gained information, we want to define the level of UX- maturity of the company. Therefore, the best target group for the survey is the lead management of the software products, because they have the strategic overview knowledge of all the processes of the software development cycle. The target group consists of six people. To gain as much information as possible from such a small target group, a survey in form of an interview including open-end questions is most suitable.

44 Analyses

4.2.1.3 Definition of the survey

As next we want to get a deep understanding of how the user interface development is integrated into the software life cycle of Robotron Datenbank-Software GmbH. The clear definition of the company’s processes will give many answers to the questions and will help measuring the level of UX design maturity. The questionnaire for the interview is divided into the following three parts.

The first part consists of the questions regarding the procedure and management of the software development process in the product development team, in particular regarding the interface design process, its organization, roles and the internal communication of the employees. To be able to evaluate the design process at Robotron, the standard or “perfect” design process needs to be defined. (see Section 2.2 [11]) The design process describes not only the phases, but also the design and evaluation methods to apply for each section of the design process. In addition, the questions concerning design deliverables between the client and Robotron as well as methods applied were a part of the survey as well.

While the first part of the survey provides us with deep insights into the UX design processes, roles and design deliverables at Robotron, to measure the design maturity of the company, much more information has to be gained. For example, information about the availability and planning of the budget for user interface design activities plays a very important role in the definition of the UX maturity stage. That is why the second part of the survey consists of the key questions about the company that define the UX level of the company’s maturity, based on the maturity model of Jakob Nielsen [40].

The last part of the survey is focused on the recognition of the improvement potential and the collection of first ideas for the future concept development. This part of the interview consists of a few open-end questions. These should collect work process insights and provide a deeper understanding of the daily problems and needs of the management stuff in the user interface development process. It should provide their personal opinion and give a general understanding of what the user experience design for Robotron employees is.

A copy of the survey questionnaire as well as all interview protocols are attached to this master’s thesis.

45 Analyses

4.2.2 Interview Process

After we created the survey, the series of interviews was scheduled within two weeks. The interviews were conducted without any problems. The management of the company was very open for questions and gave helpful, honest and fully formulated answers. Only one problem was recognized during the interviews. Because of the complexity of the software development process and functional diversity of the software products, it was almost impossible to clearly split the design process phases.

4.3 EVALUATION OF THE SURVEY RESULTS

Robotron uses the V-Model XT [8] as the fundamental software development model. In the following, we focus only on the interface design process. As mentioned in the previous section, for the survey we have chosen three products developed and maintained by Robotron. Next, we describe the results of the survey for each product. The survey has shown that all three products are developed and managed by different teams, so that the software development cycle is completely different in each case. That is, there is no centralized design process.

Consequently, we will gradually present survey results for each of three chosen software products. Section 4.3.1 considers robotron *ecount, Section 4.3.2 robotron *webportal 2.0 and Section 4.3.3 robotron *Daphne. The structure of all three sections is organized uniform. Namely, first the employee roles are described and compared for each of the products. Next we define and visualize the development process for each product.

4.3.1 robotron*ecount

4.3.1.1 Definition of the employee roles in the interface development process

The series of interviews outlined the software development process at Robotron and revealed the absence of a clearly defined user interface design process. The software development process is managed by the employees and each employee has a role that forms the process. That is why, for the description of the survey results, we begin with an explanation of the key roles of the software development process at Robotron.

46 Analyses

Project manager

A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, procurement and execution of a project. At Robotron Datenbank-Software GmbH, a project manager controls the project phases, writes offers, supervises clients, and is responsible for the coordination and administration.

Consultant

A consultant is a professional who provides expert advice in a particular area. The consultants are professionally trained by Robotron. They are responsible for professional advice regarding the products, product presentation and workshops. They record requirements from the customer and they are responsible for customer communication and the conceptualization of the infrastructure and the user interface of the software.

Marketing Department

In general, the marketing department is responsible for the coordination, selection and development of a product, the determination of its price, and the selection of a distribution channel to reach the customers. It works on development and implementation of a promotional strategy as well. In the chain of the user interface development process at Robotron, the marketing department is responsible for the consistent look of the software as well as graphical deliverables such as icons and the definition of a style guide.

Software Developer

The software developer designs the system to match the requirements of the consultants and implements the software feature.

Tester

A tester is an employee who tests the functionality of the new software product. In the Robotron energy industry product family the tester tests the implemented software focusing on functionality and the requirements of the customer. The tester is not supposed to test the usability of the software or the conformity with the style guide.

Customer

In the process described in the following, the customer is the one who sends the order. This can be a client, an external institution from the energy industry or Robotron itself.

47 Analyses

4.3.1.2 Intern teams

The roles are being combined and formed into intern teams that are responsible for some specified tasks:

Specialist team

The specialist team at Robotron is a group of professionals in different areas: professional consultants and developers. The team analyzes the customer requirements and decides about the features that have to be implemented. The team defines the task lists and assigns the tasks to the responsible employees.

Layout team

The layout team consists of the three to four employees of diverse departments, as well as marketing department employee, who helps create graphics and takes parts in the discussions of the concept development.

4.3.1.3 Overview design process of robotron *ecount

The derived design process at Robotron, namely the communication with the client, can generally be described as shown in Figure 18. Their communication can be abstractly described as follows. An inquiry in the form of a new order, bug report or policy change is sent from the client to Robotron. The result is sent in the form of the finished software or a concept file from Robotron to the customer. At this stage, the customer or the order- giver can be a client, an external institution that defines guidelines for the energy industry or Robotron itself. The client is not directly involved in the design process. Thus, at this moment, the end-user is not positioned in the center of the process, so no official user- centered design takes place.

48 Analyses

Figure. 18 Overview participants and communication robotron *ecount

4.3.1.4 Derivation of the design process of robotron *ecount

This section outlines the process of user interface design at Robotron and introduces the tasks that are typically associated with each role of the software development process. Figure 19 depicts the roles, deliverables and relations between them.

The consultant, specialist team and layout team can be generally grouped to consulting. The consultants communicate with the specialist team and the layout team. Based on that, they create a comprehensive text file for the software concept that includes the description of the software functionalities, its infrastructure, technologies used and some sketches with first ideas regarding the user interface. The software concept should be approved and signed by the customer for the software to go to the next stage of development.

After the client has approved the concept, the software goes directly to the implementation stage. The concept is split into single tasks. Single tasks or “tickets” (green arrows in Figure 19) are assigned to responsible front-end developers and then gradually implemented. After the developer has implemented the task, the layout team reviews the software user interface implemented by the developer. In the process of user interface implementation, the layout team is available for specific questions and advice concerning user interface implementation. The marketing department delivers graphics and icons for style guide conformity. Before the software is delivered to the customer, a

49 Analyses

software tester will test the implemented feature. More precisely, he or she tests its functionality and conformity to the customer requirements.

Finally, at the current user interface process at Robotron, most user-interface and user- interaction design decisions are made by developers and supported with feedback by the layout team.

The description of the design process reveals that design of the user interface is not considered systematically. All consultants work in different ways and there is no standardized wireframes delivery or user testing integrated into the development process. No iterative design process occurs.

4.3.1.5 Design deliverables and style guides

A style guide is a set of standards for the design of a software product. Usually a style guide is represented in the form of a text document, presentation or a bunch of articles. A style guide defines the look of the UI elements and color collections for the product. Furthermore, it specifies spacing and intervals between objects. In the case of the Energy Market product family by Robotron, there is a style guide that defines all necessary colors and styles for the developers to use.

50 Analyses

Figure. 19 of the design process robotron *ecount

51 Analyses

4.3.2 robotron*Webportal 2.0

4.3.2.1 Definition of the employee roles in the interface development process

In the case of robotron*Webportal 2.0, the roles of the user interface development process are equal to the roles of robotron*ecount. The only difference in the roles overview is the role customer. Despite the fact that the customer is still the network operator, the end users of the web portal are not only the professionals of the energy industry. Some modules of robotron*Webportal 2.0 are created for ordinary consumers and simple households.

4.3.2.2 Overview design process of robotron*Webportal 2.0 robotron*Webportal 2.0 is the second release of this software. It was completely redesigned and implemented using new technology. So, the user interface has been completely redesigned as well. The derived design process at Robotron, namely the communication between the client and Robotron can generally be described as shown in Figure 20. An inquiry in the form of a new order or a bug report is sent from the client to Robotron. The result is sent from Robotron to the customer in the form of the finished software or a concept file. The client is not directly involved in the design process. The design is not user-centered. The third participant of the design process of robotron*Webportal 2.0 development was an external design service provider. An external company created special design deliverables for Robotron at the beginning of the software development. The third participant of the process is depicted in Figure 20 as well. The design provider created the graphic concept of the user interface of the web portal. In the development cycle of the user interface the external design provider worked with wireframes and delivered screen designs for the development team. Finally, the external design team created some reusable code snippets for developers. This fact has determined the layout, colors and design of all reusable UI elements. This allowed to raise the quality of the design of the user interface and relieved the developers from many design decisions.

52 Analyses

Figure. 20 Overview participants and communication robotron *Webportal 2.0

4.3.2.3 Derivation of the design process of robotron*Webportal 2.0 robotron*Webportal 2.0 belongs to the Robotron Energy Industry Software Product family and basically has an equal software development process. The key difference is that the developers of robotron*Webportal 2.0 are not provided with the support of the layout team. So, they are able to freely decide about the user interaction and UI elements used in the feature implementation. However, some complex design tasks are outsourced to the external design provider. Figure 21 presents the web portal development process. There is no user testing and no iterative process is implemented into the software development process.

4.3.2.4 Design deliverables and style guides robotron*Webportal 2.0 does not have an official style guide. However, this software has a lot of other design deliverables that define its design guidelines, such as screen designs and reusable software code snippets.

53 Analyses

Figure. 21 Visualization of the design process robotron *Webportal 2.0

54 Analyses

4.3.3 robotron*Daphne

4.3.3.1 Definition of the employee roles in the interface development process

In the case of robotron*Daphne, the roles of the user interface development process are not equal to the roles of robotron*ecount and robotron*Webportal 2.0.

Here, the product manager communicated the product vision and design from the customers to the development and implementation teams. His responsibility was the strategy, roadmap, and feature definition for that product. Customers of the product are museums and collections of all kinds.

The consultant of robotron*Daphne is an employee who provides expert advice. In comparison with robotron*ecount the role of the consultant of robotron*Daphne does not include any design process tasks, like conception planning or creation of wireframes. Instead, these tasks were carried out by the product manager.

The customer was in the center of the development process and constantly provided the team with feedback. Thus, the customer played a huge role.

4.3.3.2 Overview design process of robotron*Daphne

The derived design process of robotron*Daphne, namely the communication between the client and Robotron, can generally be described as shown in Figure 22. An inquiry, in the form of a new order, a bug report or a feedback is actively exchanged in the communication process between the client and the Robotron team. The client was directly involved in the software design process and shaped the result. This fact is shown in Figure 22 as a loop, showing design iterations. robotron*Daphne has many customers, but not all of them were actively involved in the software design process. This kind of design process was chosen due to the high importance of the usability of the developed software to one big customer. Active communication and complete involvement of the client in the software development shaped by one customer helped achieve great software usability results.

4.3.3.3 Derivation of the design process of robotron*Daphne

The default used software development model is the V-Model XT [8]. However, after the survey and analysis of the development process, we can assume that the

55 Analyses

robotron*Daphne development team unintentionally applied another development model, with many iterations or even a mix of software development models.

Figure. 22 Overview participants and communication robotron *Daphne

The user interface development in this case involves fewer participants than in other products’ development teams. As described, the role of the consultant and product manager in this case differs from the energy industry product family development team. The UI development process of robotron*Daphne is represented in Figure 23. The active involvement of the customer in the design process is shown with the dashed line, representing the partial transparency of the design process to the customer.

4.3.3.4 Design deliverables and style guides robotron*Daphne has an official style guide in the form of a presentation and its own corporate design.

4.3.3.5 Prototyping techniques

For the following concept development and design maturity classification, it is important to know what kind of prototyping techniques are used in the current design process at Robotron. The survey showed that development teams often use sketching techniques for internal design communication. Moreover, some consultants in the energy industry team and the product manager of robotron*Daphne create wireframes so they can better explain the task for the developer or discuss the task with the customer. However, there

56 Analyses is no particular employee at Robotron who is responsible for user interface design as well as interaction or prototype testing exclusively.

Figure. 23 Visualization of the design process robotron *Daphne

57 Analyses

4.3.4 Conclusion of the survey results

One of the challenges faced by UX practitioners is integrating user experience best practice methods into the existing software processes. The conducted survey has outlined the design process of Robotron Datenbank-Software GmbH and gave us a deeper understanding of the daily challenges in the software development lifecycle. During the interviews we recognized the following problems in the current software development process that negatively influence the quality of the UI design. The very high complexity of the software and the absence of a centralized design make it difficult to keep the software user interface modules consistent. The concept development and feature definition is developed by many employees and rarely discussed in a large team. This fact provides a great distinction between the concepts being developed. The absence of a standardized mock-up and wireframes design procedure hinders the consistency between the files the developer uses for the implementation.

The consultants create a large concept document for the customer. The document describes the software’s functional requirements. It consists of just around three hundred pages. The developers have access to the concept file. However, the concept file is just too large and does not always describe the implemented software in detail. This makes it difficult for the developers to see the whole picture of the software that has to be implemented.

Robotron Energy Market Suite is a very large software product. It takes the largest part of the development capacity of the company. As described before, the design process involves a layout team that reviews the UI problems and meets for discussing the consistency of the UI design. The rare meetings of the layout team and the absence of full time employees working on UI topics make it difficult to track the constant improvements of the UI.

The development process at Robotron is not user-centric, exceptionally if the customer insists on the involvement in the process, like with robotron*Daphne.

4.3.4.1 Potential for improvement

When we carried out the interviews with the colleagues at Robotron, we asked a lot of open-end questions about personal opinions, problems, needs for a change and ideas for improvement. Involving a designer as well as a stable collaboration between a developer and a designer was the first and consistent wish of the employees who took

58 Analyses part in the survey. Consequently, that would mean an integration of a UI and UX designer into the development process. The consistency in the UI design development, like making consistent mock-ups and possibly screen designs for the clear task definition of the developers has been a common wish of the development team at Robotron.

As mentioned in Section 3.2, design education for the employees of the product development, especially for designers and developers, who implement the defined ideas into the software, plays a crucial role in the comprehension and appreciation of design as a science. Organizing design workshops for developers and teaching the basics of design principles could help the UI quality improvement as well.

During the communication with the employees, we had the impression that there is a strong focus on graphical design rules for developers. For example, the color definition and all details the finished graphical design includes, like exact spacing values between the elements. A very slight or maybe even feeble focus on the interaction workflow and the procedure of functionality design in order to perform a defined task by the user has been obvious. The interviews showed that there is a need to put more value on usability and maybe less focus on exact graphics measures of the used elements.

Despite the fact that Robotron does not have a centralized development process with a design team involved, almost every product of Robotron has a style guide that every developer must follow. At the moment, testers do not verify if the UI requirements are fulfilled by the developers. It would be a very good idea to involve a tester in the software UI design process. Following the expert-based evaluation method described in Section 2.2.3.2, the tester could take a reviewer role and check the state of the usability and if the style guide requirements have been fulfilled.

Another obvious problem in the UI design process, more precisely in the implementation phase of the software development cycle, are technological limitations and barriers. Sometimes the technology does not allow the implementation of all required features in the best way and does not allow the highest and most intuitive UI design quality. Therefore, some colleagues had the idea to start the redesign project of the product all over again and to build the new release of the software with the use of a new technology.

59 User Experience Maturity Classification

5 USER EXPERIENCE MATURITY CLASSIFICATION

The goal of this master’s thesis is to find a solution on how we can increase the user experience design maturity of Robotron Datenbank-Software GmbH. Before we can develop a concept, we need to analyze and outline Robotron’s level of maturity. Therefore, in this chapter we measure the actual level of UX design maturity of Robotron Datenbank-Software GmbH. As mentioned in Section 3.1.3, Nielsen’s UX maturity model can be divided into three main levels. With the help of the information gained in the interviews, we now gradually check step-by-step at which level and stage of the UX model by Nielsen Robotron currently stands. In Section 5.1 we start with the low design maturity level. After that, in Section 5.2 we continue with the middle design maturity level. Then, in Section 5.3 we consider the high design maturity level. Finally, in Section 5.4 we draw conclusions from the classification. There we will derive the change potential, more precisely, which level of design maturity we can achieve next as well as a list of changes that our concept should cover.

5.1 ANALYSIS OF ROBOTRON DATENBANK- SOFTWARE GMBH AT THE LOW UX MATURITY LEVEL

As descried in Section 3.1.3, the low UX maturity level consists of three stages:

• Stage 1: hostility towards usability

• Stage 2: developer-centered user experience

• Stage 3: stunkworks user experience

At the low UX maturity level, the values of the key points at each stage are completely different. The main variables the levels differ in are:

• importance of user-centered design at the company

60 User Experience Maturity Classification

• existence of a user interface in the developed software

• availability of funding for user experience design

Next, we analyze Robotron’s values of the variables at each stage of the low maturity level.

5.1.1 Importance of user-centered design at the company

The importance of user-centered design changes from stage 1 to stage 3 and varies between the absolute absence of user-centered design development and the first understanding of its relevance for the software development company. The research survey results have shown that Robotron Datenbank-Software GmbH has already achieved all three stages of this variable. That is, the company has recognized the importance of user-centered design and took actions for improvement.

5.1.2 Existence of a user interface in the development cycle

Stage 1 of the UX design maturity model can be characterized with the full absence of a user interface in the software. The stages 2 and 3 show the presence of the user interface that is developed exclusively by developers and a few more random employees in stage 3. The product research has shown that the software products chosen for this research have a very complex user interface design. The development of all chosen software products by Robotron involves many roles that work not only on the functionality of the back end, but also on the front end design and graphics. According to that, we can conclude that this variable has also been completely fulfilled by Robotron at the low UX maturity level.

5.1.3 Availability of funding for user experience design

A company at the low level of UX maturity is not supposed to have a planned funding for UX design. In exceptional cases, some ad-hoc activities are carried out at stage 3 of the low level of the UX design maturity model. The research showed that Robotron Datenbank-Software GmbH has a small planned funding for some promising products developed in the company. That means that this variable is fulfilled at the low level of UX maturity as well.

61 User Experience Maturity Classification

5.1.4 Conclusion of the low maturity level analysis

The information gained in the survey and the analysis of the low UX Maturity level has proved that Robotron Datenbank-Software GmbH has achieved all stages at the low UX maturity level and is actually located at a higher level in the UX design maturity model. Therefore, we can continue the analysis of Robotron Datenbank-Software GmbH at the middle UX design maturity level.

Figure. 24 Low User Experience (UX) Maturity level

62 User Experience Maturity Classification

5.2 ANALYSIS OF ROBOTRON DATENBANK- SOFTWARE GMBH AT THE MIDDLE UX MATURITY LEVEL

The middle UX maturity level is described by the next three stages of the UX design maturity model, namely:

 Stage 4: dedicated UX budget  Stage 5: integrated user-centered design  Stage 6: systematic user-centered design

The middle UX design maturity level has five variables that distinguish the stages from each other:

 recognition of user-centered design in the company  planning of UX activities  usability budget  UX design employees  design development process

5.2.1 Analysis of the shift to stage 4: dedicated UX budget

The transitions between the stages of the middle UX maturity level are presented in Figure 25. The green circles flag the variables at stage 4 that correspond to the current state of Robotron. Let us explain the variables in detail. As it was mentioned in the analysis of the low level of the UX maturity, Robotron Datenbank-Software GmbH has recognized the importance of user-centered design. This fact was obvious according to the interviews run before this analysis. So, the company has realized the need for user- centered development and started actions for improvement. Many consultants of the product development department stay in touch with the clients and give their best to meet all the requirements of the client.

Let us move to the next variable at stage 4. The careful planning of UX activities at Robotron is indicated by two facts. Firstly, the company hired an external design provider for the user interface design of robotron*Webportal 2.0. Secondly, there is an internal organization of meetings of the group of employees called “layout team” in the product development of Robotron Energy Market Suite. At these meetings, the participants are supposed to discuss the most urgent and complex topics regarding the user interface

63 User Experience Maturity Classification

design. The layout meetings take place upon need. These facts illustrate the next two variables of stage 4 as well. Namely, the availability of a small UX-budget, which was mentioned in the survey interviews too. The availability of the employees, who randomly work on topics concerning the layout of the application was proven too. There are no full- time UX design employees at Robotron. So, all UX tasks are processed by random employees, usually, these are developers, consultants and product managers. This fact matches the value of the variable “UX Design” employees at stage 4 of the middle UX Maturity.

The next and the last variable that we are going to prove at stage 4 is the “design process”. Robotron has no systematic user-centered design process. The implemented software is tested by the tester and then delivered to the customer. That means that real user testing happens late in the implementation process. So, this value of the variable “design process” matches stage 4 of the middle UX maturity as well.

The analysis of the shift from stage 3 to stage 4 has shown, that all the variables at stage 4 match the actual status of Robotron Datenbank-Software GmbH. So, we can conclude that the minimum stage Robotron has achieved at the moment is stage 4 of the middle UX design maturity model.

5.2.2 Analysis of the shift to stage 5: Integrated User-Centered Design

Let us take a look at the transition between the stages 4 and 5 in the middle UX design maturity level, presented in Figure 25. The blue arrows show transitions where the changes between two variables take place. It is obvious that the first two variables at stage 5 stay constant. The third variable requires the presence of a usability budget, but at this point the budget might be allocated only for promising big projects. The UX maturity model does not define the amount of money supposed to be allocated for the budget at each stage. According to the description of the variable by Nielsen and the interview results, we can conclude, that this variable might match the actual status of Robotron Datenbank-Software GmbH as well.

Stage 5 expects the company to create an official UX group led by the UX manager. A systematic UX process does not take place at stage 5, but the current design process is supposed to be applied more consistently. That is, the changes between the stages 4 and 5 are not critical. The main change that happens at stage 5 is the presence of the official UX team. At the moment there is no official UX team at Robotron. Thus, for Robotron to move to the stage 5 the creation of an official UX team is required.

64 User Experience Maturity Classification

5.2.3 Analysis of the shift to stage 6: systematic user-centered design

After analyzing stage 5 let us move on and take a look at next stage 6. The transition from stage 5 to stage 6 is presented in Figure 25. First, it is obvious that the variable “UX employees”, namely the presence of an official UX group stays constant at stage 6. That is, Robotron does not meet the requirements for this variable at this stage, since it has not been fulfilled at stage 5.

The other four variables at stage 6 are different than at stage 5. The survey showed that none of these four variables meet the actual state of the design process at Robotron. More precisely, at the moment there is no official user-centered design process and no process for tracking user experience. Moreover, currently the company neither allocates a stable usability budget nor applies an iterative design process.

5.2.4 Conclusion of the middle UX maturity level analysis

The analysis of the middle UX maturity level has shown a clear potential for the improvement of Robotron in the UX maturity model. More concretely, it is realistic for Robotron Datenbank-Software GmbH to gradually move to stage 6, if the following requirements will be fulfilled:

 Launch of an official user-centered design process  Employment of field studies and user experience tracking  Allocation of a stable usability budget  Foundation of an official UX group  Establishment of an iterative design process

This list of the discovered steps for Robotron to move to stage 6 of the middle UX maturity will be considered as a goal to achieve with the concept presented in Chapter 6.

65 User Experience Maturity Classification

Figure. 25 Middle User Experience (UX) Maturity level

66 User Experience Maturity Classification

5.3 ANALYSIS OF ROBOTRON DATENBANK- SOFTWARE GMBH AT THE HIGH UX MATURITY LEVEL

The high UX maturity level consists of the following two stages:

 Stage 7: Integrated User-Centered Design  Stage 8: User-Driven Corporation

These two stages are presented in Figure 26. Here the decisive variables are the same as in the middle UX maturity level. At stage 7, the company is supposed to have an official user-centered design process as well as a stable usability budget. The main characteristic of the high UX maturity level is the existence of quantitative usability metrics to be applied on released software. That means that the company should create a user tracking software and follow the user activities for the refinement of the user experience of the software product. The user data should influence each software development lifecycle.

Stage 7 definitely has the potential to improve the usability of the software by Robotron. However, the way to achieve this stage for Robotron in a short period of time is not realistic at the moment because of the high financial costs and the fact that the company and its employees first need to get used to the changes required for the completion of the middle UX maturity level. Achieving stage 7 can become a good potential goal, after Robotron has moved to stage 6. This step will shift Robotron to the completion of the middle UX maturity level. After the establishment and stabilization of iterative design processes at the middle UX maturity level, it will be potentially possible to develop software on the high level of UX maturity.

67 User Experience Maturity Classification

Figure. 26 High User Experience (UX) Maturity level

68 User Experience Maturity Classification

5.4 CONCLUSION OF THE CLASSIFICATION OF ROBOTRON UX MATURITY

For the accomplishment of the UX maturity analysis, the most important data about the software development process has been obtained through the series of interviews. Based on this information, we visualized the design process by Robotron, defining all the design deliverables and roles involved in the process. This gained knowledge gave us the possibility to analyze the UX maturity level of Robotron Datenbank-Software GmbH.

The actual level of the UX maturity of Robotron corresponds to the middle level of UX maturity. Robotron stands confidently at stage 4 in the UX-maturity model developed by Jakob Nielsen. The first steps to be taken by Robotron on the way to the next level were detected in this analysis as well. So that showed the realistic improvement potential for the completion of the middle UX maturity level moving to stage 6 in Nielsen’s model.

On the way to achieve stage 6 the following requirements have been identified:

 Launch of an official user-centered design process  Employment of field studies and user experience tracking  Allocation of a stable usability budget  Foundation of an official UX group  Establishment of an iterative design process

In the next chapter, we will develop a concept which maximally fulfills the requirements defined above.

69 Concept Development

6 CONCEPT DEVELOPMENT

In the previous chapter we have derived five requirements to fulfill in the concept that we are going to develop for Robotron Datenbank-Software GmbH to move to stage 6 of Nielsen’s UX-maturity model.

 Launch of an official user-centered design process  Employment of field studies and user experience tracking  Allocation of a stable usability budget  Foundation of an official UX group  Establishment of an iterative design process

As the next step on the way to the concept development we are going to consider all five topics and gradually implement them into the concept.

6.1 OFFICIAL UX GROUP

As determined in the previous chapter we need to consider the definition of an official UX group. The UX group is responsible for the following tasks. Each task can be carried out by the group of employees, defined by the management of Robotron. Each group may become a cluster of one UX design team. The following clusters can be defined:

 Interaction Design  Visual Design  User Research  User Assistance  Design Consulting

70 Concept Development

6.2 INTERACTION DESIGN

As described in Section 2.1.8, the interaction designer should be able to design interactive digital products, environments, systems and services. The team should explore how the user might interact with a product, test the prototypes at an early stage of development and make decisions regarding the behavior of interactive elements, functionality and design efficiency of the .

6.3 VISUAL DESIGN

Visual design is the use of imagery, color, shapes, , and form to enhance usability and improve the user experience (see Section 2.1 for more information). The UX team in the conception of this master’s thesis should be able to solve the problems of visual design. They should be able to work on the form, emotion, color and consistency of the product. The UX team in the cluster of visual design should be responsible for the design guidelines of the software products. A visual design contact person should be responsible for the emotional design of the software and the joy of use.

6.4 USER RESEARCH

User experience cannot exist without users. Creating user interfaces involves intricate and complex decisions. User research is a tool that can help the company achieve its goals. Even the most well thought out designs are assumptions until they are tested by real users [55]. Different types of research can answer different types of questions. Knowing the tools and applying them accordingly should be the responsibility of the user research cluster. The user research team could employ methods such as surveys, focus groups or usability testing.

6.5 USER ASSISTANCE

The user assistance developer or content strategist is a person who provides information to help a user to interact with the software. This can include describing the user interface, but he or she also focuses on how to help the user to best apply the software capabilities to their needs. The UA developer works with user stories and workflows of the software, error messages, notices and uniform button names. For the UX team to deliver great design work and keep the user interface consistent, the user assistance development should be a part of their official design process.

71 Concept Development

6.6 DESIGN CONSULTING

Despite the fact that the UX team is supposed to take the responsibility for all user experience design tasks, so that the software developer receives a clear and consistent design of the feature, the software developer still plays an important role in the whole design process, as he or she should implement the design and bring it to life. That is why it is very important that software developers have basic , like basic principles of design and layouting. This will facilitate the communication of the software developer with the UX team. Furthermore, it will give developers the ability to make the right design decisions on their own, for example regarding small layout problems. In the design process of this concept the UX team is available for questions concerning the delivered designs. The design competence of software developers can be achieved through seminars or workshops. These workshops may even be organized by the UX team themselves.

6.7 FIELD STUDIES

One of the most valuable assets of a successful UX design team is the information they have about their users. [56] When teams have the right information, the job of designing a powerful, intuitive, easy-to-use interface becomes tremendously easier. Spoon writes that when the team rely only on personal opinion, every little design decision becomes a struggle [56]. Tracking the user experience and organization of field studies is the requirement we defined for Robotron to move to stage 6 of the UX design maturity model developed by Nielsen.

With each study, the UX team can gain new insights into how customers behave, giving them invaluable knowledge on how they should design interfaces for use. Spoon assumes that field studies are one of the most expensive techniques to implement, but he is confident that the value the studies return is tremendous. Spoon and his design team never had an experience of wasted time and resources. A quality six-day study produced enough information to keep a design team busy for months. [56] The results from a successful set of field studies will feed directly into information architecture, workflows, use cases, and requirements for the project.

Moving to the next UX design maturity stage and organizing field studies will bring the Robotron UX design team the following advantages:

 Understanding the terminology of the end users

72 Concept Development

 Processes that the customer uses  The context of the work executed with the software product  Similarity and differences of the same types of the customers

Users cannot describe activities that they do not focus on [56]. When the design team has an audience that is experienced at what they do, they often do not pay attention to the small steps involved. An outside observer will see these “unspeakables” and can document them in ways that the participants cannot [56]. These details will make the user experience feel natural and well considered.

6.8 STABLE USABILITY BUDGET

The UX team development requires the company not only to build the new structure of the design process, but also to allocate the budget that will keep the UX team occupied.

6.9 OFFICIAL USER-CENTERED DESIGN PROCESS

In the Section 4.3 we defined the actual design process for three software products by Robotron. We have recognized that there is no official user-centered design process and all product development teams work their own way using different design processes.

To move to stage 6 in the UX design maturity model, Robotron should consider the integration of an official user-centered design process into its software development life cycle.

We have defined that Robotron needs a centralized solution for launching a UX design team. We have determined the spectrum of tasks and areas that the UX design team would be responsible for. Next, we are going to integrate the UX design team into the actual design process at Robotron.

There are three possible types of task scales:

 Mini task: this kind of UX task may include the integration of a small element into the user interface, a text description change or any other user experience task that does not require a complete redesign of the changed UI element.  Average task: the middle UX task could be an extension of a software feature or redesign of a UI element, such as a menu bar.  Complex task: a complex UI task would be a redesign of a feature as well as the development of a complete new design of the software.

73 Concept Development

Next, we are going to present two concepts of the new Robotron design process. One concept represents a simplified solution that may be applied for the resolution of mini tasks and average design problems. Another concept represents the complete new solution of the design process of Robotron to resolve a complex design problem.

6.9.1 Simplified solution

Figure 27 presents the first solution. Next, we describe how the process is supposed to happen and how is it different to today’s design process at Robotron.

For the concept development, the basic processes of Robotron Energy Market Suite were taken as the base. Thus, all the changes we develop could be integrated into the existing processes as they have been functioning up to now.

The first part of the development process at Robotron stays as it was. After the project was started by the project manager or the customer sent the inquiry, the request is discussed and processed in the consulting department. The consultants and the specialist team define a task, which is internally called a “ticket”. In the old development process, the ticket goes directly to the development team. This is exactly the moment when the UX team should become active. That is, the task description or the ticket should be sent to the UX team first.

After the UX team received the ticket, the team makes a decision about the next steps on the way to the implementation. As shown in Figure 27, the UX team develops a visual and interaction concept of the task. The UX team delivers a uniform conception and description of the solution that should be implemented.

6.9.1.1 User testing in the UX design process

To make the official design process user-centered, it is very important to collect the users’ feedback and understand the users’ needs at each stage of the development. However, it is not always possible to make field studies and complex surveys for each UI solution. The UX team of Robotron should integrate easy and fast early prototype testing into the design process of the UX team. This can be realized by collecting a fast feedback through a Skype conference. The contact persons for testing and feedback in this case can be a selection of customers who are available for this kind of help.

Robotron has a large training center for their software. The lecturer of the training courses could also actively take part in the testing process of the UX team, as they have

74 Concept Development a very close contact to the end users, so they know the real problems in their learning process, as well as their workflows. In Figure 27 the testing process is depicted by arrows.

6.9.1.2 Team structure

The UX team in this case should be responsible for a minimum of two major tasks. First, it is the user interface design and second, it is the user interaction design. In Figure 27 those task fields are marked as teams (UI-Team, Graphic-Team). The employee structure of Robotron is built the way that each employee may be reserved for all kinds of tasks. Therefore, the teams shown in Figure 27 are not supposed to consist of different employees, but both teams of UI design and graphic design may include the same team members and call some other employees for specific tasks when required. An important point is that there must be a key UX group that works on main UX tasks, so that all the concepts are consistent.

75 Concept Development

Figure. 27 New centralized design process medium/small scale problem

6.9.2 Complex task solution

The complete solution of the design process at Robotron for designing the range of complex tasks or complete redesigns of the software, like the release of a major update, is presented in Figure 28.

In Figure 28 the structure of the UX team in a complex UX task is presented. In large parts, this process is equivalent to the simplified UX design process. However, the main

76 Concept Development difference of these two processes is that the complex task is going to be worked off from two more perspectives. First, the user assistance development is a very important part of the complex user interface development. This field is responsible for the consistent creation of texts, uniform names, notices and error messages that are correctly written for each of the user groups. Second, complex user interfaces, especially the new releases of the software, which have already been in use for years, should be based on user research. A deep understanding of user needs will definitely not only help correct mistakes of the old software interface, but also to avoid new mistakes.

6.9.3 Process accompaniment and design consultation

After the UX design team created a visual and interaction concept, tested it with the users and employed the feedback of the lecturers, they send the extended ticket to the developers. The UX team should be available for questions, feedback and comments of developers communicating and supporting the correct implementation of the user interface concept.

6.9.4 Check list for software testing

After the UX design team developed the concept and developers implemented the solution, the ticket is forwarded to the tester. Besides functional testing, the tester receives a check list from the UX team with the UI/UX requirement and details that must be tested and observed. The tester will check, if all UI requirements have been implemented the way described in the check list. At this point, the UX team is available for questions from testers as well.

77 Concept Development

Figure. 28 New centralized design process large scale problem

78 Concept Development

6.10 ITERATIVE DESIGN PROCESS

In the previous chapter, we have defined the five requirements to be fulfilled for Robotron to move to stage 6 of Nielsen’s UX maturity model. Then, we have gradually created the concept, which step-by-step fulfills these requirements. The last step on the way to the completion of the middle UX design maturity level is the integration of an iterative design process into Robotron’s software design cycle. To describe more precisely, there must be a strategic iterative design methodology that the UX team should follow when developing good user interface design.

The Agile Manifesto [36] emphasizes people and interactions over processes and tools. In practice, this means communicating frequently both within teams and with the customer. This mostly takes the form of iterations, short, intense periods of production with smaller, more achievable goals. This concept of agile development perfectly suits the needs for the UX design development at Robotron. In an age of constrained finances, companies are more reluctant than ever to commit to big design projects without a thorough understanding of their chances of success. Google has developed a methodology to make the design process fast and allow the creation of valuable results (for detailed information of the Google UX design methodology see Section 2.2.2).

A draft of the iterative process is shown in Figure 29. The design development occurs in sprints. The classical Google methodology supposes one sprint to last for five days. Depending on the complexity of the task as well as on the availability of the team members the duration of one sprint can be defined.

6.10.1 UX team requirements

In order for the UX team to work according to this agile development concept, the following requirements should be available for the UX team. The functional requirements of the software should be accessible for the UX team as well as the full project concept file.

The UX design is an important aspect of making a website or application work. To provide the company with very good UX achievements, the relevant professional prototyping tools are required as well. For the low fidelity prototyping the team may need all kinds of color pencils, paper and sticky notes as well as a conference room for meetings and discussions. Tools for creating digital wireframes would also be very practical for documentation and discussions. To create high fidelity prototypes there are

79 Concept Development

a lot of professional tools available on the market. So, it is very important that the UX team has access to one of those tools to be able to create high fidelity prototypes for user testing.

As mentioned in Chapter 6, it would make sense to invite some dedicated clients as well as lecturers to take part in the testing phase of the UX design process. So, the UX team should have a list with contact data to be able to communicate with the clients for testing.

Figure. 29 Visualization of the iterative design process of the UX design team

In the following, we have a look at each of the five phases of Google’s iterative process again. However, this time we provide more details on how each phase can be carried out in practice.

6.10.2 Unpack

As described in Section 2.2.2, in the unpack phase, the team brings everyone together and discusses all the knowledge of the problem within the team. It is important to involve the whole team in the unpack event, as mentioned in [25]. The following efforts can be made at this meeting, according to [25]:

80 Concept Development

The team meeting may start with a presentation outlining why the feature presented is important to the business and why it is necessary for implementation.

Next, the demonstrations of the problem and any ideas of the solution that may already be available should be discussed. So, at the second iteration a detailed walkthrough of the proposed solution should be discussed at the meeting as well. Each team member is requested to provide a constructive feedback. User personas, use cases, and other methodologies, if relevant, may be discussed at this stage as well.

If the field studies have been conducted for the implementation of the feature, the analytical data available should be defined and included into the concept specification.

6.10.3 Sketch

The sketch phase is an individual effort [25]. Everyone in the team is tasked with coming up with a detailed solution to the problem. Low fidelity prototypes [30] suit these goals best. This solution should be presented in a form of a sketch. For particularly complex problem solving, the team should break up the problem into manageable parts and assign people a chunk rather than the whole problem. The aim of the sketch phase is to get as many ideas as possible and to reduce them at the end of the day to the most realistic and manageable ones. Then, the choice of sketches may be documented and saved in digital form as wireframes.

6.10.4 Decide

The decide phase is all about making a decision as to which idea the team is going to take to the prototype phase. At this phase, it is important to discuss how the created solutions may conflict with the objectives, abilities, resources or customers creating ideas to overcome conflicts. The team should be looking to constantly refine the list of ideas and remove ideas that are simply not feasible early in the process.

6.10.5 Prototype

At this stage, the decision made in the previous phase is designed in a prototype – a high fidelity prototype [30]. This kind of prototype is a computer-based interactive representation of the product in its closest resemblance to the final design in terms of details and functionality. The prototypes cover not only the user interface of the product

81 Concept Development

in terms of visuals and aesthetics, but also the user experience aspects in terms of interactions, user flow and behavior. Some of the top mobile and web software prototyping tools currently in the industry are:

 InVision [57]  Adobe XD [58]  Axure [59]

6.10.6 Test

User experience requires user involvement. At the last phase of the agile UX development cycle the team is supposed to bring the persons for testing together. The actual tests may be executed in the form of a Skype conference. This will help achieve a larger number of clients and will reduce the costs for testing. Most employees nowadays have a very busy day schedule, planning each minute of the work day. The client feedback through Skype conferences may help easy planning and keep meetings short and precise.

After the UX team has tested the prototype with the clients and discussed the solution with lectures, there are three possible ways to continue the development of the feature.

6.10.6.1 Success

If the prototype was successful and received few criticism and much praise in the testing phase, it can be forwarded to the software developer for the implementation. In this case, the UX team should create a clear and short, but detailed description of the functionalities and interface behavior that should be implemented by the software developer. This document can be created in the form of a check list. The UX team will provide the software developer with the last version of the tested prototype. After the software has been implemented, this check list will be forwarded to the tester for the further UI quality assurance.

6.10.6.2 Complete failure

In another case, the prototype may be criticized by the test persons. In the process of testing, it may become obvious that the tested UI solution has too many lacks or does not meet the expectations of the end users or support of the lecturers at all. In this case the UX team would begin the development cycle all over again, beginning with the

82 Concept Development

“unpack” phase and discussing the obvious problems as well as looking for another solution.

6.10.6.3 Refinement

At last, the created prototype may be successful enough but still need some refinements. In this case, the UX team would reiterate the last two stages of the UX design process. So, they would go back to the “prototype” stage and refine the prototype with the new knowledge they received during testing and then repeat the tests again.

6.11 SUMMARY

In Chapter 6 we have defined the goal for Robotron Datenbank-Software GmbH in UX maturity, more precisely, we have identified stage 6 in Nielsen’s UX maturity model. We defined the list of requirements that must be gradually integrated into Robotron’s software development cycle in order to achieve stage 6. These were: official user- centered design process, stable usability budget, official UX group, iterative design process, and user experience tracking and field studies.

The integration of the proposed concept will bring Robotron to the completion of the middle UX maturity level and will open the opportunity for the further development to the higher level of user experience design maturity.

The concept described in this chapter considers each of the requirements. It gradually develops conception of the solution so that all the requirements complement each other in one working solution.

The focus of the conception is the creation of the user experience team as well as using an iterative design process for UI design. The concept describes official process changes in the software development cycle at Robotron on the way to a better user experience design as well as the introduction and procedure of the agile user experience methodology to be applied by the new user experience team.

83 Concept Verification

7 CONCEPT VERIFICATION

Verification is the process of checking that a developed concept meets the requirements and that it fulfills its intended purpose. In our case we want to verify that the developed process can work out in the case of Robotron Datenbank-Software GmbH. More precisely, we verify the developed design process idea assuming that it has already been integrated into the software development cycle at Robotron.

7.1 CHOICE OF THE TASK FOR THE VERIFICATION – TICKET DEFINITION

We chose robotron*ecount as the real software product for this chapter. Understanding the complete workflow of robotron*ecount requires a qualified understanding of all the user requirements and problems of the energy industry. To work with the software the users get one week of basic training at the Robotron training center. Thus, because of the time limits, the issue we are looking for should not be content-oriented or too complex to become acquainted with.

Due to that, talking to the employees of Robotron and exploring the user interface as a novice user was the best choice to begin the analysis. Consequently, we have decided to work on a very first screen that each user faces after logging in, namely the main navigation screen of the software. In Figure 30 a screenshot of the start screen (navigation interface) is presented.

In the next section, first we inspect the user interface of robotron*ecount in order to identify first lacks of the UI. The inspection reveals some obvious problems of the user interface. After choosing a UI problem the team go through all five phases (Sections 7.1 to 7.5) of one iteration of the UX development process proposed in Chapter 6. We assume the UX team exists at Robotron and consists of two to five employees. We develop a suggestion how to correct the issues found in the user interface.

84 Concept Verification

7.2 UNPACK

At first glance, the user navigation of the software makes a nice impression. Big readable buttons of the navigation menu, colorful icons and a mild color palette make an impression of an easy to understand and pleasant user interface. However, if we look at the user interface in detail the following improvement potential can be recognized. In the following we focus on both, usability and graphical design issues.

Figure. 30 Start screen robotron *ecount

7.2.1.1 Position of the user in the navigation menu levels

The main navigation of robotron*ecount has a tree structure with a depth of four. The user has three possibilities to navigate through the menu: a search field, a mask overview window and the main menu navigation. While navigating in the main menu the user cannot follow the position inside the tree structure. Only the last node is displayed. This fact makes it difficult to determine the actual position of the user in the menu.

85 Concept Verification

7.2.1.2 Spread navigation elements

The software robotron*ecount is a very complex software application. The start screen of the product offers many possibilities for navigating through the system. On the right the user sees navigation windows. If all navigation windows are open, there is very little space for the overview so that each of the menus has to be scrolled.

There are four navigation bars in the user interface. The navigation bars are spread all around the window (right upper corner, left upper corner, left window etc.). This fact makes it difficult to explore and learn the user interface. Furthermore, the user’s mouse paths between two menus are relatively long.

7.2.1.3 Position of the elements robotron*ecount is a desktop application. Most elements of the software are typical desktop elements, such as navigation menus, tabs, etc., which are used in most desktop applications. Therefore, the user may expect the default positions of the navigation elements. For example, the window tabs in a browser or system window are normally located on the top of the window while in robotron*ecount the elements are located on the bottom of the window.

7.2.1.4 Closing the window

Another example of the navigation element, which could potentially be positioned better is the window closing button. Clicking on a red button in the upper right or the upper left corner of the window can close every typical window in any modern operating system. However, the window closing button of robotron*ecount is located in a menu bar together with other functionalities. That makes it difficult for the user, especially for the novice user, to understand the system.

7.2.1.5 Navigation

As mentioned before the main navigation is very complex and it consists of many functions with a tree structure in the background. At first sight, the order of the elements seems to be random. A grouping of menu points belonging together is not recognizable. The menu is neither configurable nor individually customizable. The names of the menu items are not self-explanatory. There is a small explanation field at the bottom of the

86 Concept Verification window. When the user moves the mouse pointer over a menu item, this explanation field displays a help text. However, since the explanation field is located far away from the buttons it describes, the user’s sight must always jump up and down to connect the information on the button and its description in the information field.

7.2.1.6 Spacing between objects

The spacing between navigation elements is not always optimal. Sometimes it is too small (for example for the list elements in the navigation windows) and sometimes too big (for example the spacing between the main menu and the search field).

7.2.1.7 Typography

The size of the text seems to be too small. The typography for the labels of the buttons is not optimal as well. Changing the window size makes some button labels not fit into the fields. Therefore, the user has to enlarge the window in that case to read all the names of the buttons.

7.2.1.8 Graphics

The user interface of robotron*ecount uses professionally designed complex icons. All icons are very colorful and employ 3D effects. This makes a very pleasant impression. However, the icons are quite small. Furthermore, the icons are not abstracted to symbols, such that it may take time to recognize them and to understand their meanings.

7.2.2 State of the Art

In the previous step the list of problems that the UX team aims to correct with a new design suggestion has been described. Next, the team moves on to collect ideas for the improvement.

To explore ideas for and solve the problem of an intuitive menu navigation it is important to search for the most popular and successful applications with a similar level of complexity as robotron*ecount. In this context the idea of the interface metaphor is very useful. An interface metaphor is a set of user interface visuals, actions and procedures that exploit specific knowledge that the users already have from other domains. The purpose of the interface metaphor is to give the user instantaneous knowledge about

87 Concept Verification

how to interact with the user interface. Most users are used to often-used UI patterns that they recognize in many modern applications. It is interesting to figure out the similarities of the elements’ design, their position on the screen and the interaction principles in the applications. We have chosen the following applications for the research:

 Mac OS - is the current series of Unix-based graphical operating systems developed and marketed by Apple Inc. . Mac OS system window (Figure 32) . Mac OS Notification Center (Figure 37)  Windows 10 - is a personal computer operating system developed and released by Microsoft . Start Menu – (Figure 36)  Evernote – a popular software for complex notes management, often used for project management (Figure 31)  Spotify – a music, podcast, and video streaming service (Figure 33)  Adobe Photoshop – a professional graphic software (Figure 35)  SAP Fiori 2.0 – SAP Fiori is a set of applications, newly written by SAP Software Solutions, that address the most broadly and frequently used SAP functions (for example workflow approvals). User-centered design concept by SAP Flori focuses on the way employees work, SAP design team assumes. (Figure 34)

In the following, we have a look at common interface concepts of these applications.

7.2.2.1 Main navigation bar

As displayed in Figures 31 to 34 the main navigation bar with the most important functions that aims to find and open information the user searches for is always located on the left. The information in these navigations has a tree structure as in robotron*ecount. The navigation bar can be opened and closed according to the wish of the user.

88 Concept Verification

Figure. 31 Start screen Evernote

7.2.2.2 Information division

It is obvious that the screen is divided into three parts: the navigation menu, the main working field and the third supplementary information field.

7.2.2.3 Tabs

In robotron*ecount, new windows are presented in the form of tabs, but the window tabs are located on the bottom of the window. As displayed in Figure 32 and Figure 33 the tabs or sliding navigation tabs in most applications are ordered at the upper edge of the window.

Figure. 32 Mac OS system window

89 Concept Verification

Figure. 33 Spotify - start screen

7.2.2.4 Configurable main menu – widgets

Many modern applications use widgets in a main dashboard of the user interface. That is a small application with limited functionality. The widgets present quick links or system state visualisations. They are arranged in tiles on the user dashboard. Examples of the dashboard widgets are presented in Figures 34 and 36. This makes the user interface individually configurable, customizable and flexible.

Figure. 34 SAP Flori start screen - dashboard overview

90 Concept Verification

Figure. 35 Adobe Photoshop - window and tool bar

Figure. 36 Windows 10 – start menu

7.2.2.5 Notification center

In Figure 37 an example of a notification center of Mac OS is presented. The notification center is located on the right side and can be closed easily. The right side menu panel can be used for presentation document and notifications management - supplementary information fields, that aim to inform the user or somehow provide quick help.

91 Concept Verification

Figure. 37 Mac OS – Notification center – supplementary menu on the right

7.2.2.6 Design and Graphics

Most of the modern applications use the principles of flat design. Flat design draws the attention of the user to the essence of the content. The 2D appearance of flat design icons makes them look clean and simple to understand. The icons bring the user to the main point of the content. Instead of working on complex 3D graphics and effects, flat design has a big color and font styles playground. By eliminating unnecessary styling, flat design is able to provide pleasant user experience [2].

In the “unpack” phase of the design sprint the team have collected possible ideas for solving the problems of the navigation menu of robotron*ecount. We investigated how other modern software products solve similar UI problems. Next, we move on to the “sketch” phase.

7.3 SKETCH

In Figure 38 the results of the sketch phase are presented. First, we have defined the main working areas of the user interface. After that we have ordered the functions that belong together and defined UI elements for these features.

In the sketch phase the team have created several ideas of the solution to be able to compare and choose one sketch to take into the prototype phase.

92 Concept Verification

Figure. 38 Results of the sketch phase

7.4 DECIDE

In the decide phase the team need to analyze ideas generated and sketched in the previous phase and choose one proposed solution. The team agree that the view consist of the following three parts:

• Navigation • Main view • Supplementary navigation

7.4.1.1 Navigation

The main navigation gives the user an overview of all available functions of the software. The overview is presented in the form of a list view with foldable list items for the user to request information on demand. List items are alphabetically sorted in a field to provide fast visual search. The direct search function is located above the navigation overview and is supposed to offer search results suggestions while the user types.

93 Concept Verification

According to the information collected in the interviews with the employees of Robotron, the workflow of most end users of robotron*ecount requires the interaction with at least four views, so-called “masks”. In the current navigation view the masks are ordered on the bottom edge of the window.

Working with robotron*ecount the user should be able to switch between views quickly. To reduce the number of navigation bars and to shorten the user’s mouse paths, the UX team decided to integrate the view switch into the navigation panel. That will provide fast and intuitive access to all the masks at one place. To summarize, all the masks can be managed, that is, found, opened and closed at the navigation panel.

The most challenging task is to provide the user with more space while working in the main working panel. To achieve this, the user should be able to fade out the navigation panel to create free working space, but still be able to switch between frequently opened masks.

7.4.1.2 Main view

On the start screen’s main view panel, the UX team decided to provide the user with a configurable, customizable dashboard panel. There are two main spaces on the dashboard: fast links and widgets (system states). Additionally, each user can organize groups of his or her favorites and place them on the dashboard. The dashboard organized in tiles. Per drag and drop the user can change the order of the elements or replace the tiles content according to his or her personal needs. Beyond the start screen dashboard function the main view is supposed to display the current working mask.

7.4.1.3 Supplementary menu

In the right navigation panel of robotron*ecount there are three other panels: document management, favorites management and task management. The UX team decided to keep these functions in the supplementary menu panel. The order and choice of the design elements was taken from the discovered concepts described in the previous “unpack” phase, more precisely, the tabs location on the upper edge of the window (see Figures 31, 32 and 35) as well as the optional hide away function of the whole panel.

94 Concept Verification

7.4.1.4 Summary

In the “decide” phase the UX team has determined the function range, working panels and UI elements used for the user interaction. As the next step of the sprint, the team move into the “prototype” phase to create a high fidelity prototype.

7.5 PROTOTYPE

Meanwhile, the UX team have achieved the “prototype” phase. The team choose Adobe XD as the UX prototyping tool for the prototype creation. First, the UX team create screen views without applying any colors, namely using nuances of black and white. This technique gives a possibility to arrange the elements correctly on the screen concentrating on the elements’ positions, user interaction and functionality. Next, the team create high fidelity screens using the robotron*ecount corporate color palette. Results of both prototypes are presented in Figures 39 to 42.

95 Concept Verification

Figure. 39 Prototype: start screen – nuances of black and white

Figure. 40 Zoomed in prototype: menu closed – nuances of black and white

96 Concept Verification

Figure. 41 Prototype: all navigations opened – color version

Figure. 42 Prototype: all navigations closed – color version

97 Concept Verification

7.6 TEST

In the previous section the UX team has finished the “prototype” phase. Consequently, the next step is user testing with the goal to evaluate the ideas with real users and get helpful feedback. Because of the time limits for this master’s thesis, the phase could not been executed with real end users. Instead, user tests were executed with employees of the company. The following knowledge has been gained from the user tests. The novice user would like to work with the new modern software UI. However, the experienced user, who got used to the old interface design, would find it difficult to get used to it.

The individual configuration of the menu was found very useful and promising. The only question was to identify and to bound the number of functions for the dashboard as well as to differ the configurable dashboard and the favorites function. So the next step of the UX team would be to clarify and to bound the differences in functions as well as advantages and disadvantages between the dashboard and saving into favorites menu tab.

It might seem like the team have made a mistake. However, because of the agile iterative design process this is recognized very early after one sprint. That means that they did not waste much time for the complete implementation of the new design. The team learns from the feedback of the users and get better with the time.

7.7 SUMMARY

In this chapter the results of the process verification have been presented. We have assumed that the process described in this work has already been implemented into the software development cycle at Robotron Datenbank-Software GmbH. First, the choice of the problem and task definition was described and virtually sent as a ticket to the UX team. Following the iterative agile process concept suggested in Chapter 6, the UX team executed the first five-step iteration and produced the first proposal of the problem solution. The results of the first iteration are presented in Figures 39 to 42. After the analysis of the user feedback the team would go further to the second iteration to gradually improve the suggested solution.

98 Concept Verification

99 Conclusion and Outlook

8 CONCLUSION AND OUTLOOK

User Experience (UX) design is as important part of the software design process. UX involves designing an experience and planning a workflow for the software users. Nowadays the time is incredibly valuable, so the complex enterprise software systems are forced to focus on user experience, increasing efficiency, speed to achieve the user goal, system availability and intuition of user interaction.

UX maturity models describe the sequence of stages the organizations process on the way to improve user experience of their software. For this master thesis we have chosen UX maturity model developed by Jakob Nielsen. The model consists of 8 stages describing the UX development from the complete absence of UX to the UX driven organization. We have grouped the stages on three main levels: low, middle and high maturity.

The focus of the master thesis was to analyze the design processes of the German software company based in Dresden Robotron Datenbank-Software GmbH, derive the actual level of companies UX maturity and to develop a suggestion for its level improvement. Based on the information gained from the conducted survey in form of interviews we could conclude that UX maturity of Robotron Datenbank-Software GmbH matches the level four in the Nielsen’s UX maturity level. However the analysis showed that Robotron has a realistic potential to move to the level six of the UX maturity model. Consequently the gaps to achieve the level six have been defined in order to include them into the later solution development. Creation of a centralized UX team in the company, iterative design development process, field studies and UX budget were the main gaps to fulfill on the way to achieve the level six of Nielsen’s UX maturity model. Based on that, a suggestion on integrating UX team into the today’s software development cycle of Robotron has been developed. While analyzing the UX team workflows and task spectrum, we have determined that the agile iterative design development method created by Google best suits the concept.

100 Conclusion and Outlook

To verify developed ideas for the solution, a real UI problem of the software product has been chosen for a test iteration pretending the UX team would exists. All five stages of the design process has been executed and ended up with a small interactive high fidelity prototype.

The last test phase of the iteration has shown good results and potential for successful usability improvement. To achieve better results and to gradually integrate UX into the Robotron’s development cycle the verification phase on a small project and real small UX team would be the next step to accomplish on the way to the level six of UX design maturity. It could be challenging to get the UX team together and to achieve the best results quickly. Due to this, at the beginning of the integration UX team may need more iterations, clear communication, team members’ mutual support and constructive feedback of the test users.

101 Bibliography

BIBLIOGRAPHY

[1] J. N. Don Norman, „Evidence-Based User Experience Research, Training, and Consulting,“2017. [Online]. Available: https://www.nngroup.com/articles/definition-user-experience/.

[2] P. Hußmann, „User-Centered Development Process,“ Ludwig-Maximilians- Universität München, Munich, 2017.

[3] J. Gube, „What Is User Experience Design? Overview, Tools And Resources,“ Smashing Magazine, 2010.

[4] C. Seffah, „Human-Centered Software Engineering - Integrating Usability in the Software Development Lifecycle,“ Springer, 2005.

[5] J. Nielsen, „Usability 101: Introduction to Usability,“ Nielsen Norman Group, 2012.

[6] J. Rubin und D. Chisnell, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, 2nd Edition, John Wiley & Sons, Inc., 2008.

[7] Microsoft Corporation, „Usability in Software Design,“ 2000. [Online]. Available: https://msdn.microsoft.com/en-us/library/ms997577.aspx.

[8] Association of Modern Technologies Professionals, „Software Development Methodologies,“ IT Knowledge Portal, 2017.

[9] D. Norman, Emotion & Design: Attractive things work better, Interactions Magazine Hrsg., San Francisco, 2002, p. 36–42.

102 Bibliography

[10] M. Rouse, „Information Design,“ Tech Target, 2005.

[11] Tutorialspoint, „Software User Interface Design,“ 2017.

[12] Krzywinski, „TECHNISCHES DESIGN , DESIGNENTWURFSPROZESS,“ Dresden University of Technology, Dresden, 2016.

[13] J. Nielsen, „Disruptive Workflow Design,“ United States, 2012.

[14] K. Courage, Understanding your users: A practical guide to user requirements - Methods, tools, & techniques., M. Kaufmann, Hrsg., San Francisco, 2005, p. Chapter 13.

[15] W. Lidwell, K. Holden und J. Butler, Universal Principles of Design, Rockport Publishers, 2010, p. 182.

[16] UX Booth, „Complete Beginner’s Guide to Information Architecture,“ 2017.

[17] J. Gress, Visual Effects and Compositing, San Francisco: New Riders, 2015.

[18] M. Angeles, „Wireframes,“ 2009. [Online]. Available: http://konigi.com/glossary/wireframes/.

[19] I. D. Foundation, „The Glossary of Human Computer Interaction,“ 2017. [Online]. Available: https://www.interaction-design.org/literature/book/the- glossary-of-human-computer-interaction/mock-ups.

[20] C. Snyder, Paper Prototyping: the fast and easy way to design and refine user interfaces, San Francisco: Morgan Kaufmann, 2003.

[21] Meera, „Evaluation: What is it and why do it?,“ 2017.

[22] PIDOCO: Powerfull Prototyping, „Iterative Design,“ Germany, 2017.

[23] Interaction Design Foundation, „Design iteration brings powerful results. So, do it again designer!,“ Aarhus, Denmark, 2017.

[24] Google Ventures, „The Design Sprint,“ Google Ventures, 2016.

[25] Interaction Design Foundation, „Make Your UX Design Process Agile Using

103 Bibliography

Google’s Methodology,“ Interaction Design Foundation.

[26] S. R. Purohit, „Introducing Google’s Design Sprint Process in Product Design,“ UDACITY, 2015.

[27] A. Dillon, „Usability evaluation, In W. Karwowski (ed.) Encyclopedia of Human Factors and Ergonomics,“ Taylor and Francis, London, 2001.

[28] J. Nielsen, „Heuristic evaluation,“ John Wiley & Sons, New York, 1994.

[29] J. R. C. L. &. P. P. Cathleen Wharton, „The Cognitive Walkthrough Method: A Practitioner's Guide,“ John Wiley & Sons (New York), Colorado, 1994.

[30] K. Pernice, „UX Prototypes: Low Fidelity vs. High Fidelity,“ Nielsen Norman Group: Evidence-Based User Experience Research, Training, and Consulting, Fremont, California, United States, 2016.

[31] D. Wolfgang Zuser, Softwaretechnologie fuer Einsteiger, Munich: Pearson Studium, 2010.

[32] B. W. Boehm, „Guidelines for verifying validating software requirements and design specifications,“ TRW, Redondo Beach, 1979.

[33] BUNDESREPUBLIK DEUTSCHLAND 2004., „V-MODELL® XT,“ http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.1-eng/Dokumentation/pdf/V- Modell-XT-eng-Teil1.pdf, 2004.

[34] C. M. a. T. Crawford, „Joint Apllication Development,“ IBM Canada, Canada, 1974.

[35] J. Martin, Rapid Application Development, Macmillan, 1991.

[36] Kent Beck, „Manifesto for Agile Software Development,“ Agile Alliance, Snowbird, Utah, United States, 2001.

[37] D. Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams (Agile Software Development), 2004.

[38] B. Charette, „Lean Development,“ 1993.

104 Bibliography

[39] P. C. Jeff De Luca, „Feature Driven Development,“ 1997.

[40] J. Nielsen, „Corporate UX Maturity: Stages 1-4,“ Nielsen Norman Group: Evidence-Based User Experience Research, Training, and Consulting, Fremont, California, United States, 2006.

[41] J. Nielsen, „Corporate UX Maturity: Stages 5-8,“ Nielsen Norman Group: Evidence-Based User Experience Research, Training, and Consulting, Fremont, California, United States, 2006.

[42] J. Sauro, „How Do You Measure UX Maturity?,“ MeasuringU, 2017.

[43] J. Earthy, „Usability Maturity Model: Human,“ Information Engineering Usability Support Centres, 1997.

[44] P. H. By Bruce D. Temkin with Harley Manning, „Experience-Based Differentiation,“ Forrester, 2007.

[45] R. H.-S. Robert Ballantine, „THE JOURNEY To a Customer Centric Business,“ Infosys.

[46] V. U. E. D. Scott Plewes, „A UX Maturity model for companies seeking competitive advantages,“ Macadamian Technologies.

[47] The Design Management Institute (DMI), „Measuring the Value of Design,“ 2014.

[48] Danish Design Centre, „The Design Ladder: Four steps of design use,“ Denmark, 2015.

[49] S. Anderson, „Seductive Interaction Design: Creating Playful, Fun, and Effective User Experiences (Voices That Matter),“ Poet Painter, L.L.C, USA, 2011.

[50] Artefact Group, „Design Maturity Survey: From Self-Assessment to Action,“ https://www.artefactgroup.com/articles/design-maturity-survey/.

[51] N. O'Donoghue, „Integrating UX Design methodologies into software development,“ Medium, 2016.

105 Bibliography

[52] Brhel, „Exploring Principles of User-Centered Agile Software Development: A Literature Review.,“ Information and Software Technology (61), 163–181., 2015.

[53] J.Ferreira, „Agile Development and User Experience Design Integration as an Ongoing Achievement in Practice,“ Agile Conference, 2012.

[54] Robotron Datenbank Software GmbH, „Portfolio und Branchenlösungen,“ [Online]. Available: http://www.robotron.eu/businessunits/energyindustry/robotronenergymarketsuite/e dmnetwork.html

[55] Benutzer:Guenson, „Wikipedia,“ 23 November 2011. [Online]. Available: http://de.wikipedia.org/wiki/Benutzer:Guenson/Bilder.

[56] T. Dresden, Innovation hat Tradition, Dresden: Verleger, 2011, p. 1 ff..

[57] W3C and Education and Outreach Working Group (EOWG), „Notes on User Centered Design Process (UCD),“ Web Accessibility Initiative (WAI) , 2006.

[58] H. Loranger, „UX Without User Research Is Not UX,“ United States, 2014.

[59] J. M.Spool, „Field Studies: The Best Tool to Discover User Needs,“ UIE, Chattanooga, TN, 2016.

[60] InVision, „InVision: Software prototyoing tool,“ https://www.invisionapp.com/.

[61] Adobe, „Adobe Experience Design CC,“ http://www.adobe.com/de/products/experience-design.html.

[62] Axure, „Axure: software prototyping tool,“ https://www.axure.com/.

[63] M. Stephen Richards, „The Use of Metaphors in Iconic Interface Design,“ Taylor Francis Online , 2009.

[64] http://www.fltdsgn.com, „7 Benefits of Flat Design ,“ fltdsgn, 2016.

106 List of Figures

LIST OF FIGURES

Figure. 1 Terms of user experience design [3] ...... 6 Figure. 2 Two systems of software development [2] ...... 8 Figure. 3 Linear design process [11] ...... 10 Figure. 4 Benefits of Google Agile UX design methodology [25] ...... 13 Figure. 5 Prototyping techniques [30] ...... 18 Figure. 6 An example of a low-fidelity prototype [30] ...... 19 Figure. 7 Stages of Waterfall model [32] ...... 21 Figure. 8 V-Model XT [33] ...... 22 Figure. 9 Stages of Jakob Nielsen maturity model ...... 28 Figure. 10 Overview User Experience (UX) Maturity levels ...... 30 Figure. 11 Low User Experience (UX) Maturity level ...... 32 Figure. 12 Middle User Experience (UX) Maturity level ...... 34 Figure. 13 High User Experience (UX) Maturity level ...... 36 Figure. 14 Overview Energy Market Suit [54] ...... 41 Figure. 15 Start screen of robotron *ecount [54] ...... 42 Figure. 16 Mobile version of the user interface of robotron *webportal [54] ...... 42 Figure. 17 User interface of robotron *Daphne [54] ...... 43 Figure. 18 Overview participants and communication robotron *ecount ...... 49 Figure. 19 Visualization of the design process robotron *ecount ...... 51 Figure. 20 Overview participants and communication robotron *Webportal 2.0 ...... 53 Figure. 21 Visualization of the design process robotron *Webportal 2.0 ...... 54 Figure. 22 Overview participants and communication robotron *Daphne ...... 56 Figure. 23 Visualization of the design process robotron *Daphne...... 57 Figure. 24 Low User Experience (UX) Maturity level ...... 62 Figure. 25 Middle User Experience (UX) Maturity level ...... 66 Figure. 26 High User Experience (UX) Maturity level ...... 68 Figure. 27 New centralized design process medium/small scale problem ...... 76 Figure. 28 New centralized design process large scale problem ...... 78

107 List of Figures

Figure. 29 Visualization of the iterative design process of the UX design team ...... 80 Figure. 30 Start screen robotron *ecount ...... 85 Figure. 31 Start screen Evernote ...... 89 Figure. 32 Mac OS system window ...... 89 Figure. 33 Spotify - start screen...... 90 Figure. 34 SAP Flori start screen - dashboard overview ...... 90 Figure. 35 Adobe Photoshop - window tab and tool bar, ...... 91 Figure. 36 Windows 10 –Start menu ...... 91 Figure. 37 Mac OS – Notification center – supplementary menu on the right...... 92 Figure. 38 Results of the sketch phase...... 93 Figure. 39 Prototype: start screen – nuances of black and white ...... 96 Figure. 40 Zoomed in prototype: menu closed – nuances of black and white ...... 96 Figure. 41 Prototype: all navigations opened – color version ...... 97 Figure. 42 Prototype: all navigations closed – color version ...... 97

108 List of Figures

109 Attachment

ATTACHMENT

Prototype Survey archive

110 n o i t a c i f i t o N … … … t t t e e e n t m ! m m l e l a a a a b

e a t t t t t g i i i i f s s s s s u r

r r r r i A e

n o o o o h l l l l e u c o o o o d J

u r d d d d

n a h u e r c t m i m m m m m m m w b r u

u u u u u u u u r o a g s s s s s s s s v e r a n p p p p p p p p v F i I i i i i i i b r

u r e n e m m m m m m m m s m v h r s e e e e e e e e s e c r r r r r r r r t a a a l e n o o o o o o o o e W A G R L L L L L L L L m u k o D m m m u u u s s s p p p i i i

m m m m m m e e e u u u r r r s s s o o o p p p L I L L i i m m m m u u u u s s s s p p p p i i i i

m m m m m m e e e e u u r r r r s s o o o o p p I L L L L i 1 2 m m m

u u u s s s e e p p p I i i p p

p p m m m m m m e e e e u u r r r r u u s s r r o o o o p p I L L L L I G G D R A O B H S A D m m m u u u s s s p p i p i i

m m m m m m m e e e e e e r r u r r r r s o o o o o o L L p L L L L i m m m m u u u u s s s s p p p p i i i i

m m m m m m m e e e e e e u r r r r r r s o o o o o o p L L L L L I L ! n m m m m e u u u u s s s s g p p p p i i i i n

m m u m m m m f e e e e e u r r r r r s o o p o o o p L L L L L i ü n k r e V

m m m m m s u e u u u u t s l s s s s l p p p p p e i i i i i

e g m m m m m m m n e e e e e e e d r r r r r r r i h o o o o o o o c L L L L L L L W S m e N t r n i E n

e e t e G g n g s t g i n N l n R r n e

u u a U E s e t u e r l s F r L p k e n g a r s e e i L i ü P g g N n i l l s n e

g g w s i n Ü Ü n e E h i l r u n e a ä t l n e n w u c u l a K e r r N z e n z a a r e z M s e t t t u n v t g S t i

t K e n u e r r d t n s e u e i a h n s i e n R A p A o e e k i i e a i z h c n m N D V E z z p e S S N Z V L V c V z n e j t t I M V u t r

u m a b e e L r l e s b E a i N G O N N t n

E N B A N S e

K

E k S

F s

A a

F

O

M M n o i t a c i f i t o N … … … t t t e e e n t m ! m m l e l a a a a b

e a t t t t t g i i i i f s s s s s u r

r r r r i A e

n o o o o h l l l l e u c o o o o d J

u r d d d d

n a h u e r c t m i m m m m m m m w b r u

u u u u u u u u r o a g s s s s s s s s v e r a n p p p p p p p p v F i I i i i i i i b r

u r e n e m m m m m m m m s m v h r s e e e e e e e e s e c r r r r r r r r t a a a l e n o o o o o o o o e L L L L L L L L W A G R m u k o D m m m u u u s s s p p p i i i

m m m m m m e e e u u u r r r s s s o o o p p p L I L L i i m m m m u u u u s s s s p p p p i i i i

m m m m m m e e e e u u r r r r s s o o o o p p I L L L L i 1 2 m m m

u u u s s s e e p p p I i i p p

p p m m m m m m e e e e u u r r r r u u s s r r o o o o p p I L L L L I G G D R A O B H S A D m m m u u u s s s p p i p i i

m m m m m m m e e e e e e r r u r r r r s o o o o o o L L p L L L L i m m m m u u u u s s s s p p p p i i i i

m m m m m m m e e e e e e u r r r r r r s o o o o o o p L L L L L I L ! n m m m m e u u u u s s s s g p p p p i i i i n

m m u m m m m f e e e e e u r r r r r s o o p o o o p L L L L L i ü n k r e V

m m m m m s u e u u u u t s l s s s s l p p p p p e i i i i i

e g m m m m m m m n e e e e e e e d r r r r r r r i h o o o o o o o c L L L L L L L W S m m m u u u s s s p p p i i i

m m m m m m e e e u u u r r r s s s o o o p p p L I L L i i m m m m u u u u s s s s p p p p i i i i

m m m m m m e e e e u u r r r r s s o o o o p p I L L L L i 1 2 m m m

u u u s s s e e p p p I i i p p

p p m m m m m m e e e e u u r r r r u u s s r r o o o o p p I L L L L I G G D R A O B H S A D m m m u u u s s s p p i p i i

m m m m m m m e e e e e e r r u r r r r s o o o o o o L L p L L L L i m m m m u u u u s s s s p p p p i i i i

m m m m m m m e e e e e e u r r r r r r s o o o o o o p L L L L L I L ! n m m m m e u u u u s s s s g p p p p i i i i n

m m u m m m m f e e e e e u r r r r r s o o p o o o p L L L L L i ü n k r e V

m m m m m s u e u u u u t s l s s s s l p p p p p e i i i i i

e g m m m m m m m n e e e e e e e d r r r r r r r i h o o o o o o o c L L L L L L L W S m e N t r n i E n

e e t e G g n g s t g i n N l n R r n e

u u a U E s e t u e r l s F r L p k e n g a r s e e i L i ü P g g N n i l l s n e

g g w s i n Ü Ü n e E h i l r u n e a ä t l n e n w u c u l a K e r r N z e n z a a r e z M s e t t t u n v t g S t i

t K e n u e r r d t n s e u e i a h n s i e n R A p A o e e k i i e a i z h c n m N D V E z z p e S S N Z V L V c V z n e j t t I M V u t r

u m a b e e L r l e s b E a i N G O N N t n

E N B A N S e

K

E k S

F s

A a

F

O

M M m m m u u u s s s p p p i i i

m m m m m m e e e u u u r r r s s s o o o p p p L I L L i i m m m m u u u u s s s s p p p p i i i i

m m m m m m e e e e u u r r r r s s o o o o p p I L L L L i 1 2 m m m

u u u s s s e e p p p I i i p p

p p m m m m m m e e e e u u r r r r u u s s r r o o o o p p I L L L L I G G D R A O B H S A D m m m u u u s s s p p i p i i

m m m m m m m e e e e e e r r u r r r r s o o o o o o L L p L L L L i m m m m u u u u s s s s p p p p i i i i

m m m m m m m e e e e e e u r r r r r r s o o o o o o p L L L L L I L ! n m m m m e u u u u s s s s g p p p p i i i i n

m m u m m m m f e e e e e u r r r r r s o o p o o o p L L L L L i ü n k r e V

m m m m m s u e u u u u t s l s s s s l p p p p p e i i i i i

e g m m m m m m m n e e e e e e e d r r r r r r r i h o o o o o o o c L L L L L L L W S Fragebogen 1

Entwicklungsprozess (Design Prozess)

Name: Axel Zernd

Funktion/Rolle: Projektmanager

Software-Produkt / Software-Lösung: SEA (Oracle, RDF Framework)

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Die Entwicklung wurde vor 2011 gestartet. Die Software wurde umgebaut.

Welche Hauptrollen gibt es im der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Berater: Kundenkontakt, Anforderungen aufnehmen, Konzept schreiben, Softwareschulungen. Berater sind fachlich aufgestellt.

Projektleiter: Steuert die Projektphasen, schreibt Angebote, betreut Kunden

Entwickler: Implementiert die Software

Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? ein Entwickler und ein Projektleiter, sowie Marketing. Marketing hat die Icons angefertigt, damit die Software die Einheitlichkeit besitzt.

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? Es ist schwer zu sagen, also vlt. 2%

In welche Hauptphasen war das Gesamtvorhaben unterteilt? Datenbankmodel, Entwurf. Migration alte-neue Software.

Wie viel Zeit wurde für jede Phase eingeplant? Kann ich nicht beurteilen.

Wurde von dem Zeitplan abgewichen und warum? Es gab keinen Zeitplan

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert? 2 Personen

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

Energieversorger, Netzbetreiber (Strom, Gas, Wasser)

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Management, interne Statistikführung (Assettmanagement)

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Ja

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Ja. Es gibt ein Berechtigungskonzept, Nutzerrollen sind konfigurierbar

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Nein. Es gibt eine Anweisung für Admin.

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Wir habe keinen Model bewust eingesetzt

Wurde es streng angehalten? Wenn es Abweichungen gab, warum?

Nein, wegen der Komplexität der Software und Diversität von den Kunden ist strenges Anhalten von den Rahmen ist sehr schwierig

Phasen Ich würde Ihnen empfehlen zu dem genauen Ablauf der Phasen die Berater zu fragen.

3.1 Analyse-Phase Fand eine Analyse statt? Ja

Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert? Welche oben genannte Rollen wurden in die Analyse-Phase involviert?

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Anforderungen-Liste, Scenarios) Datenmodel stand als Ziel im Vordergrund

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt? ja

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert? 2 Mitarbeiter

Welche oben genannte Rollen wurden in die Definitionsphase involviert? Alle 2

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt? Nein

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung) Konzeptbeschreibung

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt? ja

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert? Kann ich nicht genau sagen

Welche oben genannte Rollen wurden in die Entwurfsphase involviert? alle

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt? Jain

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Wireframes-Entwurf) Gemischt. Wir haben die Screenshots von der alten Anwendung genommen und für die Beschreibungen und Erklärungen der neuen Maske genutzt.

3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt? Gemischt mit dem Entwurf

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert? Kann ich nicht genau sagen Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert? alle

Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt? Gemischt mit der Entwurfs-Phase

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype)

Gemischt. Wir haben die Screenshots von der alten Anwendung genommen und für die Beschreibungen und Erklärungen der neuen Maske genutzt.

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert? Kann ich nicht sagen

Welche oben genannte Rollen wurden in die Implementierungsphase involviert? alle

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt? Ja

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? Nutzer-Oberfläche

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Wir haben die Screenshots von der alten Anwendung genommen und für die Beschreibungen und Erklärungen der neuen Maske genutzt.Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Keine

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Alle Konzepte und Beschreibungen

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Nicht bewusst Wie werden die Software-Erweiterungen entwickelt? ----

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Alle Konzepte und Beschreibungen

Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler Gibt es einen Style Guide für die Entwickler? Es gab kein Style Guide. Aber wir haben ein Framework genutzt, wo UI-Elemente schon vorgegeben. Außerdem haben wir die Vorgaben von Marketing verfolgt.

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Man könnte an die bestehende Lösungen und erfolgreiche Konzepte, die schon existieren sich orientieren. Sodass man nicht alles neu entwickeln muss.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Testphase hat 1 Jahr gedauert. Wir machen erst interne Tests, Lasttests, danach testen wir die Software bei den Kunden. Danach kamen die Anpassungen und Migration beim Kunden.

Werden die Usability Tests durchgeführt? Nein

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen? Es gibt kein Styleguide

Design Maturity Model

Wie wichtig finden Sie Usability von der Software?  1  2  3  4  5 Gibt es ein Design Team im Projekt? 1 Mitarbeiter- Projektmanager

Wie viele Teilnehmer sind in dem Team?

Welche Aufgaben werden von dem Team erledigt?

Wie werden die Aufgaben verteilt?

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Gibt es klare Rollenverteilung & Verantwortungen im Design Team?

Gibt es ein Design Teamleiter (Manager)?

Wie werden die Design-Entscheidungen getroffen?

Wird eine Strategie verfolgt? Wir versuchen das Interface einheitlich für den Nutzer zu machen

Wann wird von der Strategie abweicht? Und warum? Kann nicht beurteilen

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Nein

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? Der Nutzer muss schnell möglichst zu seinem Ziel kommen können und die Aufgabe schnell und erfolgreich lösen. Was kann man am Prozess nach Ihrer Meinung verbessern? Ich kann es nicht genau sagen. Das hängt stakt an den Daten und die Anforderungen.

Fragebogen 2

Entwicklungsprozess (Design Prozess)

Name: Christian Hofmann (ab 2008)

Funktion/Rolle: Leiter e-collect

Software-Produkt / Software-Lösung:

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Die Entwicklung wurde als Projekt gestartet. Die letzte Release 5 haben wir im Jahr 2011 angefangen. Erste Version haben wir im Jahr 2015 abgeschlossen. Die Software wird immer noch entwickelt.

Welche Hauptrollen gibt es im der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Berater: Kundenkontakt, Anforderungen aufnehmen, Konzept schreiben, Softwareschulungen. Berater sind fachlich aufgestellt.

Projektleiter: Steuert die Projektphasen, schreibt Angebote, Koordination, Administration

Entwickler: Implementiert die Software

Tester: Führt die Tests durch (Qualitätmanagement)

Außerdem gibt es ein Fachteam (Überprüfung der fachlichen Angemessenheit, Entscheidungen welche Funktionen müssen implementiert werden und welche nicht. Das Team besteht aus Berater und Entwickler) und ein Layoutteam (Überprüfung der visuellen Angemessenheit), die aus den Teilnehmer mit verschiedenen Rollen besteht.

KM-Verantwortlicher – Konfiguration-Management. Integration von der Software Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? 6 Entwickler, Berater

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? 1% bis max. 5%

In welche Hauptphasen war das Gesamtvorhaben unterteilt?

Ich kann es nicht genau beurteilen. Vlt. Analyse, Konzept und Umsetzung

Wie viel Zeit wurde für jede Phase eingeplant? Kann ich nicht beurteilen.

Wurde von dem Zeitplan abgewichen und warum? Kann ich nicht beurteilen.

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert? Kann ich nicht beurteilen.

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

Energieversorger, Netzbetreiber

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Fachkräfte, Sachbearbeiter in der Energie-Branche

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Ja

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Ja, es ist konfigurierbar.

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Ja. (3-5 Tage)

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Wir haben V-Model Extended angewendet. Scrum wenden wir nicht an, aber einige Agile-Methoden Wurde es streng angehalten? Wenn es Abweichungen gab, warum?

Nein

Phasen

3.1 Analyse-Phase Fand eine Analyse statt? Ja

Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert? Schwer einzuschätzen

Welche oben genannte Rollen wurden in die Analyse-Phase involviert? Fachteam

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt? Ja

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Anforderungen-Liste, Scenarios) Prozessbeschreibung

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert? Fachteam

Welche oben genannte Rollen wurden in die Definitionsphase involviert? Ja

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt? nein

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung) Konzeptbeschreibung

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert? Fachteam

Welche oben genannte Rollen wurden in die Entwurfsphase involviert? Fachteam

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein Welches waren die zentralen Ergebnisse bzgl. UI-Design? Entwürfe, Skizzen,

3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt? Nein

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert?

Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype)

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Implementierungsphase involviert? Insgesamt waren 13 Entwickler involviert. (Wir kaufen auch die Unterstützung von Extern), 6 UI-Entwickler. Jetzt arbeiten 2,5 Entwickler für UI.

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt? JA

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design?

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Skizzen

Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Dem Kunden werden die Zwischenstände nicht präsentiert, er bekommt Finekonzept.

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Keine

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Jain  Wie werden die Software-Erweiterungen entwickelt? Die Erweiterungen werden nach Kundenauftrag entwickelt. Der selber Entwicklungsprozess findet statt.

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Entwickler bekommt ein Ticket zugewiesen (von einem Berater oder Projektleiter). In dem Ticket wird die Aufgabe in Form einer Notiz beschrieben. Manchmal gibt es dazu Zeichnungen oder Bilder

Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler. Es wird in der Rücksprache mit Projektleiter entwickelt. Gibt es einen Style Guide für die Entwickler? Jain 

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Designer, der im Prozess unterstützen würde. Screen Designs wären auch hilfreich.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Ich kann es nicht genau beurteilen. Wir führen fachlichen Test durch, aber keine Lasttests. Continious Intergration findet statt, es wird ein konsistenter Zustand geprüft. Lasttests machen wir für automatisierte Komponenten.

Werden die Usability Tests durchgeführt? Nein, aber Usability Acceptance

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen? Der Tester guckt sich das nicht genau an. Wenn die gelieferte Leistung ein Fehler hat, wird der Ticket an den Entwickler zurückgegeben. Wenn Die Software-Lösung nur ein kleiner Bug oder Style Guide-Abweichung hat, dann wird ein Fehler-Ticket erstellt und dem Entwickler zugeordnet.

Design Maturity Model

Wie wichtig finden Sie Usability von der Software? Ich finde die Usability sehr wichtig. Aber man muss manchmal auf Kompromisse gehen und damit verbundener Aufwand ist nicht immer in der Praxis möglich.  1  2  3  4  5

Gibt es ein Design Team im Projekt?

Wie viele Teilnehmer sind in dem Team? 2 Kernteilnehmer und 3 zusätzliche Teilnehmer, die an der Entscheidung mitwirken

Welche Aufgaben werden von dem Team erledigt?

Prüfung der visuellen Eigenschaften der umgesetzten Softwarelösung, Review und das Layout-Team steht zur Interface-Fragen zur Verfügung

Wie werden die Aufgaben verteilt?

1-Grafikerin und eine Leiterin (Teilzeitaufgaben im Bereich Design)

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Es gibt kein Vollzeit Mitarbeiter, der sich nur mit den Design Themen beschäftigt

Gibt es klare Rollenverteilung & Verantwortungen im Design Team? nein

Gibt es ein Design Teamleiter (Manager)? ja

Wie werden die Design-Entscheidungen getroffen?

Wird eine Strategie verfolgt? Wir versuchen das Interface einheitlich für den Nutzer zu machen

Wann wird von der Strategie abweicht? Und warum? Kann nicht beurteilen

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Sehr gering

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? User Interface muss intuitiv und einfach sein. Aber man muss manchmal Kompromisse eingehen) Was kann man am Prozess nach Ihre Meinung verbessern? Entwickler sollte mehr Unterstützung bekommen. vlt. durch Bilder-Screendesigns oder Zusammenarbeit mit einem Designer

Fragebogen 3

Entwicklungsprozess (Design Prozess)

Name: Ines Hermel

Funktion/Rolle: Leiterin e-sales

Software-Produkt / Software-Lösung:

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Die Entwicklung wurde als Projekt gestartet. Die letzte Release 5 haben wir im Jahr 2011 angefangen. Die Software wird immer noch entwickelt.

Welche Hauptrollen gibt es im der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Berater: Kundenkontakt, Anforderungen aufnehmen, Konzept schreiben, Softwareschulungen. Berater sind fachlich aufgestellt.

Projektleiter: Steuert die Projektphasen, schreibt Angebote, betreut Kunden

Entwickler: Implementiert die Software

Tester: Führt die Tests durch (Qualitätmanagement)

Außerdem gibt es ein Fachteam (Überprüfung der fachlichen Angemessenheit) und ein Layoutteam (Überprüfung der visuellen Angemessenheit), die aus den Teilnehmer mit verschiedenen Rollen besteht.

Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? Rund 40 Berater (fachlich aufgestelt) und Layout Team (2 bis 5 Leute)

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? 10% Arbeitszeit Berater und 5% Review Layout Team

In welche Hauptphasen war das Gesamtvorhaben unterteilt?

Ich kann es nicht genau beurteilen. Vlt. Analyse, Konzept und Umsetzung

Wie viel Zeit wurde für jede Phase eingeplant? Kann ich nicht beurteilen.

Wurde von dem Zeitplan abgewichen und warum? Kann ich nicht beurteilen.

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert? Kann ich nicht beurteilen.

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

Energieversorger, Netzbetreiber

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Fachkräfte in der Energie-Branche

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Ja

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Ja, Jeder Kunde stellt die Nutzerrollen selber fest, also, theoretisch es gibt sehr viele mögliche Nutzerrollen.

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Ja. Es gibt ein 5-Tage-Grundlagenkurs, sowie weitere Schulungen je nach Komponente. (2-3 Tage)

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Nicht bewusst. Aber vermutlich sind wir nach dem Ansatz vom Wasserfallmodel vorgegangen. Außerdem gab es die Zeitabschnitte, wo moderne Agile-Methoden, wie SCRUM im Team-Organisation bei den Entwickler eingesetzt worden.

Wurde es streng angehalten? Wenn es Abweichungen gab, warum? Nein, wegen der Komplexität der Software und Diversität von den Kunden ist strenges Anhalten von den Rahmen ist sehr schwierig

Phasen Ich würde Ihnen empfehlen zu dem genauen Ablauf der Phasen die Berater zu fragen.

3.1 Analyse-Phase Fand eine Analyse statt? Ja

Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Analyse-Phase involviert?

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Anforderungen-Liste, Scenarios)

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Definitionsphase involviert?

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung)

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Entwurfsphase involviert?

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Wireframes-Entwurf) Konzeptbeschreibung 3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert?

Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype)

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Implementierungsphase involviert?

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design?

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Jeder Berater entscheidet selbst wie und mit welchen Tools er die Anforderungen aufschreibt und die Konzepte umsetzt. (Paint, VisualParadigm, MockUp Bilder oder ähnliches)

Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Dem Kunden werden die Zwischenstände nicht präsentiert, er bekommt Finekonzept. Der Kunde muss am Ende Finekonzept unterschreiben.

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Entwickler bekommt ein Ticket zugewiesen (von einem Berater oder Projektleiter). In dem Ticket wird die Aufgabe in Form einer Notitz beschrieben. Manchmal gibt es dazu Zeichnungen oder Bilder

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Nicht bewusst Wie werden die Software-Erweiterungen entwickelt? Die Erweiterungen werden nach Kundenauftrag entwickelt. Der selber Entwicklungsprozess findet statt.

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Entwickler bekommt ein Ticket zugewiesen (von einem Berater oder Projektleiter). In dem Ticket wird die Aufgabe in Form einer Notitz beschrieben. Manchmal gibt es dazu Zeichnungen oder Bilder

Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler Gibt es einen Style Guide für die Entwickler? Ja

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Aufgaben in Form einer Präsentation (Kurz und Knapp) Wenn der Entwickler einen Bild hätte, wäre er vlt. schneller.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Ich kann es nicht genau beurteilen. Maximal, in Form eines Reviews, oder exploratives Testen

Werden die Usability Tests durchgeführt? Nicht dass ich wusste

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen? Der Tester guckt sich das nicht an. Layout-Team übernimmt die visuelle Überprüfung.

Design Maturity Model

Wie wichtig finden Sie Usability von der Software?  1  2  3  4  5 Gibt es ein Design Team im Projekt?

Wie viele Teilnehmer sind in dem Team? 2 Kernteilnehmer und 3 zusätzliche Teilnehmer, die an der Entscheidung mitwirken

Welche Aufgaben werden von dem Team erledigt? Prüfung der visuellen Eigenschaften der umgesetzten Softwarelösung, Review und das Layout-Team steht zur Interface-Fragen zur Verfügung

Wie werden die Aufgaben verteilt?

1-Grafikerin und eine Leiterin (Teilzeitaufgaben im Bereich Design)

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Es gibt kein Vollzeit Mitarbeiter, der sich nur mit den Design Themen beschäftigt?

Gibt es klare Rollenverteilung & Verantwortungen im Design Team? nein

Gibt es ein Design Teamleiter (Manager)? ja

Wie werden die Design-Entscheidungen getroffen?

Wird eine Strategie verfolgt? Wir versuchen das Interface einheitlich für den Nutzer zu machen

Wann wird von der Strategie abweicht? Und warum? Kann nicht beurteilen

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Sehr gering

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? User Interface muss intuitiv und einfach sein. Aber man muss manchmal Kompromisse eingehen) Was kann man am Prozess nach Ihre Meinung verbessern? Entwickler sollte mehr Unterstützung bekommen. vlt. wäre es gut wenn der Tester über die Oberfläche drüber guckt.

Fragebogen 4

Entwicklungsprozess (Design Prozess)

Name: Martin Schöffer

Funktion/Rolle: Chef-Entwickler

Software-Produkt / Software-Lösung: Webportal - ecount

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Die Entwicklung wurde im Jahr 2015 gestartet. Bis zum ersten Release ist 0,5 Jahre vergangen.

Welche Hauptrollen gibt es im der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Berater: Kundenkontakt, Anforderungen aufnehmen, Konzept schreiben, Softwareschulungen. Berater sind fachlich aufgestellt.

Projektleiter: Steuert die Projektphasen, schreibt Angebote, Koordination, Administration

Entwickler: Implementiert die Software

Tester: Führt die Tests durch (Qualitätmanagement)

Außerdem gibt es ein Fachteam (Überprüfung der fachlichen Angemessenheit, Entscheidungen welche Funktionen müssen implementiert werden und welche nicht. Das Team besteht aus Berater und Entwickler)

Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? Wir haben eine externe Firma beauftragt uns ein Design-Konzept zu liefern. Da haben 3 Leute an dem Konzept mitgearbeitet. Bei Robotron wurden 2 Entwickler dafür eingesetzt. (Aber auch für alle andere Aufgaben)

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? 1% bis max. 5%

In welche Hauptphasen war das Gesamtvorhaben unterteilt?

Wie viel Zeit wurde für jede Phase eingeplant?

Wurde von dem Zeitplan abgewichen und warum?

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert?

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

B2B-Energieversorger, Netzbetreiber

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Fachkräfte, Sachbearbeiter in der Energie-Branche bis Endnutzer

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Ja, je nach Nutzerzielgruppe

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Rollenkonzept, beliebig zuordenbar

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Ja. Je nach Auftragsgeber

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Wir haben V-Model Extended angewendet. Scrum wenden wir nicht an, aber einige Agile-Methoden

Wurde es streng angehalten? Wenn es Abweichungen gab, warum?

Nein

Phasen

3.1 Analyse-Phase Fand eine Analyse statt? Ja Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert? 1 Mitarbeiter

Welche oben genannte Rollen wurden in die Analyse-Phase involviert? Alle

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt? Ja, grob diskutiert

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Anforderungen-Liste, Scenarios) Kurzes Dokument

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert? 1 Mitarbeiter

Welche oben genannte Rollen wurden in die Definitionsphase involviert?

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt? Ja, grob

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung) Konzeptbeschreibung

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert? Externe Firma

Welche oben genannte Rollen wurden in die Entwurfsphase involviert? Alle

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt? Ja

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? Wireframes

3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert? Externe Firma

Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert? Externe Firma Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt? Ja

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype) Screen Designs in Photoshop und Code-Schnipseln in Form eines Kataloges

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt? Ja

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert?

2 Jahre wurde das Webportal von den 2 Entwicklern entwickelt. Jetzt arbeiten 4 Entwickler und 2 Studenten.

Welche oben genannte Rollen wurden in die Implementierungsphase involviert? Insgesamt waren 13 Entwickler involviert. (Wir kaufen auch die Unterstützung von Extern), 6 UI-Entwickler. Jetzt arbeiten 2,5 Entwickler für UI.

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt? JA. Es wurde eine Nachbesserung von den Wireframes von der Robotron-Seite angefordert.

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design?

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Skizzen, Wireframes, Photoshop Schreen-Deisigin, Code-Schnipseln.

Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Teilweise haben Photoshop-Designs den Kunden gezeigt

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Alle

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Ja. Die externe Design- Firma hat sich mit den Themen beschäftigt. Wie werden die Software-Erweiterungen entwickelt? Die Erweiterungen werden nach Kundenauftrag entwickelt.

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Entwickler bekommt ein Ticket zugewiesen (von einem Berater oder Projektleiter). In dem Ticket wird die Aufgabe in Form einer Notiz beschrieben. Manchmal gibt es dazu Zeichnungen oder Bilder. Entwickler hat einen Design Katalog. (Code-Schnipseln)

Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler. Es wird in der Rücksprache mit Berater und Fachteam entwickelt. Gibt es einen Style Guide für die Entwickler? Nein, aber es gibt Design-Katalog

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Designer, der im Prozess unterstützen würde. Screen Designs wären auch hilfreich.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Manuelle Tests, Unit-Tests sind fertig. Jetzt arbeiten wir an den automatisierten UI-Tests

Werden die Usability Tests durchgeführt? Nein, es wäre aber gut einen Hall-Way-Test zu machen.

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen? Es gab früher eine Review Runde. Es findet aber auf Zeitgründen nicht statt.

Design Maturity Model

Wie wichtig finden Sie Usability von der Software? Ich finde die Usability sehr wichtig. Aber man muss manchmal auf Kompromisse gehen und damit verbundener Aufwand ist nicht immer in der Praxis möglich.  1  2  3  4  5

Gibt es ein Design Team im Projekt? Nein, nur eine externe Firma, die ab und zu unterstützt

Wie viele Teilnehmer sind in dem Team? Welche Aufgaben werden von dem Team erledigt?

Wie werden die Aufgaben verteilt?

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Gibt es klare Rollenverteilung & Verantwortungen im Design Team?

Gibt es ein Design Teamleiter (Manager)?

Wie werden die Design-Entscheidungen getroffen?

Wird eine Strategie verfolgt?

Wann wird von der Strategie abweicht? Und warum?

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Ja, aber sehr gering

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? User Interface muss intuitiv und einfach sein.

Was kann man am Prozess nach Ihre Meinung verbessern? Entwickler sollte mehr Unterstützung bekommen. vlt. durch Bilder-Screendesigns , Wireframes, Entwurf

Fragebogen 5

Entwicklungsprozess (Design Prozess)

Name: Susanna Käpler + Andre Zeranski

Funktion/Rolle: Systemberaterin, ÖV2 + Junior-Projektleiter

Software-Produkt / Software-Lösung: Daphne

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5 (4)

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5 (4)

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Wir haben im Jahr 2011 angefangen die letzte Version zu entwickeln. Im Jahr 2012 -2013 lieft die Entwicklung. Die Software wird immer noch entwickelt.

Welche Hauptrollen gibt es im der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Produkt-Manager: Kundenkontakt, Anforderungsanalyse, Konzept schreiben

Entwickler: Implementiert die Software

Fachliche Beraterin: Führt die Tests durch (Qualitätmanagement)

Außerdem sind Praktikantenstellen sehr wichtig. (Objekt-Erfassung)

Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? 4 Personen + Kunden

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? 1Farbgebung, Design hat Marketing angefertigt. Außerdem die UI/UI-Themen wurden aktiv mit Kunden diskutiert. Also, 10%-20% Zeit hat man für die Oberfläche ausgegeben. In welche Hauptphasen war das Gesamtvorhaben unterteilt?

Ich kann es nicht genau beurteilen.

Wie viel Zeit wurde für jede Phase eingeplant? Kann ich nicht beurteilen.

Wurde von dem Zeitplan abgewichen und warum? Kann ich nicht beurteilen.

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert? Kann ich nicht beurteilen.

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

15 Kunden. Kunstsammlungen, Museen, Sammlungen aller Art. Bibliotheken, Denkmalämter…

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Mitarbeiter von den Institutionen, Praktikanten.

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Nein, die Software ist selbsterklärend

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Ja, wir haben einen Berechtigungskonzept.

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Wir machen Beratung vor Ort. Schulung besteht aus 2 Teilen.

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Nicht zuordenbar

Wurde es streng angehalten? Wenn es Abweichungen gab, warum?

Nein.

Phasen Ich würde Ihnen empfehlen zu dem genauen Ablauf der Phasen den Produkt Manager zu fragen

3.1 Analyse-Phase Fand eine Analyse statt? Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Analyse-Phase involviert?

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Anforderungen-Liste, Scenarios)

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Definitionsphase involviert?

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung)

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Entwurfsphase involviert?

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Wireframes-Entwurf) Konzeptbeschreibung

3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert?

Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt? Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype)

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt?

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Implementierungsphase involviert?

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design?

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Konzepte, Wireframes, Beschreibungen werden von den Produktmanager erstellt. Außerdem arbeiten wir sehr nah mit dem Kunden, die ganze Zeit findet ein Abstimmungsprozess statt.

Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Alle

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Alle

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Nicht bewusst

Wie werden die Software-Erweiterungen entwickelt? Die Erweiterungen werden nach Kundenauftrag entwickelt.

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Der Entwickler bekommt einen Konzept.

Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler Gibt es einen Style Guide für die Entwickler? Nein. Die Anwendung wird mit einem Framework entwickelt.

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Die Anwendung ist fast fertig. Zurzeit funktioniert das Entwicklungsprozess ganz gut. Es gibt nach meiner Meinung wenige Verbesserungsmöglichkeiten. Ein verbesserungspotenzial sehe ich aber in der Weblösung des Daphne Web.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Tester füllt eine Testtabelle aus. Sie prüftjede Prozesskette. Es gibt bei uns ein Ticketsystem, wo die Kunden Ihre Fehlermeldungen schreiben. Wir wollen bald einen Forum einrichten.

Werden die Usability Tests durchgeführt? Indirekt.

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen? Der Tester guckt sich das nicht an. Layout-Team übernimmt die visuelle Überprüfung.

Design Maturity Model

Wie wichtig finden Sie Usability von der Software?  1  2  3  4  5 Gibt es ein Design Team im Projekt?

Wie viele Teilnehmer sind in dem Team? Nein, alle Konzepte werden von den Projekt Manager gemacht.

Welche Aufgaben werden von dem Team erledigt?

Wie werden die Aufgaben verteilt?

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Gibt es klare Rollenverteilung & Verantwortungen im Design Team?

Gibt es ein Design Teamleiter (Manager)?

Wie werden die Design-Entscheidungen getroffen? Nach Erfahrung aus den Museen

Wird eine Strategie verfolgt?

Wann wird von der Strategie abweicht? Und warum?

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Nein. Design wird zum Teil der Entwicklung.

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? User Interface muss intuitiv und einfach sein. Was kann man am Prozess nach Ihre Meinung verbessern? Zurzeit kann nur einen neuen Relaunch der Software helfen, wo man auch die Technologie umstellt. z.B. auf Web.

Fragebogen 6

Entwicklungsprozess (Design Prozess)

Name: Rita Kempe

Funktion/Rolle: Projektleiter GB ÖV

Software-Produkt / Software-Lösung: Fömisax, Sachsen Födermittelverwaltung

Finden Sie das Design des Software-Produkts / der Software-Lösung gut? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

Ist es (nach Ihre Meinung) leicht bedienbar? Bewerten Sie in der Skala von 1 bis 5.  1  2  3  4  5

1. Allgemeine Fragen

Über welchen Zeitraum fand die Entwicklung des Software-Produkts / der Software-Lösung statt? (Von der Anforderungsanalyse bis zum ersten Release)

Wir haben im Jahr 2011 angefangen. 2013 hat die Implementierung angefangen. Die Software wird immer noch entwickelt.

Welche Hauptrollen gibt es in der Entwicklung der Software-Lösung bzw. des Produkts und welche Aufgaben haben diese?

Themenverantwortliche: Er nimmt die Rolle eines Systemarchitektes an

Berater: Fachliche Verantwortung, Schnittstelle zu den Kunden

Entwickler: Implementiert die Software

Wie viele Personen haben sich im gesamten Prozess aktiv mit UI/UX Design Themen auseinander gesetzt? Insgesamt 3 Personen. Teil davon waren die Kunden und Berater.

Welchen Anteil (Prozent) hatten die Arbeiten bzgl. Usability und Design im Vergleich zum Gesamtvorhaben? Es ist sehr schwer einzuschätzen, aber vlt. 10% Arbeitszeit Berater

In welche Hauptphasen war das Gesamtvorhaben unterteilt?

Anforderungsanalyse (1,5 Jahre - 2 bis 3 Mitarbeiter) ->

Implementierung (1,5 Jahre – 6 Entwickler)

Anpassungen und Weiterentwicklung (3, 4 Mitarbeiter)

Wie viel Zeit wurde für jede Phase eingeplant? s.o.

Wurde von dem Zeitplan abgewichen und warum? Es gab keinen genauen Zeitplan. Wir haben uns immer an den Kunden orientiert. Der Kunde war sehr flexibel.

Wie viele Personen waren in die einzelnen Phasen insgesamt involviert? s.o.

2. Produkteigenschaften:

Wer ist der Kunde / sind die Kunden des Software-Produkts / der Software-Lösung?

Landesamt für Steuer und Finanzen, Bewilligungsstellen in Ministerien.

An welche Zielgruppen richtet sich das Software-Produkt / die Software-Lösung? Fachkräfte in den Ämtern

Müssen die Nutzer bestimmte Fachkenntnisse haben, um das Software-Produkt / die Software- Lösung benutzen zu können? Ja

Gibt es verschiedene Nutzerrollen für das Software-Produkt / die Software-Lösung? Ja - Fachadmin, Normalen Arbeiter, Superadmin

Müssen die Nutzer des Software-Produkts / der Software-Lösung geschult werden? Wie? Wie lange dauert die Schulung? Ja. (1 Tag)

3. Beschreibung Entwicklungsprozess:

Welches Vorgehensmodel wurde im Entwicklungsprozess angewendet? (z.B. Wasserfallmodel, Spiralmodel, Agile…)

Nicht bewusst.

Wurde es streng angehalten? Wenn es Abweichungen gab, warum?

Nein, es gab keinen strengen Plan, wir waren sehr flexibel. Phasen Ich würde Ihnen empfehlen zu dem genauen Ablauf der Phasen die Berater zu fragen.

3.1 Analyse-Phase Fand eine Analyse statt? Ja

Wie lange dauerte die Analyse-Phase und wie viele Mitarbeiter waren involviert? 1,5 Jahre

Welche oben genannte Rollen wurden in die Analyse-Phase involviert? Kunde, Berater, Themenverantwortliche

Wurden in der Analyse-Phase spezielle Aspekte des UI-Designs berücksichtigt? Nein, nur fachliche Fragen

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? Anforderungen (z.B. Anforderungen-Liste, Scenarios)

3.2 Definition Fand eine Definitionsphase oder eine vergleichbare Phase statt? Bedingt.

Wie lange dauerte die Definitionsphase und wie viele Mitarbeiter waren involviert? Das war Teil der Analyse-Phase

Welche oben genannte Rollen wurden in die Definitionsphase involviert? S.o.

Wurden in der Definitionsphase spezielle Aspekte des UI-Designs berücksichtigt? nein

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Konzeptbeschreibung) 2 A4- Seiten-Beschreibeung kurze Spezifikation

3.3 Entwurf Fand eine Entwurfsphase oder eine vergleichbare Phase statt? nein

Wie lange dauerte die Entwurfsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Entwurfsphase involviert?

Wurden in der Entwurfsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Wireframes-Entwurf) Konzeptbeschreibung

3.4 Ausarbeiten

Fand eine Ausarbeitungsphase oder eine vergleichbare Phase statt? nein

Wie lange dauerte die Ausarbeitungsphase und wie viele Mitarbeiter waren involviert?

Welche oben genannte Rollen wurden in die Ausarbeitungsphase involviert?

Wurden in der Ausarbeitungsphase spezielle Aspekte des UI-Designs berücksichtigt?

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet?

Welches waren die zentralen Ergebnisse bzgl. UI-Design? (z.B. Screen-Design/Prototype)

3.5 Implementierung

Fand eine Implementierungsphase oder eine vergleichbare Phase statt? ja

Wie lange dauerte die Implementierungsphase und wie viele Mitarbeiter waren involviert? 6

Welche oben genannte Rollen wurden in die Implementierungsphase involviert? Entwickler

Wurden in der Implementierungsphase spezielle Aspekte des UI-Designs berücksichtigt? -

Wurden bestimmte Entwurfs- /Evaluationsmethoden für die Phase angewendet? nein

Welches waren die zentralen Ergebnisse bzgl. UI-Design? Fertiges Produkt

3.6 Gesamtergebnisse

Welche "Design-Deliverables" wurden insgesamt erstellt?

Wir haben keine Dokumente für UI-Design erstellt.

Welche von diesen Design-Deliverables wurden mit dem Kunden diskutiert?

Keine

Welche von diesen Design-Deliverables wurden dem Entwickler zur Verfügung gestellt?

Kurzbeschreibungen, Email-Nachrichten

Können Sie Beispiele zeigen? z.B Wireframes, Konzept, Mockups, Photoshop, Paper Prototype…

Welches Grundwissen aus Psychologie und Design wurde im Projekt genutzt? Nicht bewusst eingesetzt Wie werden die Software-Erweiterungen entwickelt? Die Erweiterungen werden nach Kundenauftrag entwickelt. Das selbe Entwicklungsprozess findet statt.

------4. Entwickler

Was bekommt Entwickler als Grundlage zur Implementierung von User Interfaces?

Beschreibung Wie geht der Entwickler bei der Implementierung von User Interfaces vor? Je nach Entwickler Gibt es einen Style Guide für die Entwickler? Ja, nicht offiziell

Was könnte dem Entwickler noch zusätzlich beim User Interface Design helfen? Weiterbildung, Gestaltungsworkshops, Menschenverstand und Wunsch ein schönes Ergebnis zu liefern. Es wäre gut wenn nach der Implementierung jemand von außen über das Ergebnis drüber guckt um die Rechtsschreibfehler und Design zu kontrollieren.

5. Tester

Welches Model wird beim Softwaretest eingesetzt? Wir haben keine Tester

Werden die Usability Tests durchgeführt?

Wie wird mit identifizierten Abweichungen vom Style Guide umgegangen?

Design Maturity Model

Wie wichtig finden Sie Usability von der Software?  1  2  3  4  5 Gibt es ein Design Team im Projekt?

Wie viele Teilnehmer sind in dem Team?

Welche Aufgaben werden von dem Team erledigt?

Wie werden die Aufgaben verteilt?

Wie viele Personen beschäftigen sich nur mit Design-/Layout-Themen?

Gibt es klare Rollenverteilung & Verantwortungen im Design Team?

Gibt es ein Design Teamleiter (Manager)? Wie werden die Design-Entscheidungen getroffen?

Wird eine Strategie verfolgt? Wir versuchen das Interface einheitlich für den Nutzer zu machen

Wann wird von der Strategie abweicht? Und warum? Kann nicht beurteilen

Wurden jemals Usability Tests/ Usability Researchers durchgeführt? nein

Gibt es ein Usability/Design-Budget? Nein

Verbesserungspotenzial

Was ist für Sie ein gutes User Interface Design? User Interface muss intuitiv und einfach sein. Was kann man am Prozess nach Ihre Meinung verbessern? Es wäre gut ein einheitliches Konzept zu haben.