Research questions
Technological
what are technical limitations of the configure/signing process?
What are technical limitations of the configure/signing process? | |
| Find out what the possibilities are between the design and development of the EBP Portal. The portal runs on a particular server which is handled by different stakeholders and can’t be adjusted right away. My goal is to find balance between clear designs and possibilities in development. |
Expert Interview - with back-end development. | |
| Expert Review Report |
| Answer from the head of the back-end department:“The data come from an outside source which does not provide all the options we want to implement. Actually, we are thinking to reduce the possible options because it is way too complex right now. That means we are trying to set up prefixed models so consumers get better know how. Peugeot Nederland creates a catalogus with all the options a specific model can get. These options are just written out, so without visuals. So if we want to overwrite it, it is only possible to implement textual content. We have started a project for this major problem, but you can guess it will take some time to implement because of all stakeholders interests and money.” |
For the outcome of my project I am willing to challenge my client to create two different prototypes. One with visual support and one without. In that way I can collect test results and analyse it to see which users like more. If, in the end, the one with the visual support is more popular I can show them the results, and ultimately they are more willing to move forward with this project. |
User
What are the main problems with the configure/signing process?
What are the main problems with the configure/signing process? | |
Find out what the portal lacks (e.g. errors, bad affordance, no states, weird flow) when configure a car at the employee benefit program portal | |
Usability Tests | |
Test Report | |
Throughout the first test I gathered a lot of first hand problems. First of all, the flow was really important. The users did not understand the reason why they had to choose between a gasoline or diesel motorisation and later on had to choose for a variant/version. Next, the users showed weird responses when seeing unfilled or inconsequent defaults. It simply made them feel confused. | |
The first tests showed useful insights. The insights sketched a detail view of how users would use the product. The most important part of the problem, as I assumed, were the states and guidance through the process. The first high-fidelity prototype should provide these essentials at first hand. |
How do users experience the configure/signing process?
How do users experience the configure/signing process? | |
Find out what the target group needs and wants are during a configuration process. | |
Literature Study + Participant Observation | |
Persona’s + Customer Journey | |
The two literature studies have shown that users perform certain behaviour and how to guide them through a process. Firstly, Steve Krug’s Don’t Make Me Think described all the information that I need to create a usable product. Second, the persuasion and MBTI study defined specific user behaviour while making a purchase or using particular service. As last, the participant observation was a real eye opener. The answers users gave about their experience with a service like EBP were incredible. As one part really spoke about usability, others spoke about how to improve user experience by adding little details such as better thank you pages and how to provide information through the process. | |
The findings validate all the required knowledge |
What motivates users to stick to the configure/signing process?
What motivates users to stick to the configure/signing process? | |
Find out how to let users stick or let them return to the make a purchase/sign a contract | |
Literature studies | |
Wireframe | |
Throughout the BJ-Fogg model I found out that users need three different aspects: Motivation, Ability and Triggers. If all three aspects are in place, behaviour is likely to occur. When one of the three is missing users, at some point, will leave the process. | |
The BJ-Fogg model is one thing I will carry with me the rest of my design career. It seems so simple, but, from own experiences, a lot of digital products lack these standards. I will take these theory into account when designing the configurator. |
What motivates users to complete the configure/signing process?
What motivates users to complete the configure/signing process? | |
Find out how to persuade users to finish the process. What is triggering them to make decisions and how to convince them to make that decisions. | |
Deskresearch + Survey | |
Job Stories | |
Throughout my deskresearch I found theories about persons behaviour. According to the BJ Fogg model, the best way to hook users is to influence user behaviour and create habits. The model explains how users behaviour is influenced by three main aspects. Motivations, ability and triggers which can be written in the following format: Behaviour = Motivation x Ability x Trigger. When a desired behaviour does not appear, at least one of these three is missing. | |
Together with behaviour model and the insights of the survey I can conduct different job stories that can help me design a better EBP. |
Context
How do users behave during the configure/signing process?
How do users behave during the configure/signing process? | |
Find out how user respond to certain designs and flow, to ultimately find the best solution | |
Data analysis | |
Requirements list | |
The data analysis showed some corresponding results. At every configurator the bounce percentages were almost the same at certain steps. The car option and version options showed some really high bounce rates which were not odd. The designs lacked affordance and guidance which can be overwhelming for users. | |
This analysis can not predict all the behaviour. To define all behaviour I will carry out user tests with the first designs as well to gather more information. |
How do users use the portal per device? (Mobile, Tablet, Desktop)
How do users use the portal per device? (Mobile, Tablet, Desktop) | |
Find out what user do in different context (e.g. waiting in line or using public transport) | |
Data analysis | |
Requirement list + Contextual mapping | |
Throughout the data analysis I found out that users have different behaviour per device. Firstly, tablet has the least users at every device. Second, users request more offers through mobile than expected. Desktop are still more, but mobile take up a third of all offers. The flow per device is also a bit different. Whereas users mainly exit the pages more random at mobile, users tend to exit more constantly near the end. | |
The behaviour of user can’t be predicted for a 100%. Research shows that these patterns in behaviour but every user is different. The findings show some of these patterns but the better insights will come from user tests later on in the project. |
What are strengths and weaknesses of the competitors?
What are strengths and weaknesses of the competitors? | |
Find out which other configurators work well, and find out what mistakes other configurators made before. | |
Competitor Analysis + Best practices | |
Requirement list | |
Nowadays there a dozens of examples. The configurator database websites facilitates all sorts of products which can be personalised. I made a wide analysis of direct competitors such as Renault and BMW, but also used other products to see what I can learn form their point of view. (eg. bikes and phones) | |
The findings validate all the required knowledge |
Last updated
