Introduction

The client administers all social insurances of the first pillar on behalf of the federal and cantonal governments and is spearheading the digitalization of the publicly mandated insurance sector. For their next step, they want to provide a central service for all their customers' needs. For this step, they’ve started a public tender to find a consultant who can help them build the envisioned service.

The project is a one-month-long proof of concept where we build a simplified customer service portal that displays just the essential customer information while providing a restricted set of functionalities to facilitate user navigation and interaction. The RFP (Request for Proposal) is being executed in parallel to our ongoing client projects. After the final presentation of our work and a short operational phase, the client decides on a consultant to build their platform.

Problem

Usually, the problem that requires a solution stems from the client and their customers. In this scenario, however, the problem is defined as how do we show the client that we are the partner they want to collaborate with.

Goal

To have built a product according to their specification and present ourselves in an honest way to convince the client that we are the right partner for them.

To win client trust, we keep our process fully transparent and communicate honestly about our progress and the issues we encounter.

To present the client with our unique value proposition, a dynamic and motivated team that goes the extra mile.

Solution

Due to the strict timeline, the customer portal will only have the most basic functionality, with the mobile version even more limited.

As design and development start concurrently, the first design version (UI 0.1) is heavily simplified and built in close collaboration with the front-end developer. One of the biggest risks is not having a working proof of concept at the project's end.

With the remaining time, a design outlook (UI 0.2) is created to be shown at the pitch presentation to more accurately represent a possible design solution for the customer portal. UI 0.2, with more focus on usability and appealing design instead of pure implementation speed, is being created as a Figma prototype.

To achieve all our goals, we invite our client to fixed meetings and deliver periodic progress updates, including planned, ongoing, blocked, and finished tasks, but also encountered issues.

Strategy

Process

Due to the nature of RFPs and the limited allocated time, following the usual product development process is impossible. Design, software development, and DevOps start simultaneously, where task management is handled dynamically. To optimise efficiency and ensure all requirements are covered, we established a kanban style board for all tasks and in which every requirement is referenced to a task as well.

As design work is limited to 5 working days and the front-end developer needing the first screens right away, design starts to ideate and build heavily simplified UI drafts which are quick to implement. Once front-end has a buffer to work from, design will start in parallel to develop a version with a more user-centered concept and appealing visual design.

v0.1 versus v0.2

To reduce development time, all version 0.1 screens are built exclusively with MUI components, while version 0.2 only uses them for standard inputs. In the rest of v0.2, the design is built more freely and better adapted for the client's users.

Landing Page

The landing page is built with a very simplistic layout, while the majority of the customer portal information is presented on the landing page itself to reduce the amount of paging and complex routing, as there is not enough time to develop such a system.

A similar approach has been used for the mobile application, with the exception that a more complex page routing in 0.1 was unavoidable.

For continuity, the overall idea of 0.1 has been kept, but the information architecture has been reworked to be more user centric and the overall presentation cleaned up to better reflect the user demographic and be more welcoming.

Detail Page

For the detail page in UI 0.1, the landing page will be reused, therefore the notification and quick access is still visible.

UI 0.2 focuses on the actual content. The mobile version only gets a minor visual update.

Third party integration

One requirement was to considering integrating various third party tools, from which the user can choose the most preferable one.
To present this use case, we've chosen a flow where the user needs to sign a document.

Signing a document

In many cases, it is necessary for the claimant to sign documents during the process. They will be notified through their preferred channels, which contains a direct link to the landing page of the customer's portal. Due to it being a POC, all user flows are going through the landing page, e.g. no deep linking is happening.

New tile with a strong emphasis to present a required action

Large tiles to present the various possible options

Hover over a tile

Mockup of an integrated third-party service

Notification of completed action

Lessons Learned

Consider your Chances