Overview
PostNord is a large logistics company operating in Sweden, Norway, Finland and Denmark. They have a business portal where companies track their parcels and all other feature. One of the features I was assigned to is the Claims Business app, where users can create a claim for delivery issues and damages.
Key Takeaways
After seeing how the whole process worked, I reviewed it carefully and found out that there is a missing link. I proceed to conduct service blueprinting because I want to map out the different teams that get touched by the claims process. Out of this I soon found out that I need to talk to the team reviewing the claims because they are the ones who make decisions on whether to approve or decline.
The big surprise
When I plot the claims process, I noticed that the team reviewing the claims are discounted in the process by tech stakeholder. So I organized a focused group discussion over teams with 3 managers and one from leadership and learned that they are disconnected from the digital process of claims. I was already warned by my manager that they attempted this meeting before but failed because most of the team there resist using new technology. And are unaware that PostNord has an online portal where they are actually getting the claims requests. I have to explain to them where the claims process starts, and how it ends up in their bucket for them to review. It was a surprise to them, and they appreciate their value even more knowing that they are one of the most important people in the claims process.
key Takeaways
The PostNord team reviewing claims makes use of data and documents they received with the complaint but according to them, they require specific documents with specific qualities in order for them to review the case effectively. Otherwise, they will send an email requesting those documents back, and this leads to a back-and-forth conversation which slows down their review process. As well as dragging the results from the users. The lack of documents forces them to put cases on hold until the right document is provided, otherwise, they are forced to reject the claims.
Research
I have conducted a series of focus group discussions with our business customers to know their thoughts and pain points in using the Claims app. To supplement the needed data, I run a poll in the claims app which will cover quantitative and qualitative surveys. Below are the screenshots of the data gathering method using Hotjar survey.
User insights
Below are the user insights I have uncovered from the focus group discussions with our users, and the survey I have conducted.
Claims business landing page
The goal is to only show high-level information to allow the users to make a decision fast. Whether that is finding the create a claim button or identifying the claims they want to follow up on.
- Just enough information.
- Cluster details according to a specific use
- Allow users to export doc about a claim anywhere in scroll port view
- Just enough information.
- Cluster details according to a specific use
- Allow users to export doc about a claim anywhere in scroll port view
Create a claiming flow
The claims creation flow is very important in the claims app because this is where information is gathered which will be used by the PostNord review team to make a decision to decline or approve the claim.
- Guide the user with needed information
- Show a list of documents and specifics about the documents the review team needed
- Guide the user with needed information
- Show a list of documents and specifics about the documents the review team needed
Claims status page
After a claim is created, users want to verify if they have really created a claim. So this claims status or claims details page should communicate information about the claims and updates on phases of the claims review process. This is also where the users can send messages to follow up with the review team.
- Hide information that may not be needed, like parcel information, but allow users to show it on-demand
- Cluster the location of status updates, messages, and notifications so that users will only check in one area.
- Hide information that may not be needed, like parcel information, but allow users to show it on-demand
- Cluster the location of status updates, messages, and notifications so that users will only check in one area.
Visual Design
After doing discovery sessions, workshops, user research and wireframe, I slowly worked on the visual design utilizing the existing components while creating new ones that are not yet available. Below is a sample, the rest are shown in the Compare section of the old and new.
Compare
This side-by-side comparison aims to present the improvements made from the previous version. I added an explanation at the bottom to articulate the intention behind the change.
Key takeaways
Empathy is key
Immersing myself to the user’s perspective made me understand what were important to take note and be able to shape the design around users’ paint points.
Documentation helps
Being in an agile environment means that the process should be calculated to have optimal results, it is prudent to do documentation on the side to help with decision-making the future.
Soft skills
Being able to present my ideas and show the value of design is really a game changer and makes it a lot efficient on navigating through arguments, and turning that into productive results.
Trust your gut but be objective
Trusting your gut is the quickest way to move forward in the design process but it is also prudent to be objective and not be swayed by biases.
What went well
Shape the process according to the project need
It is imperative to adapt the design process according to the needs of the project and the time required to finish. I was able to adjust the design process according to what is required in each phase.
getting a response from BUsiness stakeholders
Booking a meeting with stakeholders proves to be hard to come by since they are mostly busy, so we set a weekly meeting with them to talk and demo the design. It became a good avenue to discuss rules that apply in Norway, Denmark, Sweden and Finland
What would you do differently?
Do more meetings with technical stakeholders
When gathering requirements, there are times when the person in-charge of the tech may not have the ready information you need and sometimes you get pushback later which was not informed beforehand. This became a huge friction during the process because it caused me to go back and forth on the design because some end-points are not available.
