Driver Feedback Portal
Empathise and identify pain points
In order to understand the user you need to do research and during this project it was in forms of interviews and collected comments. I entered the project in the end of this phase. My task was to get updated on the matter and decipher the inputs in order to understand the users desires and pain points.
Because the idea of replacing the existing reporting tool witch was highly disliked, the idea of doing a new app was born. But after a lot of discussion, the decision of integrating it with the existing Volvo Car App (VCA), was the best solution. The idea of having it as a Portal in the VCA was to lower the mental barrier, make it easier to report and also remind the drivers of the program.
Ideation
The ideation could have different formats depending on the features we worked on. The brainstorming session usually consisted of sketching sessions which we had as a base of discussion.
We also had a big feature which we called “feedback”, where we had a workshop where we tried to figure out what is the best way to give feedback or engage the drivers. In the end we together placed them in a roadmap to see which ideas where easier and harder to do and implement.
The Portal allows chosen Volvo employees to submit feedback regarding Volvos products and services in form of issues, ideas or praise. It is a part of the existing Volvo Cars App. The goal with the portal is to create a sense of community where employees can together help Volvo improve their products and services. The Portal can collect data from the car when needed, follow up on tickets the user has sent in and share information about the improvement they contributed to.Because this was a MVP product, the functionality was quite limited. Before I ended my assignment I had time to work on features such as gamification, surveys implementation and 2-way communication.Wireframing and prototyping
After a brainstormed feature, I took the sketches and created wireframes. This was a phase that went through a lot of iteration. It could either because of good discussions or results from tests we did.
The main tool was Figma and because we used Figma, we did the wireframing and prototyping in the same place. This ment that we could do quick prototyping for the tests we did.
A/B test and Usability test
The majority of the features in this portal was either A/B or Usability tested. This mean that we introduced real users which we tested out our designs on.
First we decided the goals with our tests and based on that created scenarios. During the tests there was one facilitator and one observer. The users tested one concept and after answering some questions (and sometimes questioners) they tested the other. Not always the same order of course 🙂 When the tests were done we sat together and analysed the result and made decisions based on the findings. Then it was back to the drawing-board!
The usability tests made was to confirm that the decisions we made was easy to understand and is in the interest of the user.