A better way of managing the configuration of Fremtind's insurance products
This project is a part of a summer internship where I worked in a multi-disiplinary product team with three other students from NTNU and UiO. We designed and developed the web application Product Config Manager for managing the configuration of Fremtind's insurance products. The application will be used by product owners, functional architects and developers within Fremtind Forsikring.
I was responsible for project management and visual design, while Kaja, my co-designer, was responsible for planning and facilitating design workshops within the product team. Apart from that, we worked closely together throughout the project.
The background 🔎
Fremtind is offering a number of insurance products to private customers, and they all have different configurations. Previously, the configurations were "hard coded" into Fremtind's applications, making the data difficult to update. To solve this, Fremtind introduced Product Config, a database including every insurance product and their properties. Now it was possible for the applications to fetch the product data using API, and changes made in Product Config would be automatically synchronized across all the applications.
The problem 😐
While Product Config made it easier to update the product data across applications, it was still difficult to view, understand and edit the product configurations. In order to make changes, the product owner had to open the data in a spreadsheet, which consisted of more than a hundred rows and columns, look for the correct cells, edit their values, then send a screenshot of the changes to the system administrator, who would create a SQL statement based on the changes, and run it in the database.
The process was time consuming, and with a high risk of human error.
The brief 📃
We were expected to deliver a web application that fetches the data from "Product Config", making it possible to view the product properties across multiple test environments and make changes. In addition, we were required to use Fremtind's design system Jøkul.
The process ✏️
Our design process has included the entire team, to ensure that we are all working towards the same goal, and share the same insights and understandings. Involving the developers in the early design phase by inviting them to work on the structure with us, also enabled them to start coding early. In the final design phase we did several iterations with user testing and changes in the design, structure and flow.
1. Understanding the problem (week 1)
We spent a lot of time trying to understand the problem. A document with requirement specification were provided, which we all read through, while trying to wrap our heads around the terms and their definitions.
2. Analyzing the requirements (week 1)
We looked at the list of functions and sorted them by priority. The goal was to have a common understanding of what the most important functions are. That way, we could prioritize to implement those first, and do the other functions if we had more time later.
3. Creating the application structure (week 1)
We (the designers) created 4 use cases based on the prioritized functions. Then we had a workshop making flow charts of each use case. The workshop resulted in an overview of the most important functions, which enabled the developers to start coding right away. After the workshop, I combined all the flowcharts into a map displaying the entire application structure.
3. Sketching wireframes (week 1-2)
During the second workshop, we sketched wireframes based on the flow charts we made together. Now, the developers were able to set up the main pages of the application displaying the products and their properties.
4. Making prototypes and doing user tests (week 3-7)
We (the designers) made new wireframes of each page and function based on the sketches. We discovered that it was more efficient to make the wireframes with post-its, enabling us to re-use the components and move them around while we discussed different variants. This resulted in a paper prototype that was easy to test on the product owner and present for the rest of team.
Additionally, the paper prototypes made it easier to start prototyping in Figma using the design system Jøkul. I made the layout with rules for sizes and spacing, and me and Kaja worked on different sections of the pages. After finishing one section, we let the developers know right away so that they could start implementing the design into the application.
5. Design and coding simultaneously (week 1-7)
After weeks of doing coding and design iterations simultaneously, the application still did not look quite look like the prototype in Figma. We solved this by doing a "progge session" (as we called it), where we sat down together in front of a large screen, and the designers gave feedback while the developers implemented the changes directly. If it was not a quick fix, they added it to their to do-list. We repeated this method a few times in the final project phase.
The result ✅
We have delivered a solution that makes it smoother and safer to maintain the product data, by minimizing the risk of human error and giving the product owners a closer relationship to the product. Through an iterative design process, we have also made sure that the solution is user-friendly and efficient to use.
By involving the entire team in the early design phase, we have ensured mutual understanding and shared goals. Additionally, it enabled the developers to start coding early, which made the process more efficient and allowed us to add more functionality than expected for this summer. Inviting developers to join the design workshops also provided different perspectives and viewpoints, and forced us to be more critical about our design choices.
Working in a multi-disiplinary product team where we all had different backgrounds, helped me practice articulating my design decisions. It was challenging at times, but it helped with a culture of not being afraid to speak our minds. We were all honest with each other and we dared to have the difficult discussions. I think that was essential for the quality of our delivery.
