04 — ZKTeco Vendor Portal · B2B / Enterprise / Vendor Management
Bringing fragmented vendor workflows into one workspace.
Designing a centralized vendor portal for onboarding, account management, communication, vendor activity and transactions.
Role
Product Designer — research, information architecture, interaction design, UI, prototyping
Team
Product, engineering and internal business stakeholders
Tools
Figma, FigJam, Jira, Notion
Headline result
16% increase in vendor registrations
What I did
- Ran interviews and working sessions with vendors and the internal teams who manage them
- Mapped the end-to-end vendor workflow across onboarding, activity and transactions
- Designed the portal structure, navigation and the core enterprise screens
- Built the component library and prototypes used to align stakeholders before build
Overview
ZKTeco works with a network of vendors. Onboarding a vendor, managing their account, keeping track of their activity, handling transactions and simply talking to them were all happening in different places.
The portal brought those into one workspace, for the vendor and for the internal teams supporting them.
Discovery
I spoke to vendors and to the internal teams who deal with them daily, and worked through the requirements with stakeholders who each owned one part of the process. Nobody owned the whole thing, which is exactly why it felt fragmented from the outside.
What the work surfaced
- Onboarding asked for the same information more than once, through more than one channel.
- Vendors had no reliable place to check the status of anything.
- Internal teams rebuilt context from email threads before they could answer a question.
- Requirements differed by team, and some of them quietly contradicted each other.
Structure
- 01
One vendor record
Everything about a vendor — profile, documents, activity, transactions and conversation — hangs off a single record instead of living in separate systems.
- 02
Onboarding as a tracked process
A clear sequence with visible status, so both sides can see where an application is without asking.
- 03
Activity and transactions in view
The information internal teams were previously reconstructing manually is now on the screen where the decision is made.
- 04
Communication attached to context
Messages sit with the vendor they relate to, so the history is part of the record.
Design decisions, and why
Ask for information once, at the point it is needed.
WhyRepeated requests were the main reason onboarding stalled partway through.
Make status explicit everywhere, for both sides.
WhyMost of the support load was people asking where something had got to.
Dense tables with a detail panel, rather than page-per-record.
WhyInternal teams work through many vendors in a session. Keeping context beats navigating back and forth.
Design against the real constraints rather than an ideal process.
WhyExisting systems and internal rules were not going away, so the portal had to fit around them to ship.
Outcome
16%
increase in vendor registrations
Reflection
Enterprise work is mostly alignment. The design got better every time I got two teams who had never spoken about the same workflow into the same session.
I would push earlier for one owner of the end-to-end journey. Designing across several partial owners is slower than it needs to be.