In short, factoring is buying invoices from the seller minus a fee, Factris provides liquidity and relieves the seller from debt management. As most financial products it's possible to change the dressing according to: customers needs, business strategy and country based regulations.
Shaping
By directly involving all stakeholders (sales, finance, operations, risk management, tech, design, and customers), we have discussed the product's current status, short and long-term plans and goals, and gained insight into the thinking process that led to Factris's current requirements.
Through multiple workshops with selected stakeholders, we have defined the needs and documented the ideal user journeys through wireframes and user flows.
Some of the key elements from the initial shaping:
- Customers onboarding;
- Customers access;
- Back-office access (operations, risk, finance, sales);
- Country based exceptions;
- Agnostic payments provider;
- Variety of factoring products offering.
Planning
The team consisted of three developers (one front-end, one back-end, and the CTO) and one designer (me). The initial goal for the MVP was to set the foundation for the needs discovered during the shaping process and to replace the previous platform.
To move as quickly as possible while still allowing for iteration, the MVP focused on a few user types (operations and risk), only one country, one payment option, and one product offering. The onboarding process and the seller-side platform were left out of the MVP (as they were not available on the previous platform).
During this phase, I produced detailed process mappings, identified pain points and feature requests through user interviews and by shadowing my colleagues.
A series of workshops between the product/design and operations/risk teams were held to address flawed processes caused by the limitations of the previous "no-code" platform. Users were able to be creative in finding alternative ways to implement risk policies, which were improved in the new web app that we built in-house.
Building
This was by far the most demanding phase as we were all newly hired employees eager to do our best, but our varying approaches led to conflicts in the current "waterfall" process.
We overcame these differences by quickly shipping affordances before focusing on pixel-perfect design. This allowed programmers to start working on the project immediately and enabled us to answer fundamental questions early on, such as: Does it make sense? Is it understandable? Does it do what we want?
This meant that the first interfaces I passed on to the developers could look basic, while keeping more polished UIs in the prototyping tool for testing with users in a format that was more familiar to them.
Meanwhile, the react developer and I started building the first version of the design system, defining components following the atomic design principles.
Product shots
A series of stills from the MVP launch featuring the main table component, modals and invoice and client details page.
Conclusion
Defining the long-term plans for the web app helped to keep the shaping of the MVP straightforward and focused.
Challenges within the team during our first attempt at building the MVP led to quick iterations that were verified through user testing, which kept the users engaged and excited about the release.
I personally grew a lot as a designer during those months. It was my first deep dive into an intricate financial web app, which allowed me to utilize all the tools necessary for a product designer.
Credits
Designed in Amsterdam in 2018 and 2019 as a full-time employee with Ash Hewson (Backend), Raju Maher (Frontend), Jasper Laagland (CTO) and Brice Laurent (Founder).