The Journey at NEVS.
Feb 2020 - Nov 2021
Close to 2 years spent at NEVS Trollhättan, was when I got to work closely with electric and autonomous vehicles, cities, and services, to shape mobility for a sustainable and exciting future.
- Worked in teams (from 2 to 4 teammates) as well as individually.
- Followed a company-wide Scaled Agile (SAFe) framework.
DISCLAIMER: All images used on this page are only for story-telling purposes and purely for representations. Some images are taken from nevs.com
My Roles and Responsibilities
Building Use Case Scenarios
For the first three months at NEVS, I was involved with the Business Modelling team and worked with a User Strategist in creating use case scenarios for the autonomous vehicle- 'Sango'. A vehicle prototype was already being done by then.
Our responsibility was to develop this idea and find out more opportunities and situations where PONS could become a complete mobility solution. This essentially became a top-down approach.
What we did:
- Brainstormed ideas.
- Studied different types of journeys, users, their requirements, service area, and journeys during different times of the day.
- Identified different service areas where PONS could become a potential mobility service. Detailing the reasons for selecting these areas and identifying the partners to work with.
- Categorised the different services.
- Had dialogues with potential business partners and pitched the idea of PONS.
- The responses and feedback were collected and presented to the entire Mobility Solution team.
The Challenge I faced:
A top-down approach was new to me as a designer and found it difficult to justify what we are doing.
How I overcame the challenge:
Through a thorough design research process, I studied the product (the autonomous vehicle) and found out the user groups and the types of services and partnerships possible. I was then able to convince the product and function owners of the changes that need to be made in the vehicle in order to create a pleasant experience for the users.
Building Strategies for Pilot Deployment
Soon after, I worked with Mobility Strategists and helped them by researching the different cities for PONS to be rolled out in the next 10-15 years. The tasks, however, were done individually.
What I did:
- Studied different cities in Europe, US, and China. Identified many different indices and city rankings and their reasons.
- Identified as well as created parameters for cities on their 'Readiness for PONS Service'.
- Studied the relationship of Public Transport Authorities (PTA) in these cities to the different mobility services that already exist.
- Summarised the study to indicate: which cities to be considered, how they perform in the parameters, what 'category of progress' they fall into, how liberal is the PTA, which type of PONS service is best suitable for that city, and the recommended year for deployment.
Example of Parameters:
Vision & strategy
Maturity of MaaS
Regulatory environment
Transport affordability
Sustainability initiatives
The study was summarized in the form of infographics. An example is shown below.
The cities in comparison were also mapped out on the basis of Market regulations and Innovation Initiatives.
The outcome of this assignment was well appreciated and is considered for creating the future business models for NEVS.
The Challenge I faced:
I was not confident enough about handling such a fundamental piece of data, on which the business models are developed.
The Learning:
With the help of my senior colleagues, I regained my confidence in myself and was convinced that even an entry-level member of the company could direct the company with valid data and reasoning.
Service Design
As soon as the previous task was completed, I was required by the design team to help them out with the design of the service itself. As a designer coming from the Business Modelling (BM) team, I was acting as the bridge between these two teams. The task of designing the service needed a lot of input from the BM and I was able to provide them when it was required.
What we did:
- Helped in facilitating a Customer Journey internal workshop.
Purpose:
Identifying different types of journeys and journey needs.
Identifying what users are going through at different stages in their journey.
Reframing some of the personas which were created earlier.
- Talking to different stakeholders, and back-end services and understanding their needs.
- Stitching a service together and creating a Service Blueprint.
- Identifying gaps between the needs of different types of services and vehicle modes, and the capabilities of actual vehicle prototype (example: secured entry).
Sango has three different modes:
- Clearly defining the edge-cases (including emergency), vehicle, system, and operator actions. Actively participating in the inter-team discussions, to understand their needs as well as being a voice of the end-user.
The Challenge we faced:
It was really difficult to have a complete picture of the service since most of it was still in discussion.
The Learning:
I learned that we have to keep coming back to the materials we created to update them according to the new developments that happen. It is a cyclic development process and it will never get 'finished'.
UX/UI for Digital Assets
From the Service Blueprint, we had identified what digital assets would be required to complete a successful ride. As a natural progression, I was involved in the development of UX for those digital assets. The first task was to redesign-
1. Fleet Management Web App
A previous version of the fleet web app before it was redesigned.
It was important for us to understand the needs of the Fleet Managers and Maintenance personnel to design the app.
What we did:
- Worked with the fleet managers and others involved to create a complete Information Flow.
- Created separate information flows for 'sunny day' cases, maintenance, emergency, and other edge cases.
- Mapped the Fleet Web App system to identify which entity interacts with the app in what way.
An example of what we did for a system map of Fleet Web App
- After that we started with wireframing.
- Low to high fidelity prototypes.
- User testing and feedback at each stage of development.
The Challenge we faced:
People from different teams have different perspectives on the project and they sometimes may not see the user's perspective.
The Learning:
I learned that people could have really different takes on the same project but we as designers, need to help them see the user's side by creating suitable narratives.
2. End-User Mobile App
We began by analyzing the UX of a previous version of the developed app. This was to understand what all were considered before and what was missing in the design of the app.
A previous version of the End-User Mobile App before it was redesigned
What we did:
- Analyse the previous version of the app and created insights that needed to be incorporated into the new version of the app.
- Boiled down to the fundamentals of app and app designing- By questioning each and every aspect. Asking 'Why?'s.
- Explored new directions for a mobility app (example: Can the user start at a different point than location on map? like selecting number of passengers or preferred ride type) and iterated some ideas.
- Evaluated the ideas based on constructed parameters (example: number of steps to achieve the goal, ability to understand the complete information)
- Selected the idea which was found optimal and started with wireframing.
The team formed a 'Cyclic & Co-dependent Design Framework' through which we could make sure the changes that happen during one stage reflects on the other materials that we created earlier, so that all the different materials are up to date.
For Example, There were many changes to the Information Architecture while we were developing the wireframes. Those changes were updated from time to time. That in turn resulted in updated the Information blueprint and Service blueprint.
What is an Information Blueprint? (Click to Zoom)
Example of an information blueprint from the start to the end of an autonomous ridesharing service:
It is essentially a part of the service blueprint, zoomed in at the different touchpoints. An Information blueprint gives the overall picture of the user journey separated into different events, their thoughts and desired experiences. Further, on the touchpoint level, it shows how the different touchpoints interplay with each other, what information they show to the user, and how long each touchpoint is going to be.
The information blueprint, as reference material, was appreciated by the people across different teams.
- Wireframing the mobile app.
- Low to high fidelity prototypes.
- Multiple user tests and feedback sessions at each stage of app development.
- UI design of the app and creation of design elements and library.
The Challenge we faced:
It was really difficult to know what are the different touchpoints, especially when the service itself is a bit unclear and continuously developing.
The Learning:
We have to find new methods and materials to create better clarity for ourselves and thereby help others have better clarity about the service.
3. In-vehicle Screen
A similar approach to the mobile app was used for designing the In-vehicle Screen. Most of the context of the operation of the in-vehicle screen, however, was still in the early stages of development.
- Defining the screen size, and position of the screen in the vehicle.
- Wireframing.
- Low fidelity prototypes.
- Multiple user tests and feedback sessions at each stage of development.
Retrospection
The 2 years at NEVS had its ups and downs, just like any other place. But in this short time, I got a nice opportunity to wear multiple hats as a mobility designer and flex my capability to zoom out and see the big picture- the entire PONS mobility solution and zoom in, for example, to see what color a button should be.
NEVS gave me the chance to showcase the learnings my education gave me and at the same time created moments for me to learn new things and grow in the company.
To top it off, I met some amazing people and made a few good friends.
