DF Developing a future concept for an online clothing configurator An evolution of Ridestore’s style creator, 2020 Bachelor’s thesis in Product Design Engineering ALEXANDER MATTSSON ANTON OHLSLÖF Department of Product Design Engineering CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2020 Bachelor’s thesis 2020 Developing a future concept for an online clothing configurator An evolution of Ridestore’s style creator, 2020 Alexander Mattsson and Anton Ohlslöf DF Department of Product Design Engineering Chalmers University of Technology Gothenburg, Sweden 2020 Developing a future concept for an online clothing configurator An evolution of Ridestore’s style creator, 2020 Alexander Mattsson and Anton Ohlslöf © Alexander Mattsson and Anton Ohlslöf, 2020. Supervisor: Olof Wranne and Mafalda Samuelsson Gamboa Examiner: Olof Wranne, Department for Design & Human Factors at the Institution for industry- and materialscience Bachelor’s Thesis 2020 Department of Product Design Engineering Chalmers University of Technology SE-412 96 Gothenburg Telephone +46 70 772 9099 Cover image: Demonstration and over dramatisation to illustrate how the clothing configurator will work. Typeset in LATEX, template by David Frisk Printed by Chalmers Reproservice Gothenburg, Sweden 2020 iv Developing a future concept for an online clothing configurator An evolution of Ridestore’s style creator, 2020 Alexander Mattsson and Anton Ohlslöf Department of Product Design Engineering Chalmers University of Technology Abstract The aim of this project was to investigate how Ridestore’s stylecreator could evolve with UX design, an ease of use perspective, in preparation for when they can display fully 3D rendered clothing instead of photographs. The goal was to propose a digital prototype with proof of concepts through visual examples that Ridestore could implement in their online configurator/style creator to show how different sized clothing could fit on different sized bodies with an increased website usability. The project started off by analyzing Ridestore’s current style configurator to understand its strengths and weaknesses in order to design: tasks performed by test participants, questions for follow up semi-structured interviews, and questions to be asked to focus groups. The data from these user tests was used to define functions, requirements and wishes for the end product. All of this resulted in a digital prototype that was created using Figma, an online prototyping tool. Evaluation of the different components in the prototype was conducted through a methodical triangulation between the requirements, data from the user studies and theoretical background on UX design. In the end, it was possible to conclude that the digital prototype is an improvement of Ridestore’s current configurator, as it hypothetically solves all of the requirements and the most important wishes. It is however not clear that it will work perfectly in the end due to the lack of user tests done on the prototype. Keywords: online, clothing, configurator, style, combinations, Ridestore, usability, users, tests. v Acknowledgements We would like to thank Olof Wranne and Mafalda Samuelsson Gamboa from Chalmers, Linnea Grunnesjö and Nhina Svensson from Ridestore, and our friends and family at home for helping us with guidance and opinions for this project. Alexander Mattsson and Anton Ohlslöf, Gothenburg, June 2020 vii Contents List of Figures xiii 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Aim and Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Specification of issue under investigation . . . . . . . . . . . . . . . . 2 2 Theoretical background 3 2.1 Different Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Achieving Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1 Flow through animations . . . . . . . . . . . . . . . . . . . . . 5 2.3 Excise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Navigational excise . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1.1 Navigation across multiple views, or pages . . . . . . 6 2.3.1.2 Navigation between tools and menus . . . . . . . . . 6 2.3.2 Navigation of information . . . . . . . . . . . . . . . . . . . . 7 2.3.3 Eliminating Navigational Excise . . . . . . . . . . . . . . . . . 7 2.4 Manual Affordance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Methodology 9 3.1 Data gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Heuristic Evaluation . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Think-Aloud observations . . . . . . . . . . . . . . . . . . . . 10 3.1.3 Structured Interviews . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Semi-structured Interviews . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Open-ended Interviews . . . . . . . . . . . . . . . . . . . . . . 10 3.1.6 Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.7 Data Recording . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Defining the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 KJ-analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Specification of requirements, wishes and functions . . . . . . 12 3.2.3 Function Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 Triangulation in research . . . . . . . . . . . . . . . . . . . . . 13 3.3 Generating Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 Collective Notepad . . . . . . . . . . . . . . . . . . . . . . . . 14 ix Contents 3.3.2 Brainwriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.4 SCAMPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.5 Thinking Hats . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Digital Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Evaluation of Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.1 Not Invented Here . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.2 Triangulation in evaluation . . . . . . . . . . . . . . . . . . . . 15 3.6 Improvement through iteration . . . . . . . . . . . . . . . . . . . . . 16 4 Procedures and Results 17 4.1 Effects of the COVID-19 pandemic . . . . . . . . . . . . . . . . . . . 17 4.2 Picking literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Sustainability analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 How data was gathered and its output . . . . . . . . . . . . . . . . . 19 4.4.1 Heuristic Evaluation of the Current Configurator . . . . . . . 19 4.4.2 User studies of current situation . . . . . . . . . . . . . . . . . 21 4.4.2.1 Focus groups on winter sport clothing . . . . . . . . 21 4.4.2.2 Think-Aloud observation on current website . . . . . 22 4.4.2.3 Semi-structured interviews regarding current website 23 4.5 How the problem was definied . . . . . . . . . . . . . . . . . . . . . . 23 4.5.1 Kj-analysis on gathered data . . . . . . . . . . . . . . . . . . . 24 4.5.2 Compiling Functions, requirements and wishes . . . . . . . . 25 4.5.3 Triangulating research data . . . . . . . . . . . . . . . . . . . 27 4.6 The development process . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.6.1 The Collective Notepad in use . . . . . . . . . . . . . . . . . . 27 4.6.2 Performing Brain Writing . . . . . . . . . . . . . . . . . . . . 28 4.6.3 Maintaining focus and spurring ideas . . . . . . . . . . . . . . 28 4.6.4 Brainstorming for digital prototypes . . . . . . . . . . . . . . 29 4.6.5 Refinement and Compilation of the Prototype . . . . . . . . . 30 5 Proposal to Ridestore through a digital prototype 33 5.1 Digital rendering instead of photographs . . . . . . . . . . . . . . . . 35 5.2 Moving the avatar to the left side . . . . . . . . . . . . . . . . . . . . 35 5.3 [R.1] Give a relatable, editable, depiction of the user . . . . . . . . . . 35 5.4 [R.2] Show how different sizes of clothing fit on the same body . . . . 40 5.5 [R.3] Enable effective comparisons between garment sizes . . . . . . . 41 5.6 [R.4] Provide intuitive and responsive navigation . . . . . . . . . . . . 42 5.7 [R.5] Display elements that are easily understood . . . . . . . . . . . 45 5.8 [W.1] Mediate garment fit on different body positions . . . . . . . . . 47 5.9 [W.2] Show garment from multiple angles . . . . . . . . . . . . . . . . 48 5.10 [W.3] It should be a conscious decision to remove all the clothes from manikin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.11 [W.4] Display all the available products in the style creator . . . . . . 50 6 Discussion 51 x Contents 6.1 [E.1] Eliminate the all return shipments based on incorrect sizing or unpleasant fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 Why is it not possible to manually edit the avatar after scanning? . . 51 6.3 Where the user study participants too old? . . . . . . . . . . . . . . . 52 6.4 Did the COVID-19 pandemic affect the result? . . . . . . . . . . . . . 52 6.5 New to Interaction Design . . . . . . . . . . . . . . . . . . . . . . . . 53 6.6 Real life feasibility of the proposal . . . . . . . . . . . . . . . . . . . . 53 6.7 Evaluating without matrices and final user tests . . . . . . . . . . . . 53 6.8 Being objective when using triangulation for evaluation . . . . . . . . 54 6.9 Analysis of Ridestore’s ethics . . . . . . . . . . . . . . . . . . . . . . 54 6.10 Ethics regarding gender selection . . . . . . . . . . . . . . . . . . . . 55 6.11 Ethics regarding words that might exclude certain people . . . . . . . 55 7 Conclusion 57 7.1 Was the project successful? . . . . . . . . . . . . . . . . . . . . . . . . 57 Bibliography 59 A Data gathering I B Ideation V xi Contents xii List of Figures 2.1 Illustration of Represented model spectra. Cooper et al., 2014. . . . . 3 2.2 The sub-menu of Adobe Photoshop’s fill tools. Cooper et al., 2014. . 7 3.1 Picture of the scale that was used to grade wished from 1 to 5. Au- thors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Illustration of a function tree. Authors’ own picture, 2020. . . . . . . 13 4.1 Overview of the OneNote board where the blue and purple ellipses en- closes the quotes (seen as small black lines) from the focus groups and the semi-structured interviews respectively. Authors’ own picture, 2020. 24 4.2 Function tree. Authors’ own picture, 2020. . . . . . . . . . . . . . . . 26 4.3 A sample of ideas from the first Brain Writing session. Authors’ own picture, 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 The right part of the image shows testing of different possible al- ternatives for Ridestore’s current navigation menu between clothing categories (left image). Authors’ own picture, 2020. . . . . . . . . . . 29 4.5 Testing the history display as well as size and color choice features. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . 30 4.6 Screenshot from www.ridestore.se 2020-05-24. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1 Overview over the current and remade style creator. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2 Picture of a user hovering over a choice between selecting male or female. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . 36 5.3 Picture of a user hovering over a choice between scanning their own body vs creating a more general avatar. Authors’ own picture, 2020. . 36 5.4 The different steps required for the user to scan itself using a phone camera. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . 38 5.5 A slider is being used to change the body composition of the avatar, where the rightmost image shows a body containing more fat whereas the leftmost displays a body consisting of more muscle. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.6 Screenshots from the prototype taken for a jacket and a pair of pants in the different sizes small, medium and large. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 xiii List of Figures 5.7 The size selection menu that is connected to the clothing category currently selected. Authors’ own picture, 2020. . . . . . . . . . . . . . 41 5.8 Cut outs that show the quick start guide that appears when entering the style creator. Authors’ own picture, 2020. . . . . . . . . . . . . . 42 5.9 Comparison between Ridestore’s current main menu and the new, remodeled one. Authors’ own picture, 2020. . . . . . . . . . . . . . . 43 5.10 Comparison between the old and new menus for navigating between clothing categories. Authors’ own picture, 2020. . . . . . . . . . . . . 44 5.11 The new way of viewing product specific information about clothes. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . 44 5.12 A cohesive look for all the drop down menus and buttons. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.13 The left picture shows of the current way of seeing selected products and the right picture shows the new way. Authors’ own picture, 2020. 46 5.14 Small colour dots in every product window represents the different available colours for that garment. Authors’ own picture, 2020. . . . . 46 5.15 Difference between two different body positions, where the left one shows a normal stance and the right one shows one with the avatar’s hands over its head. Authors’ own picture, 2020. . . . . . . . . . . . . 47 5.16 The rotation feature in the style creator. Authors’ own picture, 2020. 48 5.17 The left pictures show the ways to remove clothing in the current style creator, where the user either clicks the entire item, or switches be- tween the different genders for the avatar. The right picture show the new way of deselecting pieces, with a button. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.1 The collaboration board from the female focus group. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II A.2 The collaboration board from the male focus group. Authors’ own picture, 2020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III A.3 The complete list of graded wishes. Authors’ own picture, 2020. . . . IV B.1 The Collective Notepad. Authors’ own picture, 2020. . . . . . . . . . VI xiv 1 Introduction The purpose of this chapter is to define the framework for the project in order to make it easier to understand the starting point and the end goal of the project. 1.1 Background As of today, Ridestore is designing, selling and distributing winter sport clothing online on their website ridestore.se. One way to view and purchase clothing on their website is by using their "Style Creator", which is a clothing configurator where the user can create a style by selecting different clothing pieces. The main focus in this project has been to improve this configurator for the future by adding functionality and increasing the website’s usability. Ridestore has a process when it comes to designing clothing, and it starts off by modeling the garments in a software called Clo3D. These models later undergo a rendering process in another program named Blender. Though, before the renders are made, small changes such as moving the garment on the avatar or adding small buttons has to be done since the design team has deemed that doing this in Blender (a CAD program) is simpler and more time effective than it would be in Clo3D. The renders are subsequently adjusted in Adobe Photoshop to be more color accu- rate. These stills can afterwards be used in polls on social media platforms such as Instagram, to gather information about what specific color combination or design satisfies their customers. When the design is finalized, it gets sent to the clothing manufacturer. When the clothes return in their final form, they are photographed. Photos taken on one particular pose will later be fitted for their previously mentioned online cloth- ing configurator, using Photoshop. Taking all of these photos and editing them is a time staking process and it has to be done quickly after a new collection is released. The technical aspects of modelling and rendering the clothes may be beyond the authors’ abilities. Therefore, the focus has been on improving the current configu- rator, by researching related literature to create future visions and concepts. These concepts could then be implemented or used as inspiration for a future configurator, when the technology is good enough to smoothly and quickly create photorealis- tic renders of clothes in many different sizes. As a final note, the creators of this project have assumed that the customer segment mostly consists of kids, teenagers and young adults, since Ridestore was unable to share information about this topic. 1 1. Introduction 1.2 Aim and Goal The aim of this project was to investigate how Ridestore’s stylecreator could evolve with UX design, an ease of use perspective, in preparation for when it can start to display fully 3D rendered clothing instead of photographs. The goal is to propose a digital prototype with proof of concepts through visual examples, that Ridestore could implement in their online configurator to show how different sized clothing will fit on different sized bodies with an increased website usability. 1.3 Delimitations The concept for the configurator does not have to work, it only has to show how it would function if it were to be created as a real product. This means that no coding or programming has to be done, and that it does not have to be interactive. Instead of using 3D-renders to display the garments, edited photographs will be used. This is for practicality reasons and they will only be used to display the de- sired functions and features of the configurator. The possibility to render 3D clothing in real time on the website does not have to be taken into consideration when developing the concept. 1.4 Specification of issue under investigation Based on the aim and goal mentioned in 1.2, there are some questions worth ad- dressing to keep the project on the right track: • How will options for different body- and clothing sizes be displayed, so the user is able to decide which size is best for the intended use case? • How many sizes does the user need to see in order to make a good purchasing decision? • How is the fit of the garment best communicated? • Is the ability to manipulate the manikin needed? • Does the draping and creasing of clothes matter? • What type of layout for the configurator will result in the best usability? • Which areas of the existing configurator has to be improved? • Will too many choices make it hard for the user to make choices? • Will a simple layout make interaction easier? • Will a responsive, quick and unobtrusive website make the interaction more fun? 2 2 Theoretical background The information in this chapter will later be referred to in order to explain design choices that have been made in the digital prototype. 2.1 Different Models The concept of implementation, represented and mental models are brought up by Cooper, Reimann, Cronin, and Noessel (2014, p. 15-20) in the book About Face: The Essentials of Interactions. They say that a product following the implementation model is used very similarly to how it works mechanically, while a product following the mental model is designed to be used in a way the user finds intuitive. They also say mental models often differs from user to user and are sometimes impossible to realize, Cooper et al. (2014) therefore also bring up the represented model. It is the spectra between the implementation and mental models where the designer of the product can choose to position it in relation to either end. Cooper et al. (2014) states the importance of trying to stay as close to the mental model as possible. An illustration of different models can be seen in Figure 2.1 below. Figure 2.1: Illustration of Represented model spectra. Cooper et al., 2014. 2.2 Achieving Flow Cooper et al. (2014) brings up arguments for how to make interactions with an inter- face a seamless experience for the user. They base their theories on Csikszentmiha- lyi’s concept of Flow which they describe as a state where people can be "extremely 3 2. Theoretical background productive, especially when engaged in constructive activities" and "can make you unaware of the passage of time" (Cooper et al., 2014, p. 249-269). They further state that if all elements in a software are well "orchestrated" the user can achieve a state Flow where she forgets that she is using a program and is only focusing on the goals to reach. It is all about enabling effortless "Harmonious Interactions" between human and machine. Cooper et al. (2014) also present a list of strategies they deem "effective for designing interactions that go with the user’s flow". A shortened ver- sion of the in depth explanations from the book can be read below: • Follow users’ mental models. Many users have different goals with the same software and the software should therefore have the ability to change accord- ingly. For example, sorting clients after different attributes such as credit or health history, depending on if there is a desk clerk or doctor reviewing the patients profile. • Less is more. Dieter Rams once said, "good design is as little design as pos- sible". The user should need as little interaction as possible to achieve their goal and there should be very little "interface" that can be misinterpreted and cause user mistakes. Keeping it simple and easy to understand is crucial to maintain Flow. • Let users direct rather than discuss. Let the user be in control of what is happening by experiencing the result of their actions in the software, not though dialog boxes popping up. If a carpenter hits a nail with a hammer, she sees that the nail got bent and needs directing or replacing, the nail does not shout it in her face. • Provide choices rather than ask questions. Instead of the user being asked what they want should happen, they should be able to choose for them selves when it fits them. Instead of getting asked by a dialogue box what color the shape you just created in Adobe Illustrator should be, the user can just open the color palette when it suits them and choose the color they deem fitting at the time. • Keep necessary tools close at hand. Trying to find a specific tool can easily disturb Flow. They should therefore be placed close at hand in accordance to how often they are used. Keyboard shortcuts should also be possible to use to make an ever more "harmonious interaction" for expert users. • Provide modeless feedback. When a program gets halted in wait for a response to be made in a dialogue box, it is put in a modal state, this interrupts Flow and should be avoided. A good way to give "modeless feedback" is to display real time updating information in the edges of the screen, so it is visible for the user when she feels the need to look at it. • Design for the probable but anticipate the possible. This is best described with an example, there is a possibility that a user would want to discard the work she has done. However, the probability that she would want to save it instead is many times greater. Therefore, it is much better if a system saves changes without asking, instead of relying on the user to make that conscious decision. • Contextualize information. Processing detailed numerical information takes up cognitive working memory for the user. It is therefore better to visualize 4 2. Theoretical background information with pie charts or bars. • Reflect object and application status. The user wants to understand what the system is doing, so if it is asleep, it should look asleep, if it is working hard, it should look like it can not respond instantaneously. • Avoid unnecessary reporting. There is no need to report normalcy to the user. Only high alert changes and questions should be presented in dialogues. • Avoid blank slates. It is often hard to start with an empty space to fill, therefore starting out with some tips or examples of where different information or elements could be placed is a good way to guide the user and induce Flow. • Differentiate between command and configuration. The user does not like to be presented with many choices when asking to do a task they deem "simple". Asking to print a document often results in a big window where a lot of configuration can be done, most of which is highly irrelevant for the user at that time. • Hide the ejector seat levers. The ejector seat lever in a fighter jet results in a drastic change of the system and should never be pushed unintentionally. The same is true for commands that drastically change a software and/or possibly discard recent work. • Optimize for responsiveness but accommodate latency. A system should be clear about how much time a certain task will take to perform. If a task is time consuming, the user should be able to cancel it or do other work in the meantime (Cooper et al., 2014, p 251-266). 2.2.1 Flow through animations In addition to the list above Cooper et al. (2014) discusses the power of using "mo- tion, timing and transitions" in ways that make animations great mechanisms of explaining the relationships between objects, when they are used well. They also emphasise the importance of not using them to much or in an irritating manner, since it can cause disorientation and frustration. To make good animations, these guidelines on how they should behave are presented: • Short, Sweet and Responsive. If the animations are to slow, they inhibit instead of enable Flow. • Simple, meaningful and appropriate. They should be enhance the experience of using a software, a help, not the main attraction. • Natural and Smooth. Animations should mimic the real world in terms of shadows, inertia, movement etc (Cooper et al., 2014). 2.3 Excise According to Cooper et al. (2014, p. 271-272) digital products of today are made in such a way that tax the users in a cognitive and physical manner. This tax is referred to as excise. The users have to understand the products layout along with using their previous knowledge to understand how this new product might behave. 5 2. Theoretical background Using all of this mental power at the same time as maneuvering a computer mouse can cause unnecessary strain on the person, hindering them to reach their goal. Cooper et al. (2014) brings up an example of driving to work, where the goal is go reach the destination. During this task, the driver has to do things that does not have a direct correlation to the actual driving. They have to open their garage to back out the car and start the motor before they can start driving which are all taking up valuable time for the driver. Thus, when it comes to digital product you want to minimize the amount of unwanted steps the user have to take to reach their end goal by eliminating excise. 2.3.1 Navigational excise A lot of excise is caused when navigation is needed to find the wanted tool, web page or end destination of an interactive product and can cause major frustration (Cooper et al., 2014). This bad type of navigation is unfortunately one of the most common problems when it comes to software. One way to combat this is by having well-designed navigation that can help the user by instructing it towards their goal. Cooper et al. (2014) has a broad definition of how to spot navigational excise and it follows: "any action that takes the user to a new part of the interface or that requires him or her to locate objects, tools, or data elsewhere in the system." - is navigational excise and should thereby be minimized and even eliminated if possible. 2.3.1.1 Navigation across multiple views, or pages They further mention that it is important that the user does not have to switch between windows or screens, since it is highly likely that this will disorient and frustrate them, leading to distraction from their goal and a decrease in productivity. If the user gets completely lost in the interface it is experiencing navigational trauma (Cooper et al., 2014). A possible way to negate this is by using multiple panes next to each other or by using tabs that can stack onto each other. However, the placement of the panes have to match the user’s workflow and they should avoid being so crowded that scrolling is required (Cooper et al., 2014). An additional note to have in mind here is that contradictions may occur between helping the user to navigate and hiding excise. They exemplify this with the interface of Microsoft excel, where tabs are used to enable navigation between multiple documents in the main work area. In this case, the tabs could result in navigational excise for the user, but the fact that they enable the user to work in multiple documents makes them necessary. Moreover, the settings menu in general is mentioned. The added navigational excise of categorizing settings is a worthy trade off instead of seeing all the settings at the same time. It also saves space (Cooper et al., 2014, p. 274-275). 2.3.1.2 Navigation between tools and menus Menus should be used when the command that are hidden in it are accessed infre- quently, since the content that the menu item holds is not visible to the user prior to clicking it. Here, Cooper et al. (2014) mentions another contradiction where the "gradient tool" and the "paint bucket tool" (seen in Figure 2.2) are under the same 6 2. Theoretical background sub-menu in Adobe Photoshop. It makes sense that they are grouped together since they are both "fill tools", but they argue that both of the tools should be visible at all times because of their frequent use. Figure 2.2: The sub-menu of Adobe Photoshop’s fill tools. Cooper et al., 2014. 2.3.2 Navigation of information Zooming, panning and scrolling should be minimized but they are often necessities which makes it important to understand the users’ mental models so that you pick the right one. Pan and Zoom is often used when looking at maps, 3D models, or in details of pictures. While Scrolling is used when maneuvering horizontally or vertically in 2D information (Cooper et al., 2014, p. 278). 2.3.3 Eliminating Navigational Excise Cooper et al. (2014) states the Navigational Excise to be the most prevalent in dig- ital products propose a set of guideline to how to get rid of or avoid it. Reduce the number of places to go - The overall amount of windows, and different places to end up should be kept to a minimum within an interface. Provide signposts - Signposts are similarities over different interfaces that the user knows how to maneuver. They are also symbols and icons explaining where a spe- cific function can be found. Properly map controls to functions - Buttons should be placed so that the user un- derstands what they affect when they are activated. For instance when the controls 7 2. Theoretical background to a stove top are placed in the same pattern as the burners, it is easy to understand what knob to turn. Avoid hierarchies - In the physical world storage is not very often performed in multiple layers, there is often just an item on a shelf. However, digital interfaces enables grouping folders into folders into infinity. This is not intuitive for the user and cause excise. (Cooper et al., 2014, p. 285-294). 2.4 Manual Affordance Cooper et al. (2014) challenges Donald Normans concept of Affordances by calling it Manual Affordance instead. They do this since they claim that Manual Affordance occurs when a user instinctively knows how something should be used, solely based on its properties such as shape, size and weight etc., unlike Normans Affordance concept that also include the object in relation to other ones, like a button next to a door is a doorbell. Cooper et al. (2014) disagree with Norman by saying that his concepts includes things users are taught, not thinking just by using their "cave man" instincts. To sum up, according to Cooper et al. (2014) Manual Affordance is when a person feels the urge to perform an action with an object or an interface just from relying on instinct. In 2-dimensional digital interfaces this can be achieved with shading, telling the humans’ tool manipulating brains for example to "slide" or "press" as well as give the interface a sense of depth (Cooper et al., 2014, p. 312-314). 8 3 Methodology The chapter explains the methods that have been used during this project. 3.1 Data gathering In order to define the products boundaries, limitations, requirements and wanted functions, it was important to gather data in different ways to establish a starting point. The following methods aided this quest. 3.1.1 Heuristic Evaluation This method was invented to help set aside developer biases in regards to how a soft- ware should function. It works by having experts or novices alike evaluate anything from a low-fidelity prototype to a complete product against an agreed set of rules. This method rarely result in big breakthroughs, but it often helps to find incon- sistencies early on in a development process as well as imperfect dialogue elements (Martin, Hanington, & Hanington, 2012, p. 98). Below are 10 widely acknowledged heuristics developed by Jakob Nielsen in 1994, as interpreted by Wong (2020). 1. Visibility of system status. Users should always get to know what the system is doing in a convenient manner. 2. Match between system and the real world. When adequate the system should mirror the real world, based on user expectation. 3. User control and freedom. The possibility of backward steps, undoing and redoing should be provided. 4. Consistency and standards. Regardless of what platform you are using a web- site, visual elements and terminology should stay the same. 5. Error prevention. By reducing or alerting actions that might cause errors, they can be kept to a minimum. 6. Recognition rather than recall. For instance, music apps show album covers, it is easier to recognize a picture than recall the name of a song. 7. Flexibility and efficiency of use. The system should be adaptable to how the person uses it. 8. Aesthetic and minimalist design. To not make the user confused or distracted, unnecessary visuals should be avoided. 9. Help users recognize, diagnose and recover from errors. Since users rarely understand technical terminology, error messages should most often be in plain 9 3. Methodology language. 10. Help and documentation. If instructions on how to use the system can not be avoided, they should be both easily located and understood (Wong, 2020). 3.1.2 Think-Aloud observations To help surface what emotions and problems users are experiencing when performing a task the Think-Aloud protocol is often used withing usability testing. It is per- formed by having a user verbalize their actions and thoughts as they are interacting with an interface or product. There are two main ways to perform the observation, concurrently and retrospectively. In the first the user is talking as they are perform- ing the task with an emphasis on what is happening and not why they think it is happening. The second way is conducted through analysis of video recordings of the user performing the task, where the user comment on what their thoughts were in different situations during the observation. The concurrent approach gives a more detailed view of the step by step actions while the retrospective can give a deeper insight into user feelings. (Martin et al., 2012, p. 180-181) 3.1.3 Structured Interviews Structured interviews can be useful when you want feedback on particular design features on websites (Rogers, Sharp, & Preece, 2019, p. 268). The reasoning behind this is that it is possible to ask questions that are very relevant to the aim and goal of the project. Moreover, it is important that all of the participants get asked the same exact questions and that they know the goal of the study. The questions asked here will be closed, which means that they are asked to choose between predefined answers (Rogers et al., 2019). An example of such a question could be "How often do you use the internet? More than once an hour? Once an hour? Once a day? Or once a week?" 3.1.4 Semi-structured Interviews Rogers et al. (2019, p. 268) mentions that it can be good to use an open-ended style of interviewing when the goal is to see reactions for a new concept. Here, the interviewer should use a basic script of closed questions and then probe (discussed in section 3.1.5 "Open-ended Interviews") with more open questions. An example of a closed question could be "If you have to chose between a red and a green button, which one would you pick?" and an open one is "How did you feel when pushing the button?". The importance of the interviewers body language and facial expressions should not be neglected. Nothing should feel rushed or unnatural to the interviewee. 3.1.5 Open-ended Interviews An open-ended interview is good to use when you want to gather qualitative data. The way this is done is by using a lot of probing, which is when the interview ask relevant follow up questions or other questions that can have deeper unexpected answers (Rogers et al., 2019, p. 269). A regular probe could be "Can you tell me a 10 3. Methodology bit more about..." and a neutral probe is "Do you want to tell me anything else?". This can produce rich insights but the data can take a while to analyze (Rogers, Sharp, & Preece, 2011). 3.1.6 Focus Groups Focus groups are useful when it is more interesting to look at shared issues among people rather than individual experiences between them. The groups are often formed so that the participants have many common denominators and will therefore use the product that is under developed in similar ways (Rogers et al., 2019). It is conducted by having a moderator give out a statement, question or task for the group to complete, while managing the participants so everyone is able to speak. Furthermore, it can be needed to steer the people back onto the right track if drifts too far away from the subject (Rogers et al., 2019). There can however be some problems with using focus groups. According to Richardson (2016), focus groups does not work a lot of the time due to numerous reasons. The first one is peer pressure, which can impact what people say even if they think that it does not impact them. Secondly, people lie unconsciously by sharing their thoughts in a way that can represent them as better than they actually are (Richardson, 2016). Because of this, it is important to understand that statements has to be taken with a grain of salt. 3.1.7 Data Recording Rogers et al. (2011, p. 227) mentions three different ways of recording data. It can be done by taking notes, recording audio and by capturing video. According to them, it is not always necessary to transcribe a whole audio recording since it can take up a lot of time, but it can however be useful when you want to write down specific anecdotes as an example. They explain that taking notes by hand is very flexible and is good for that reason, but that it can introduce bias from the writer and this should be minimized. Lastly, video capturing will most likely impact the participant since it can be intrusive. It is therefore a good idea to only record relevant actions to aid the goal of the study and be careful with the camera position. The video can be very useful afterwards because of its ability to play back both video and audio simultaneously along with the users facial expressions and reactions (Rogers et al., 2011). 3.2 Defining the Problem The underlying methods go in depth on how it is possible to understanding and dissecting all the data so you can have a well-defined problem. 3.2.1 KJ-analysis By first transcribing the information acquired in section 3.1, a KJ-analysis can be performed using the printed quotes. This is done by taking one quote and putting 11 3. Methodology it up on a blank space, such as a white board. Another quote is then read and also put on the board and if the two are in the same subject or can be related, they are placed together, if not, they are placed apart. This action is then repeated until clusters of quotes are formed. Headings to each cluster is formulated at last, to reduce the risk of wrongfully defining specific clusters early into the process due to personal bias’(Rexfelf, 2019, p. 20). 3.2.2 Specification of requirements, wishes and functions The requirements set on a product should not be too loose or too defined. This would make it hard to generate ideas. Setting the requirements should also be based on how the current market looks like, as well as the information and data previously gathered. They are expressed in the form of functions, and will be clas- sified as either real requirements, or just wishes (Österlin, 2016, p. 60). Functions are correlated to the requirements in such a way that they are all dependent on the goal and aim of the project. The main difference is that the functions drive solutions while the requirements eliminate solutions that are not fit. The aim and goal mentioned in section 1.2 also has to be taken into consideration since the final concept will be compared with these. A four step procedure on how requirements, wishes and functions should be specified can be seen in the following paragraphs. Step 1: Paraphrase or directly quote sentences retrieved from the data gathering sessions. The paraphrasing is a powerful tool to use when the chosen sentence is very long, messy or unstructured. Step 2: The meaning behind the chosen paraphrases or sentences can be seen as a requirement, if it is somewhat quantifiable, less abstract, and if the meaning aligns with the goal of the project. Step 3: If the meaning is somewhat quantifiable but not completely necessary to meet the goal it will be seen as a wish that can be graded based on its importance. In order to grade these wishes between 1 and 5 (where 5 is the most important) consistently, the scale in Figure 3.1 will be used. Here, the wishes from the users will be compared to the compare the goal of the project. To exemplify: If the wishes were completely aligned with the goal and highly wanted by the people they would get the grade 5. On the other end of the spectrum, if they were not in line with the goal and not particularly important to the users they would get a grading of 1. Step 4: Define the meanings as functions if they cannot be quantified in any rea- sonable way. 12 3. Methodology Figure 3.1: Picture of the scale that was used to grade wished from 1 to 5. Authors’ own picture, 2020. 3.2.3 Function Tree A function tree is used to get an overview over the functions that have been es- tablished and that define the product. It creates a hierarchy over these functions where the ones closer to the main function answers the question ”why?”, or in other words, what functions are needed for the product to work. Further down in the tree, the ”how?” becomes more clear. Here, there will be easier to find concrete solutions. In Figure 3.2 below, part function B serves as the main function for B.1 and B.2. (Österlin, 2016, p. 50).. B.1 for example, does not have to have any direct correlation with the real main function. Figure 3.2: Illustration of a function tree. Authors’ own picture, 2020. 3.2.4 Triangulation in research In the book Interaction Design Rogers et al. (2019) describes "triangulation" as a way of "fact-checking" yourself, by being able to make the same or very similar conclusions from multiple ways of confronting a subject or question. Rogers et al. (2019) further presents multiple ways of performing "Triangulation", the two 13 3. Methodology that are going to be mentioned here are "triangulation of data" and "methodical triangulation". They are described in the mentioned book as using both multiple methods and sources to be able to draw conclusions with high credibility. This will be performed as an iterative process resulting in refining both the Specification of Requirements and Function Tree. 3.3 Generating Ideas To generate a large amount of ideas one can use a variety of methods. During the entire ideation process it is important to be open and positive to all ideas regardless of how unrealistic or crazy they may seem, to be able to generate as many as possible (Österlin, 2016, p. 64). 3.3.1 Collective Notepad This method is mostly used along side a person’s ordinary work tasks and works by having a notepad available in which ideas are written down. For each day during a month, a new idea is supposed to be added into the notepad(Österlin, 2016, p. 65). 3.3.2 Brainwriting Brain Writing is done by sitting and effectively putting down all ideas for solutions to paper, both by sketching and writing. This will be done together but with as little discussion as possible in order to not influence each other’s ideas too much. The participants repeatedly work effectively for about 15 minutes, followed by a 5 minute break, until a big pool of ideas is generated or until no more ideas av available (Österlin, 2016, p. 64). 3.3.3 Brainstorming Brainstorming is done after the Brainwriting since it is a much more interactive method where the participants are using a shared surface for drawing to create solutions together. With the pool of ideas from the previous Brainwriting session as creative inspiration it is possible to come up with more novel and in some cases more refined ideas (Österlin, 2016, p. 64). 3.3.4 SCAMPER The word is an abbreviation for Substitute, Combine, Adapt, Modify, Put to an- other use, Eliminate, Reverse. The main idea is that the ideating group should ask themselves a variety of different questions in order to find new ways of looking at a problem or solution (Österlin, 2016, p. 65). SCAMPER can be a good method to implement if the ideation process slow down or start coming to a halt. 14 3. Methodology 3.3.5 Thinking Hats This method was developed by Edward de Bono and consists of six different coloured imaginary hats. When a group member pretends to put on a specific hat, they also have to look at the problem from a specific angle associated with that hat. This is also meant to help the ideating group see the problem differently in order to find new ways of solving it (Österlin, 2016, p. 67). Österlin (2016) describe these six different hats in the following ways: • White hat: Try to be objective and look at neutral facts. • Yellow hat: Be positive and look at the possibilities. • Green hat: Look at the crazy and creative possible solutions. • Red hat: Consider peoples intuition and the feelings involved . • Black hat: Critical thinking about the risks and weaknesses. • Blue hat: Thoughts about the actual work process (Österlin, 2016) . 3.4 Digital Prototyping In order to make the concepts come alive, interactive digital prototypes will be cre- ated. It will be done in a web-based service called Figma, were interactive software prototypes very similar to a real product can be created. This is achievable without the need to write any code (Figma-inc, 2020). 3.5 Evaluation of Concepts Stated below are the methods that are going to be used to improve and refine ideas into solutions worthy of placing in the Digital Prototype. 3.5.1 Not Invented Here Being able to Kill Your Darlings is a crucial when evaluating concepts. Meaning that it might be necessary to eliminate ideas that The Inventor have favored from the start, when it shows that they do not meet the criteria and requirements. De- velopment teams therefore often try to work under the illusion of that their ideas are Not Invented Here, to have a higher ability to maintain a critical mindset when evaluating (Österlin, 2016, p. 78). 3.5.2 Triangulation in evaluation Triangulation is most often used as described in section 3.2.4. Here, instead of us- ing multiple methods to acquire and fact-check different research data against each other, evaluation through triangulation is performed by analyzing an idea or a con- cept against multiple sources of recommendations for improvement. These sources can differ but it is recommended that the three following areas are represented: 15 3. Methodology • The project’s aim and goal. • Data gathered from user studies. • A Theoretical Background. Firstly, make sure that your solution is in line with your projects aim and goal. Secondly, check if it can be backed and confirmed by data gathered from user studies. Thirdly, find theoretical support for the proposed solution in general research to conclude empirical backing. The actual analysis is conducted through conversation between two to three people within the development team. A bundle of ideas that serve as solutions to the same function can be evaluated simultaneously where the developers work up to an agreement in regards to which idea meets the relevant criteria best based on the previously mentioned areas. It is important that the developers try to be as objective as possible during this step. 3.6 Improvement through iteration Johannesson and Persson (2013) emphasises the fact that very few products go di- rectly from getting their requirements specified to becoming refined products directly after. They further state the importance of performing an iterative development pro- cess where alternation between idea generation (see section 3.3) and idea evaluation (see section 3.5) is important, making the product more and more refined in each step. It can be done in each phase of the process starting with a general idea going down to every last detail (Johannesson & Persson, 2013, p.72) 16 4 Procedures and Results This chapter explains how methods were utilized and the results that came with them. 4.1 Effects of the COVID-19 pandemic This project was performed during the spring of 2020 and was therefore subject to the COVID-19 pandemic. This section conducts the changes that were made in order to be able to continue working. The overall conclusion is that user studies were affected the most by the pandemic, since the disease did not become a large issue in Sweden until the second half of the semester. Moreover, the project could be conducted online thanks to many collaboration services. However, a decision was made to minimize the amount of real life interactions with people such as family and close friend. This mainly affected selection of participants for the user study, the conduction of the focus groups and the categorization of the data collected. 4.2 Picking literature In order to select relevant literature to study for this project, a consultation meeting was held with Mafalda Samuelsson-Gamboa from the division of interaction design of the department of computer science and engineering, at Chalmers University of Technology. Based on the aim of the project (see section 1.2), she recommended not to focus on the users’ feelings, and instead focus on the elements that they would interact with on the website. Mafalda thereafter recommended specific chapters in a variety of books: Chapter 11-13 in About Face: The essentials of Interaction Design by Cooper et al. (2014), along with chapter 8, 11 and 14 in Interaction Design: Beyond Human Computer Interaction by Rogers et al. (2019). Lastly, Mafalda also recommended the book 100 methods by Martin et al. (2012) for cross referencing and quick summations of the methods in the previously mentioned books. The books Produktutveckling: Effektiva metoder för konstruktion och design (Johannesson & Persson, 2013) and Design i fokus: Varför ser saker ut som de gör? (Österlin, 2016) were chosen to support the methodology chapter of this report. 17 4. Procedures and Results 4.3 Sustainability analysis It is hard not to notice the boom in e-commerce over the last decade and its impli- cation of an increase in both global and domestic parcel freight. Sharon Cullinane at the University of Gothenburg have researched the logistics surrounding fashion e-commerce over the last couple of years. She states in an interview posted on the university’s website that she chose that specific subject due to the large amount of returns within the business area (Norrström, 2018). Cullinane mentions the emer- gence of a return culture where the consumer orders more products than he or she actually intend on keeping, with the thought of returning the sizes and colors they did not like. This results in Swedish return rates that range between 18 percent all the way up to 60 percent, although averaging out on 22 percent. Cullinane says the differing return rates correlates to differences in both consumer and product seg- ments, where the rates are higher with the younger than the old, with females than males and with garments associated with trends in relation to basic garments. The reasons to why consumers take so kindly to returning products is divided into two main reasons by Cullinane. The first is due to the operations behind the shipping of products being hidden from the consumer. People do not know that the jacket they are returning is being shipped to Poland for repackaging before coming back to the warehouse the consumer originally ordered it from. Cullinane reasons that the e-retailer can not take to much blame for doing this, since the margins in the industry of which they operate are slim and they have to limit their costs to be able to turn a profit. However, she also states that the companies could be a lot better at communicating this to the consumer, to enable them to make a more calculated purchase decision. The second reason to why the consumers have an easy take on returns Cullinane says is that they have a really hard time purchasing the right size or colour to begin with. She means that the websites are under developed and could be designed in a way that would help the consumer purchase the size that actually fits them to begin with, eliminating the need of returning a garment because of incorrect size choice all together (Norrström, 2018). Ridestore was contacted about their return percentages. They did not share their exact values but mentioned the industry average of being 30 percent. This value was deemed to be a bit on the low end in regards to Sharon Cullinane’s research. Therefore, an assumption was made that Ridestore most likely has a return rate higher than the 30 percent mentioned. The basis for this is that they have a young customer segment, a "free shipping and returns" policy, as well having the authors of this report viewing their products as being dependant on both trends and cor- rect sizing. Therefore, further assumptions were made estimating that the value of the total return rate could be in the upper margins of a 40 to 50 percent spectra. However, Cullinane mentioning that many returns are made due to the consumer not being able to pick the correct size finalized the return value, for the returns that solely were based on incorrect sizing, to 40 percent. Since it is in the authors’ belief that the additional 10 percent of returns are made for other reasons. In order to quantify this, the decision was made to calculate the approximate CO2 18 4. Procedures and Results equivalent that gets emitted when transporting 1000 jackets that each weigh 1,3 kg, from Gothenburg to the Polish city of Lódz and then back again. It is a 2400km round trip that was deemed representative as an average for re-packaging. To get an estimate of how much CO2 that would get emitted by transporting the previously mentioned weight that distance Klimatkalkylatorn by (AB, 2020) was used and the result was 219 kg CO2. This is a rough estimate that is only based upon 1000 jackets, the accuracy is therefore questionable and it was mostly calculated to get an understanding of what the emissions could be. However, the value is meant to only represent the jackets that are being returned by the customer due to incorrect sizing. It is therefore in the authors’ belief at the very least 219kg of CO2 emissions can be avoided yearly if a proper sizing service is added to Ridestore´s website. 4.4 How data was gathered and its output The following subsections are presenting the Proceedings and Results of each data gathering method used. 4.4.1 Heuristic Evaluation of the Current Configurator Proceedings: One Heuristic evaluation each was performed independently by both authors, using the methodology described in section 3.1.1 and later assembled into one document. At first, the Style Creator was analyzed repeatedly through the lens of one Heuristic at the time, writing down both pros and cons. Then one pretended style creation procedure each was performed, both ending with a make believe pur- chase, to produce an analysis with a high degree of coverage. Results: The results from the Heuristic evaluation was a list of negative (-) and positive (+) pointers, for each "heuristic bullet point" in section 3.1.1. The negative pointers would later be used for triangulation 4.5.3 while the positive ones stayed implemented on the website and used as reference for ideation. A list of what were deemed as "bugs" is also mentioned but not taken into consideration for improve- ment as they could be solved through better programming. 1. Visibility of system status − The brand filters are confusing to deactivate. − "Man/Woman"-buttons beside the Ride Store logo just affects the Style Creator and not the entire website. − The available sizes are not shown until you open the style overview. + The website is snappy with very little delays. + It has fast animations and a loading symbol when loading. + Deleting something from the style overview makes it disappears in the Style Creator. 2. Match between system and the real world. − The "save"-button does not tell you what it is saving. − The symbols for different product categories might be better placed as they are worn on the body, helmet icon in the top etc. 19 4. Procedures and Results − Clicking on a garment in the style overview could provide additional information, such as water resistance etc. 3. User control and freedom. − There is a lack of an undo or "show previous garment" function. 4. Consistency and standards. − There is inconsistencies between the brand filter and sorting functions. − There is not a need for multiple gender selectors. 5. Error prevention. − It is possible for the user to confuse the style examples on the website with the Style Creator. − All progress is lost when changing gender. 6. Recognition rather than recall. − The bar next to the product category symbols is easily mistaken for a scroll icon. − If a product is on sale, the price does not stay red in the style overview. + The symbols representing product categories are easily recognized. 7. Flexibility and efficiency of use. + There is no need for keyboard shortcuts, due to the amount of new/be- ginners that will use the website. 8. Aesthetic and minimalist design. − It is hard to understand that the user is supposed to click the price to proceed with purchase. + The website is minimalist in general with words as buttons, not much shading and many white areas. 9. Help users recognize, diagnose and recover from errors. − The "share"-button below the avatar does not specify that it redirects you to share on the style Facebook. − There is no information provided of how big the models are and what sizes they wear. 10. Help and documentation. + The help page is easily found with multiple ways of contacting the com- pany. Bugs to address • Filter drop down does not activate when the “select brand” arrow is pressed. Instead, the text to the right gets highlighted. • If the size of the website would adapt to the screen on the user’s device, there would be less need for scrolling the entire page. • Scrolling in the style overview with the size selection drop down open, does not result in the correct elements scrolling. • It is not possible for the user to share another style than the one that has been created and saved. • Some icons "light up" when hoovering the mouse pointer over them, not all. 20 4. Procedures and Results 4.4.2 User studies of current situation The User studies had two main issues to address. They were therefore conducted through two different methods, Focus groups and Think-Aloud observations, where the first was meant to give more insight into how users think when purchasing cloth- ing for winter sports and the second was intended to further analyze the usability of the Style Creator. Semi-structured interviews were also conducted with the par- ticipants of the Think-Aloud observations to acquire the most information possible. The selection of participants was made by asking possible participants if they "would consider purchasing winter sport clothing with a tool such as the Style Creator". If the answer was "Yes", they would be considered a fitting for being a participant. 4.4.2.1 Focus groups on winter sport clothing Proceedings: Two sessions were carried out with each author moderating one re- spectively. As mentioned in section (3.1.6), it is of interest to form focus groups containing participants with many similarities. The groups therefore only contained users of the same gender, to hopefully result in more in-depth conversations with in- formation of higher quality. The female group consisted of five people and the male group of four, where their ages ranged from 24 to 32 years old with the majority of participants on the lower end of the age spectra. To practice social distancing, the sessions were held online with the participants in a shared video conference call. Both focus groups followed the same structure and were screen recorded with consent, by using the program OBS (Open Broadcaster Software). They were initiated with a collaboration exercise where the participants were presented with a board of pictures representing a variety of clothing styles worn while performing winter sports. A website called Aggie was used as the interactive platform where the participants were allowed to draw on the same "canvas". The ex- ercise was successful with both groups interacting a lot to meet the goal of agreeing upon three styles they all liked. Since this exercise was mostly meant to warm up the participants and not immensely important for data gathering, the collaboration boards can be viewed in appendix as Figure A.1 and A.2. The moderator then tran- sitioned the conversations towards the remaining subjects. The first of which was meant to make the groups reflect around how they dress when performing winter sports, to prepare them for the last three questions that was meant to render more useful information towards the goals of this project. The questions and answers to these questions can be seen in the results below. Results: The focus groups resulted in recorded answers and discussions. Seen below are the three most important questions with a couple of paraphrases each that represent an overview of what was said for that particular question. The answers are paraphrased instead of quoted in order to increase their sensibility. What are your thoughts regarding sizes and winter sport clothing? • "You have to think through the entire kit, it’s not like I own ten different jackets 21 4. Procedures and Results and pants, so matching a new piece can be hard." • "If a jacket fits nice now, I’m not going to be able to wear anything under it on a cold day. So I’d rather it being a bit big, or having the possibility to try it with a lot of clothes under, before I spend a lot of money." • "I like to be able to move my arms without the entire jacket sliding up." How do you go about when you choose sizes online? • "I want to have a reference body. If it says that the reference is 185cm and is wearing a Medium, I would most likely buy the same size even though he is taller than me." • "I ordered two models in two different sizes each, I planned on keeping the one I liked the most. But I ended up sending all of them back." • "I read the customer reviews to learn if the garment is running big or small in the sizes. I think that is very important to have." What would be dream functions to have in a tool designed to help you chose winter sports clothes online? • "It would be nice to see, plain and simple, these are the differences between two garments." • "I want to change size of doll, give it my hair colour and spin it 360 degrees." • "I want to know how much other clothing I would be able wear under the jacket I’m looking at online." • "Reliable size recommendations from a big data base and previous purchases would be nice." • "I would like to see how the clothes compare to my measurements instead of the other way around." 4.4.2.2 Think-Aloud observation on current website Proceedings: Four Think Aloud observations were performed to further under- stand problem areas within the usability of the Style Creator. The two female participants were 24 and 27 years old while the two male participants were 25 and 58 years old. Both authors observed and instructed two sessions each where screens were recorded along with their commentaries. All observations followed the same procedure where the participants were presented with the front page of Ride Store and were then asked to find the Style Creator, create a style that they would want to wear in real life as well as decide upon what size they think would fit them. They were also asked to perform an imaginary purchase where they would continue to the point where they would have to enter their credit card information. When the participants where briefed with their tasks the instructor emphasised greatly that they where to think and act as if they were going to make a real purchase. Results: A great deal of problem areas arose where all users experienced some sort of confusion in different areas if the interface. To exemplify, all participants had some problems finding the Style Creator on the website, they activated filters unintentionally resulting in no garments being displayed, all of them accidentally undressed their avatar since they explored the gender selection, as well as being 22 4. Procedures and Results generally surprised at times of different interface behaviours. However, the two main reasons to why the user Flow got disturbed was that they either got lost in the interface or made a mistake without knowing why, the two main problem areas with the usability of the Style Creator found through this method are therefore concluded to be with navigation and comprehension of elements. Where navigation is referring to the user ending up in a section of the interface that they did not intend and comprehension of elements is referring to the user interpreting the meaning of different icons incoherently with how it is intended. 4.4.2.3 Semi-structured interviews regarding current website Proceedings: After the Think-Aloud observations, the same four participants where interviewed to further discuss their thoughts and feelings regarding the Style Creator. As described in section 3.1.4 all interviews followed a basic script that had the same rough structure before the Think-Aloud observation, but was altered after to better suit what occurred during the session. The interviewer also repeat- edly probed the participant with open questions to get a deeper knowledge of their thoughts. Moreover, to get a bigger knowledge base surrounding size-choice of winter sports clothing, the Semi-structured interviews also served the purpose of getting in- sight into the participants purchasing behaviours regarding that category of clothing. Results: The participants expressed frustration surrounding the areas discussed in the previous section (4.4.2.2) but were overall fond of the idea of being able to combine and try on clothes without going to a store. However, the participants emphasized their inability to know how the garments would fit their bodies based on the data they where presented with. One participant said "The Style Creator is actually not telling me anything else than just how the color combinations would look, since these models are thin as sticks". Two of the four participants said they wished to see the size selection earlier in the process and exemplified with wanting a filter to activate that would not show them garments that are out of stock in their size. In conclusion, based on these interviews, there is an emphasised need to be able to change the size of the avatar to increase the relatability and possibility of making calculated decisions regarding sizing. Other wishes from these participants was also that the women wanted to be able to try on clothes designed for men, but not the other way around. Moreover, the participants had a hard time navigating through the menus and they could not find the style creator as well as understanding the differences between "ski" and "snowboarding". Lastly, the users also wished for easier access to information about material properties of garments and better a overview of what garments and sizes are in stock in order to reduce disappointment. 4.5 How the problem was definied The over all definition of what this project was intended to accomplish is summarized in the Aim and can be viewed in section 1.2. However, the broad definition of the aim needed to be more precise so the developers could know what to do, that is what is achieved in this section. 23 4. Procedures and Results 4.5.1 Kj-analysis on gathered data Proceedings: The method for KJ-analysis explained in section 3.2.1 was used as the foundation for analysing the data gathered in the focus groups and the semi- structured interviews. It was decided not to quote the participants if they mumbled or did not say anything relevant to the task in hand, paraphrasing was therefore used to better emphasise the essence of what was said. To continue the social dis- tancing the digital service OneNote was used as a canvas (see Figure 4.1 where all paraphrases and notes from the user studies could be grouped together and analysed. The grouping of quotes and paraphrases was completed in two sessions on two different days. On the first day the focus groups were done and on the second day the semi-structured interviews. The grouping of data was then performed as described in section 3.2.1. Figure 4.1: Overview of the OneNote board where the blue and purple ellipses encloses the quotes (seen as small black lines) from the focus groups and the semi- structured interviews respectively. Authors’ own picture, 2020. Results: The KJ-analysis resulted in small clusters of quotes that represented a general opinion amongst the test subjects. These clusters where given words or summarizing sentences that could be later used for defining requirements, wishes and functions for the end product. 24 4. Procedures and Results 4.5.2 Compiling Functions, requirements and wishes Proceedings: The starting point to define the functions and requirements were the words and summarizing sentences that came as a result from the KJ-analysis (see section 4.5.1). These were modified in a google document so they could be more easily understood. Later, by using the method mentioned in section 3.2.2, all of the data was categorized in a google sheets document to get an overview of the of the functions, wishes and requirements. A major categorization was done to take a deeper look into the functions so they could be split up into potential main functions (HF), part functions (DF) and supportive functions (SF). This made it more clear for the authors to understand which functions were independent and which ones were building up others. Following this, the methodology for making a function tree (see section 3.2.3) was applied. Results: This resulted in the function tree that can be seen in figure 4.2. The part functions "Depict user", "Explain clothing" and "Guide the user" along with their sub-functions were thereafter used to form the the following requirements: Requirements: R.1 Give a relatable, editable, depiction of the user R.2 Show how different sizes of clothing would fit on one given body R.3 Enable effective comparisons between garment sizes R.4 Provide intuitive and responsive navigation R.5 Display elements that are easily understood Environmental requirements: E.1 Eliminate the all return shipments based on incorrect sizing or unpleasant fit The enumeration of the requirements and upcoming wishes does not indicate any specific form of importance. The numbers are only there as labels so it will be easier to find the corresponding [R] solutions in the upcoming chapter 5, and the answer to the environmental requirement [E.1] in chapter 7. Wishes with grading 5: W.1 Mediate garment fit on different body positions W.2 Show garment from multiple angles W.3 It should be a conscious decision to remove all the clothes from manikin W.4 Display all the available products in the style creator Since the solutions to all of these requirements and wishes in section 5 the choice was made to narrow down the list of wishes to the ones with a grading of 5 due to time limitations. The whole list of wishes can be seen in appendix A.3. With all of that said, it would of course be preferred to solve all of the wishes if possible. 25 4. Procedures and Results Figure 4.2: Function tree. Authors’ own picture, 2020. 26 4. Procedures and Results 4.5.3 Triangulating research data Proceedings: As described in section 3.2.4 the first step in the triangulation process was a compilation of the data gathered in the focus groups and the semi-structured interviews. This compilation resulted in the function tree that was analysed in con- junction with the heuristic evaluation and the aim of the project. After this analysis, the supportive function "Guide the user" (see Figure 4.2) was compared to the goal once more, which led to the realisation about its mentioning of "an increased website usability" that also had to be taken into consideration. It thereby had to be changed according to the next section. Results: The triangulation resulted in an alteration of "Guide the user" in the function tree (see Figure 4.2), turning it into a part function, which in turn made it necessary to declare requirements based on it. It also resulted in a change of the main function from the original "Mediate fit" to the revised "Mediate fit online". Consequently, this resulted in two new requirement as well as the removal of a previous one in the design manual (section 5. Moreover, further realizations were made that resulted in the requirements list in section (4.5.2) reaching its final state. Before this revision one requirement stated The garment has to mediate its fit. It was discarded due to it being deemed unnecessary since its essence was regarded as covered in R.2 Show how different sizes of clothing fit on the same body and R.3 Enable effective comparisons between garment sizes. Furthermore, the R.4 and R.5 requirements were also added in this revision and originated from the part function called "Guide the user" in 4.2. 4.6 The development process This section presents the development process, starting with the generation of ideas, following as they get refined and resulting in a finished prototype. blabla 4.6.1 The Collective Notepad in use Proceedings: The collective notepad method explained in section 3.3.1 was used mainly to improve focus during other parts of the project. For example, when the KJ-analysis (see section 4.5.1) was conducted, the conversations easily drifted to- wards discussing solutions to the problems expressed by the quote being processed at the time. Instead of risking a loss of both valuable time and the newly discovered ideas, the authors could easily write down their thoughts in the shared online doc- ument named "Collective Notepad". This document was later used when working with the Digital Prototype presented in chapter 5. Results: There are a total of 6 entries in the Collective Notepad that can be viewed in Appendix B.1. Two of the entries are discussing the low amount of shading in the Style Creator of today, that was later addressed and is therefore deemed the primary implemented result from this method. However, this method mainly resulted in a 27 4. Procedures and Results higher productivity when laying the ground work for the latter ideation processes. 4.6.2 Performing Brain Writing Proceedings: The generation of large quantities of ideas was performed in three sessions, all through the help of Brain Writing (see sect. 3.3.2) where the authors worked intensely in 15 minute instances with a couple of minutes of break time in between. The first session was the longest and most exploitative, focusing widely on all different angles of entry into the subject. The second was a bit more narrow, exploring different ways of navigation and lay outs of the "Style Creator". Lastly, the third session focused solely on different ways of making the Avatar pose. The reason to why there were three sessions was that some Iteration and Triangulation as mentioned in sections (3.6) and (3.5.2) was performed in between resulting in decisions being made refining the vision of what the prototype should be. Results: The results from the brain writing was an abundance of different ideas in the form of hand sketches and short texts representing and explaining everything from small features to the big overall layout of the Style Creator. A sample of the idea sketches from the first session can be viewed in figure 4.3. Figure 4.3: A sample of ideas from the first Brain Writing session. Authors’ own picture, 2020 . 4.6.3 Maintaining focus and spurring ideas Proceedings: When having trouble to come up with new ideas the authors mixed the essence of the SCAMPER and Thinking Hats methods from section 3.3.4 and 3.3.5. It was never said out loud to use one of the two methods explicitly, it rather happened organically and one author would for example say to the other "how do we Combine these?" or "is this Reversible?". Additionally, one author could take a 28 4. Procedures and Results more positive approach while the other maintained a critical view on the ideas at hand. Results: The method resulted in a more productive environment giving the pro- totype more refined features with high resemblance of the current interface of the Ridestore website. 4.6.4 Brainstorming for digital prototypes Proceedings: The method of Brainstorming (see section 3.3.3) was conducted in coalition with Digital Prototyping (see section 3.4), as well as with the use of the ideas from the Brain Writing sessions in section 4.6.2. The authors used the service called Figma to make rapid prototypes of the Brain Writing ideas, having the ability to quickly see if they were feasible or not. As well as easily improving the ideas into more refined ones, making them work better. Having the ability to be connected to the same work space while communicating via online voice call made this a highly interactive process, where the authors could get new ideas from one another and refine them by copying sheets and adding features or symbols as they pleased. Results: By getting a feel for the Figma service and generating a large variety of feature samples, the groundwork was laid for the upcoming Prototype. The re- sults from this method are therefore not very tangible since the lines are somewhat blurred in regards to where the building of the prototype began and the Brain- storming ended. However, this method was a crucial component in refining ideas into believable solutions. Two samples of what some early prototype frames looked like can be seen in figures 4.4 and 4.5 Figure 4.4: The right part of the image shows testing of different possible alter- natives for Ridestore’s current navigation menu between clothing categories (left image). Authors’ own picture, 2020. 29 4. Procedures and Results Figure 4.5: Testing the history display as well as size and color choice features. Authors’ own picture, 2020. 4.6.5 Refinement and Compilation of the Prototype Proceedings: When starting to seriously work towards a prototype, the workflow explained in previous section 4.6.4 was combined with the Triangulation in Eval- uation method from section 3.5.2. Below are all sources of recommendations for improvement with matching sections as they where used: • Problem Definitions - Aim from section 1.2, Specification of Requirements from section 4.5.2 and Function Tree from fig 4.2. • Data gathered from user studies - see section 4.4.2. • Theoretical Background - see chapter 2. Since the Requirements and Wishes where formulated similarly to individual prob- lems they could be focused on independently. Ideas generated from the Brainstorm- ing could therefore be evaluated and refined though checking them against the Re- quirements and Wishes. When a Requirement or Wish was solved, the solution was compared with data from the user studies along with the Theoretical Background to ensure empirical backing. As a final measure it was double checked against the visuals of Ridestore.se (see Figure 4.6). In the beginning there were a variety of solutions to the same problems, but these solutions were then triangulated through conversation between the authors. This process was later repeated with all of the previous bigger ideas. However, some gaps needed to be filled and the problems not solved though previous ideation got individual attention. As mentioned in section 3.6, developing the final prototype was an iterative process where the main problems was solved independently and later tied a little closer by each iteration resulting in a complete prototype. All throughout the refinement process it was emphasised to maintain a critical mindset, this was achieved through truly trying to regard the solutions as Not Invented Here as stated in section 3.5.1. Lastly, since this project was an improvement of an existing product and not a solution to a new problem, 30 4. Procedures and Results no individual complete concepts were developed and can therefore not be presented. The overall process is similar to laying a jigsaw puzzle, where parts of the puzzle can be solved independently and later merged together. The resulting prototype is brought forth in chapter 5. Figure 4.6: Screenshot from www.ridestore.se 2020-05-24. Authors’ own picture, 2020. 31 4. Procedures and Results 32 5 Proposal to Ridestore through a digital prototype This chapter shows the final product in the form of a digital prototype. It also explains how the design choices are based on data from the user studies along with the theoretical background. The digital prototype in Figure 5.1 is the result of all of the methods, theoretical background and all of the user studies. It can be seen and interacted with by going to the following link: https://bit.ly/configurator_prototype_2020 and works best on a 1920x1080 display while using fullscreen and selecting the option "100% - Display at full size" in the "options" drop down menu in the top right corner. The prototype shows a possible future evolution of Ridestore’s current style creator by applying the different requirements and wishes defined in this project (section 4.5.2) where the aim has been to show how different sized clothes can fit on different sized bodies, in addition to their purpose of how different pieces can fit together to create a style. The design decisions that have been made to create this prototype are supported by the user studies and the theoretical background. 33 5. Proposal to Ridestore through a digital prototype Figure 5.1: Overview over the current and remade style creator. Authors’ own picture, 2020. 34 5. Proposal to Ridestore through a digital prototype 5.1 Digital rendering instead of photographs As mentioned in the Aim of the project in section 1.2 the prototype is intended for when the Style Creator would be able to calculate the fit of a garment to a specific body. This is thought to be achieved by displaying rendered pictures based upon digital 3D-models of both the avatar and garment. Consequently, the model of the avatar would be generated based upon measurements provided by the user as described in section 5.3. However, in the examples in this thesis, manipulated photographs are still being used to show proof of concepts. 5.2 Moving the avatar to the left side As seen in figure 5.1 the avatar has been moved from the right side closer to the left, along with having its gray background removed. This was done to better follow the users Mental Model (see section 2.1), since western cultures read from left to right the user mental models are considered to be viewing information displayed on the left hand side as more important in regards to web page layout. Furthermore, the reason to why the grey background was changed to white was to reduce clutter and help increase user Flow as mentioned in section 2.2. 5.3 [R.1] Give a relatable, editable, depiction of the user The user can relate to the on screen avatar in different ways. One way is through body measurements and another is through other traits such as hair and facial similarities. One conclusion was drawn from the focus groups and the KJ-analysis (see section 4.5.1) was that people can have a hard time relating to measurements of the real model on the website, rendering them unable to base their purchase solely on how the garment fit the model. Therefore, in order for the customer to understand how the clothing would fit on their own body, they need to have an accurate depiction of their measurements. In the proposed prototype, users are initially able to select their gender (see Figure 5.2). 35 5. Proposal to Ridestore through a digital prototype Figure 5.2: Picture of a user hovering over a choice between selecting male or female. Authors’ own picture, 2020. This is followed by two different ways in which the user can create an avatar (see Figure 5.3). Figure 5.3: Picture of a user hovering over a choice between scanning their own body vs creating a more general avatar. Authors’ own picture, 2020. 36 5. Proposal to Ridestore through a digital prototype The first method of creating an avatar would be to use a phone camera or webcam as a scanner (see Figure 5.4). This technology is currently being used on websites such as tailorstore.com, but it would need to improve in the future in order to work well for this purpose. The method would result in a very accurate model of the user’s body, which would make it very easy for the user to understand the fit of the clothing when they are using the configurator in the later stages. The other alternative can be seen in Figure 5.5, and defines a more general avatar by letting the user enter their height and weight, followed by the usage of a slider to specify their most representative body composition that they feel are in line with their mental model (section 2.1). The displayed versions of body compositions would be generated by using existing data on how much muscle versus body fat a body can have on the given frame. This will ensure a quicker, but less accurate way to create an avatar for the user. Therefore, it is suitable to use this method if you do not have enough space to conduct the scan or if you want a fast, general depiction of your body. To clarify the Figure 5.5 further and exemplify more, imagine a user that enters a height of 180cm along with a weight of 100kg. In this case, the extreme values (slider all the way to the left/all the way to the right) would yield very different results. The slidercontextualizes information (see flow, section 2.2) by giving the user the ability to see changes to the avatar immediately which spares them the mental strain that would occur if they had to imagine the body composition by themselves. 37 5. Proposal to Ridestore through a digital prototype Figure 5.4: The different steps required for the user to scan itself using a phone camera. Authors’ own picture, 2020. 38 5. Proposal to Ridestore through a digital prototype Figure 5.5: A slider is being used to change the body composition of the avatar, where the rightmost image shows a body containing more fat whereas the leftmost displays a body consisting of more muscle. Authors’ own picture, 2020. 39 5. Proposal to Ridestore through a digital prototype 5.4 [R.2] Show how different sizes of clothing fit on the same body During the semi-structured interviews (section 4.4.2.3) it was mentioned that the static positioning of the avatar was appreciated when toggling between clothing. Participants in the focus group (section 4.4.2.1) also mentioned that the consistent lighting between the photos helped to minimize distractions, making it easier to focus on the actual clothing piece. This is also supported by the points made in section 2.3.1 about navigational excise between views. It was therefore concluded that the the fit of the garment should be the only variable factor that changes when the user selects different product sizes (can be seen in Figure 5.6). Thus, the avatar stays put while the the garment changes and adapts. Figure 5.6: Screenshots from the prototype taken for a jacket and a pair of pants in the different sizes small, medium and large. Authors’ own picture, 2020. 40 5. Proposal to Ridestore through a digital prototype 5.5 [R.3] Enable effective comparisons between garment sizes An issue regarding clothing in real life was addressed in the focus groups (section 4.4.2.1). The issue was that the participants needed to change between sizes of the same jacket many times in order to understand the differences of the two, which is a time consuming process. In this case, being able to effectively flip between the sizes digitally shows a lot of strength because it enables quicker comparisons than what is possible in real life. Figure 5.7: The size selection menu that is connected to the clothing category currently selected. Authors’ own picture, 2020. According to navigation between tools and menus (section 2.3.1.2), tools that are used very frequently should be visible at all times. The size selecting toolbar shown in Figure 5.7 changes dynamically through all of the different clothing categories, in order to save space and declutter the interface. 41 5. Proposal to Ridestore through a digital prototype 5.6 [R.4] Provide intuitive and responsive naviga- tion By giving the user an introductory quick start guide (see Figure 5.8 when they have entered the style creator they will have an easier time digesting the content of the web page. This avoids blank slates (see flow, section 2.2) by letting the user gradually get introduced to the style creator instead of just dropping them straight into it. It is however possible to skip the guide if the user does not need it. Figure 5.8: Cut outs that show the quick start guide that appears when entering the style creator. Authors’ own picture, 2020. Since people expressed having a hard time understanding the menus and the words "ski" and "snowboarding" (section 4.4.2.3) these menus were made simpler to min- imize navigational excise described in section 2.3.1.1. This was done by renaming the clothing categories so they included the word "winter", instead of having them ski and snowboard specific. Thus, the different categories at the top of Figure 5.9 would be compressed into one new category called "clothes" (swe: kläder). 42 5. Proposal to Ridestore through a digital prototype Figure 5.9: Comparison between Ridestore’s current main menu and the new, remodeled one. Authors’ own picture, 2020. Following this, the participants in the think-alouds expressed a lot of frustration about the navigational menu in the actual style creator (see figure 5.10 below). The previous way the website displayed the selected clothing category was not optimal, as it got mistaken as being a scroll bar. Additionally, the way that all of the icons used all of the vertical space on the screen made people believe that more icons could be hiding further down, which is not the case. Therefore, the icons got pushed up and the selection for the chosen category was changed to mimic a tab in order to provide signposts as mentioned in section 2.3.3. Lastly, the issue with not being able to view information about clothing in the style creator has been addressed. Previously, the users could only find this type of information in a very unintuitive way that would open up this information in a new browser tab that made the user feel lost. The new way that of finding information (seen in Figure 5.11 below) lets the user stay in control (see let users direct rather than discuss section 2.2) and ensures that they can maintain flow through (section 2.2.1) by having the information widow slide in from the right while the background fades into a darker colour. 43 5. Proposal to Ridestore through a digital prototype Figure 5.10: Comparison between the old and new menus for navigating between clothing categories. Authors’ own picture, 2020. Figure 5.11: The new way of viewing product specific information about clothes. Authors’ own picture, 2020. 44 5. Proposal to Ridestore through a digital prototype 5.7 [R.5] Display elements that are easily under- stood Drop down menus and buttons in Figure 5.12 were changed to follow Ridestore’s design system. They have been more distinguishable from the white background by implementing the drop-shadow and arrow-icon that is currently being used on some of their elements. This is referred to as affordance in section 2.4. The consistency among these elements will make it easy for the user to understand what they can interact with. Another part of the website that was hard for the participants to understand was the button that showed the price on the left picture in Figure 5.13, along with the cor- responding circular images underneath. The black button opened up a preliminary shopping cart, where they could choose to add the product to the actual shopping cart. When clicking on one of the circular images the user would get rerouted to where they selected that piece of clothing. In order to make the black button more understandable, it was changed into the actual shopping cart. As seen on the right image in Figure 5.13, the new button has a cart icon that also shows the amount of articles it contains. This figure along with the sum of the products gets updated every time the user selects or deselects a piece of clothing, providing the user with modeless feedback according to section 2.2, flow. Figure 5.12: A cohesive look for all the drop down menus and buttons. Authors’ own picture, 2020. 45 5. Proposal to Ridestore through a digital prototype Figure 5.13: The left picture shows of the current way of seeing selected products and the right picture shows the new way. Authors’ own picture, 2020. The ability to efficiently toggle between colours was very popular amongst the par- ticipants. In order to properly map controls to functions in accordance to section 2.2, the available colours of the clothing pieces were put on the product images them- selves (as seen below if figure 5.14) to represent the garments different available colours. Figure 5.14: Small colour dots in every product window represents the different available colours for that garment. Authors’ own picture, 2020. 46 5. Proposal to Ridestore through a digital prototype 5.8 [W.1] Mediate garment fit on different body positions Different body positions were made accessible through a drop down toolbar (see Figure 5.15 below), which makes it easy to hide in case it is not being used. This is to reduce the risk of cognitive overload for the user due to the amount of elements that visible to the user. It is good to keep the interface as simple as possible according to less is more in section 2.2 (flow). Figure 5.15: Difference between two different body positions, where the left one shows a normal stance and the right one shows one with the avatar’s hands over its head. Authors’ own picture, 2020. 47 5. Proposal to Ridestore through a digital prototype 5.9 [W.2] Show garment from multiple angles One way to rotate the avatar is by dragging it to the left or right with the mouse cursor as seen in Figure 5.16. Even though panning should be minimized according to section 2.3.2, it was implemented due to the potential upsides. It is an intuitive way to interact with the avatar that will give flow through animation (section 2.2.1), instant/modeless feedback (section 2.2), reduced excise by removing the need for more tools or buttons on screen (see section 2.3), as well as being in line with a users mental model (section 2.1) as long as they are used to this type of interaction. Figure 5.16: The rotation feature in the style creator. Authors’ own picture, 2020. 48 5. Proposal to Ridestore through a digital prototype 5.10 [W.3] It should be a conscious decision to remove all the clothes from manikin A deep frustration that occurred for the participants of the semi-structured inter- views (section 4.4.2.3) was when they accidentally removed all the clothes from the avatar when hitting the bottom left button in Figure 5.17 . Because of this, the ability to do this have been removed since it is good to hide ejector seat leavers (sec- tion 2.2). This was in turn replaced with a button that follows Ridestore’s design system. The button only appears on an item whilst it has been selected. Figure 5.17: The left pictures show the ways to remove clothing in the current style creator, where the user either clicks the entire item, or switches between the different genders for the avatar. The right picture show the new way of deselecting pieces, with a button. Authors’ own picture, 2020. 49 5. Proposal to Ridestore through a digital prototype 5.11 [W.4] Display all the available products in the style creator Figure 5.9 earlier in this chapter shows how the current website displays a menu with clothing categories that are not available in the style configurator. This can cause confusion for the customer since it might be unclear why other garments are available outside the configurator. In order to solve this, all of the products available for purchase on the website has to be included in the configurator. This would not change anything visually, since the products will be displayed in the same way as they are in Figure 5.1). It would however be an improvement of life for the customers since they would not need to worry about not seeing all the available products just because they are using the configurator instead of the "regular way" of looking at clothes. 50 6 Discussion This chapter will shed light on areas that could be possible reasons for error or disbelief in regards to the credibility of this thesis, along with the corresponding counter arguments to those reasons. 6.1 [E.1] Eliminate the a