Fintech · Creditor, investor and administrator journeys
piHub
Making a financial application easier to follow when several people have a part in the decision.
- Contribution
- Product design contribution
- Evidence
- Complete original Figma screens · sample design content
The project and my part in it
piHub connects creditors, investors and administrators. Each person sees a different part of the same process: one submits an application, another reviews an offer or request, and an administrator manages access and records.
I worked on forms, information hierarchy and status language across these roles. The central problem was helping someone understand what had happened, what was still needed and who should act next.
What shaped the design
- Creditor, investor and administrator roles need different information.
- Waiting for another person is a legitimate part of the process.
- A review decision needs the relevant request and its supporting detail.
THE DESIGN CHALLENGE
How does a financial workflow remain understandable when the next step belongs to another person?
I followed the application across the roles. The screens need to share a meaning for each status, while giving creditors, investors and administrators different information and actions.
Show what has been submitted
The creditor sequence starts with company information, acknowledges an application and brings submitted work into a list. The acknowledgement says that the application was received; it should not be confused with approval.
In the list, written statuses sit beside the information needed to compare applications. A person can see which requests are waiting and which have moved forward without opening every record.
A compact list helps comparison, but a request that needs attention also needs a specific explanation.
Give investors their own view of the work
Investors enter the process with different questions. They need to define an offer, review products and inspect incoming credit requests. Their screens therefore give those objects more attention than the creditor profile.
I kept the relationship between the roles in the status language. A label such as Awaiting Approval needs one agreed meaning even when each role sees a different page.
The roles can share components and status names while giving different actions priority.
Put the request beside the review decision
The administrator views add the other side of the handoff. A request list leads into company details, and a credit-review page collects the information and attachments needed to consider the request. Approve and Disapprove sit with the record they affect.
Access denial is a separate situation. Its recovery screen gives a way back, while permission checks still belong to the application and server. I would review these boundaries with the team before treating the cross-role flow as complete.
Review actions need enough context to support a decision; showing more financial fields alone does not make the decision clearer.
What I delivered
The creditor, investor and administrator designs show the application from different responsibilities. The additional review screens make the handoff visible within this case.
Outcomes and next steps
The design establishes a role-based structure and a shared way to discuss state changes. Live processing, uploads and synchronized notifications remain engineering work.
What I would test next
- Ask a creditor to identify who owns the next step after submission and what would require a response.
- Trace an application returned for changes across creditor, investor and administrator views; check that their status language describes the same event.
What I learned
Waiting is easier to understand when the interface explains the dependency. Sometimes the right next step belongs to another person.
