Shipped
Caraid Developer Portal
Organisation
Cariad (VW Group Company)
Team
Scrum Master
Business Owner
Product Owner
Product Manager
Integrator
2 Frontend developers
3 Backend developers
2 Designers, including me
Responsibilities
Revamping persona
User interviews
Synthesising research
Product Strategy
Ideation
Prototyping
User testing
Developer Handover
I redesigned flow to add APIs to minimize support inquiries by VW and its brands. Additionally, I incorporated a ticket form to gather future feedback and smooth out the communication between the ID and VW teams.
*To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.
All information in this case study is my own and does not necessarily reflect the views of Volkswagen.
Challenge
The Developer Portal is the first and crucial step for integrating Identity Kit services into an application. It helps brands set up consent documents, data collection purposes, and more. However, the process to reach the final stage is complex. The dependencies of products are unclear, leading people to guess why it's not working. This results in an increase in tickets or trials to fix it, and also increases outages. Additionally, services are not properly grouped together based on their purpose, making it harder for teams to understand.
What's Developer Portal?
Developer Portal — works as a services marketplace, allowing VW teams to quickly generate client IDs, add legal docs and set up information for users and voila! get an application GDPR compliant in minutes.
The application is not just limited to mobile and desktop, but also car applications as the front door for all the consent setup.
More about Portal Usage
4
global regions
30k+
Users
500+
applications managed on portal
First thing, we wanted to take pressure off the team by streamlining the communication process by the Brands
Brand teams are aware of team structure and would reach out directly with the developers which sometimes burnout the team or adds context switching to them.
Streamlining the process will also give information on what areas of the product needs more improvement and if we bring in any future updates, we would know through user tickets as well what areas are problematic.
Now back to: "I am losing time solving support tickets than on the tool tickets." -Developer, Identitykit
We saw rise in support tickets after the addition of new products in API marketplace and as our user base grew with more and more brand teams shifting to Identitykit login solution.
And Developers of the team had to go for different brand team rescue point as they had most knowledge on the tool which started going against the mission of "building applications in minutes".
Project goal
Refining the flow to add projects to the application to generate client credentials.
Key Metrics to track
Significantly reduce the dependence on developers and support team of the brands to create applications by Q2.
Increase adoption of the tool among brands seamlessly and ensure a 100% setup completion rate
Achieve a 90% satisfaction rate in post-setup surveys
Problem Breakdown
39%
people reported difficulty in discovering APIs they require
60%
increase in support requests because of missing setup details
59%
users reported not able to figure out which authentication feature to use in the application
What we learned
"I added the API but it didn't work and support team helped me out, turns out I missed adding a pre-requistic API." - Alicia, Developer- Skoda
Problems of our personas changed.
We connected with our users to understand the problems and their impact on the flow to prioritise the risky areas, in between the process, we realised the problems of our personas changed and we summarised and updated our personas with the interviews.
Confusing pits in the journey map
so what are the new problems that Kate is facing?
We connected with our users as well to know their pain points in the journey before we created this journey map.
Main Identified Problems
01.
Confused between APIs services and, authentication features and when to use
02.
User flow is not guiding/relevant enough.
03.
The documentation is not fulfilling the needs of the user.
Not only new users, but experienced users feel equally confused on which authentication type to use and how to differentiate between authentication and services which will provide client IDs
How can we help our users see distinction between different product APIs?
With the team, we could put all the services under different categories. For the simplicity of the tool at the moment , we decided to put two levels of category division.
Information should be shown in a systematic manner to help users take faster decisions.
Users who are arriving on the platform don't have full information about the services, in most cases they are aware of the usecase and with hidden requisites and other required information needed to take an action, user either misses out important information or might add wrong services.
Guiding users through product variants
Our current system doesn't show users when product is already added in the application and will just show an error message "failed to add" without any further information. This made us think in direction of making our product card self explanatory.
After product card, we changed product page to help users scan the products and quickly identify the API types
The goal of the new page is to help users distinguish between authentication features and add on services, as from research we identified that most of the time this page has high friction in figuring out if they are adding the right product.
Main Challenges
01.
Confused between APIs services and, authentication features and when to use
02.
User flow is not guiding/relevant enough.
03.
The documentation is not fulfilling the needs of the user.
Our users can feel very lost and abandoned when going through the user journey to add APIs and self services in the portal
Insights from the interviews:
The end goal is to get client IDs, and hence users only look for services they are asked to add, missing out on authentication features.
Allowing users to multi select products or dependent products rather than one
Our current system only allows one product addition at the moment, this 1-1 addition also gives users feedback that there are no dependencies among each other and they miss out on adding pre-requisite services.
In case user misses out any dependent product, system adds it for them.
To make it easy for users, in case if they miss out the dependency product, system will add it automatically in the product cart, user has freedom to remove it if they want.
Main Challenges
01.
Information Architecture is not guiding/relevant enough.
02.
Confused between APIs services and, authentication features and when to use
03.
The documentation is not fulfilling the needs of the user.
Users get confused by error on setting up products right after adding them.
Insights from the interviews:
Users expect tasks to be completed after adding products to the application, they are left confused with current content for next steps.
Using UX writing to guide users in setting up client IDs.
Dividing the features setup by letting users know the next step, highlighting the authentication features as top priority to setup credentials which are used by add-on features.
Taking away the fear of clicking and breaking things in production
Current design doesn't have any precautionary step before major actions which makes non-developers or new users to avoid the platform.
Connecting the dots of the journey with next tool by allowing users to take action.
In the consent cluster, we also wanted to start moving forward the bigger picture of the product vision to have a single source to manage consents. We added the link button to start testing out our next set of assumptions to move in that direction.
The impact
This feature was rolled out for Volkswagen and its brands (Audi, Skoda, and Bentley) to create applications and was appreciated in multiple demo meetings.
The creation of applications flow became faster and self-guided by the addition of features directly in form of a proposed marketplace catalog and the cart system.
The integration of a form as a communication channel helped in getting data points for future iterations and frustration points, by allowing the team to get feedback/ticket support for categorised themes in the form.
The support ticket requests/emails and direct messages to the team and integrators got reduced by more than 80%. Previously, integrators had to handle at least 5 requests daily for different teams in different brands.
Reflection note
Just because they are internal tools, it's not an excuse to be sloppy and lazy with the design.
Developer tools are a challenging and rewarding design challenge. Delightful interactions and saving time are appreciated, be it internal or external tools. Allowing internal users to have an amazing experience creating application for external users, allows them to create beautiful experience for others as well. It makes teams value design more.
Let's talk design?