Kit Management

The fundamental design challenge was that two very different user groups needed to work within the same workflow, but with opposite mental models.

The Franchisor (Corporate Office) thinks in aggregates and operations. They need high-level visibility across all centers, operational dashboards showing metrics and trends, the ability to manage kit requests, and reporting to understand financial collection and performance.

The Franchisee (Pre-school Center) thinks in tasks and local context. They need to see newly enrolled students at their center, submit kit requests, provide payment information, and track whether requests have been processed and dispatched.

Rather than creating one interface that tried to serve both, the approach was to create two distinct experiences, each optimized for how its users think about the problem.

Despite having separate interfaces, both users are part of a single connected workflow. The workflow moves through distinct phases, each supporting a different part of the request lifecycle:

Franchisee creates a request → Provides payment information → Franchisor reviews and processes → Kits are dispatched → Franchisee tracks status.

The design had to make this lifecycle clear for both sides while reflecting that they see different aspects of the same flow.

My process began by understanding the business requirements provided by the Project Manager, then mapping how each user group needed to interact with the system.

First, I understood the ecosystem: What is a kit and how is it composed? Who manages what? What data matters to each user? Then I developed the information architecture: What features must each side have? How should they be organized? What information is critical at each step?

Next, I designed workflows for each user group: How does a Franchisor operate at their dashboard level? How does a Franchisee execute the request creation task? What are the differences in their interaction patterns and needs?

Finally, I refined the designs based on Project Manager feedback and prepared the complete module design for handoff to the development team.

The Franchisor interface is built on a dashboard-first approach, because the corporate office's primary need is operational visibility across all centers.

The Franchisee interface is designed around task completion. The center manager's core task is straightforward: see newly enrolled students, create a kit request for them, provide payment information, and then track that request through processing and dispatch.

Several design decisions emerged from thinking through these workflows and how to serve two fundamentally different user groups:

The complete module design was prepared and handed to the development team. This included information architecture, screen designs for all major user flows, design assets, and specifications for both Franchisor and Franchisee interfaces.

The design demonstrates end-to-end UX thinking: from business requirements through user-focused interface design to development-ready specifications. The design provided the blueprint for implementation.

The separation of Franchisor and Franchisee interfaces addresses a fundamental design challenge: two very different users within one connected workflow. By tailoring the experience to each role's mental model—operations versus task completion—the design makes complex workflows feel natural for both users.

This project demonstrates an approach that transfers beyond Kit Management: when two user groups have opposite needs, separate interfaces often work better than forced unification. Dashboard-first is powerful for operational roles; task-first is powerful for transactional roles. Connecting payment information to the request keeps workflows efficient. Status visibility reduces support burden and builds user confidence.