Account data needed a dependable home
Company and member information had to be easier to inspect and update without switching tools.
← Selected work
Dialogue · B2B product discovery
Designing a clearer account-management portal
A research-led concept that reorganized company profiles, billing, subscriptions, and support tasks into a focused experience for account teams.
Project snapshot
Untangling account work spread across systems
Dialogue’s existing portal served both internal account managers and customer-side administrators. The discovery explored how to separate internal operational work and create a focused portal around the information each group needed.
- My role
- Product Designer leading research and design with the Product Manager
- Users
- Internal account managers and designated administrators at client organizations
- Focus
- Company profiles, members, billing, subscriptions, and support workflows
- Methods
- User interviews, synthesis, workflow mapping, information architecture, and prototyping
- Stage
- Discovery and concept development
The challenge
Account work extended far beyond the portal
Account managers relied on the existing portal alongside Slack bots, support-request templates, and help from technical teams. The fragmented toolset made routine tasks harder to locate and complete consistently.
Design challenge
How might we create a dedicated account-management experience that reflects real workflows while separating internal operations from customer self-service?
Research synthesis
Turning interview evidence into product requirements
I organized interview findings into common themes and translated them into must-have capabilities for a future tool.
Support was part of the workflow
Slack bots and IT requests were not edge cases; they represented tasks the portal did not adequately support.
Internal and client needs were different
A clearer boundary was needed between operational administration and customer self-service.
Current-state ecosystem
Mapping the work outside the product
Before proposing screens, I documented the external tools and support channels account managers used to finish their jobs.
Existing product
Understanding the portal before changing it
I mapped the current interface and its connections across billing, organizations, member records, imports, and profile details.
Information architecture
Organizing the future product around account work
The proposed hierarchy separated customer-facing administration from internal operational tools while preserving the relationships among organizations, members, subscriptions, and billing.
Design progression
Moving from structure to task-level interfaces
Low-fidelity wireframes tested the structure of organization lists, profiles, billing information, and editing workflows before visual refinement.
Prototype evolution
Two stages of concept development
The first prototype made the information architecture tangible. A later concept expanded the feature direction after product-planning conversations.
Initial high-fidelity concept
Translating the proposed hierarchy into an interactive product direction.
Evolved feature concept
Extending the experience after product-manager review and feature brainstorming.
Proposed product model
A focused workspace for recurring account tasks
Organization profiles
View and maintain company-level information in one dependable location.
Member administration
Inspect, add, and update member records within the appropriate organization.
Billing and subscriptions
Bring financial and plan information into the same account context.
Guided support
Reduce reliance on scattered tools by supporting recurring operational needs directly.
Outcome
A clearer product direction grounded in real work
The project produced a synthesized understanding of account-manager needs, maps of the current ecosystem and portal, a proposed information architecture, low-fidelity workflows, and two prototype stages.
Because the available evidence documents discovery and concept development—not a production release—this case study focuses on the quality of the research-to-design reasoning rather than claiming launch metrics.
Reflection
The workaround is part of the user experience
Mapping only the existing portal would have missed much of the real job. Slack bots, IT requests, and manual support showed where the product boundary had failed to match users’ responsibilities.
The most valuable design move was therefore not a screen—it was expanding the research frame before deciding what belonged in the new portal.
Selected work
Explore another case study
Return to the portfolio to review released insurance experiences and other product-design work.
Return to selected work