B2B
SaaS
Desktop web

Software spend management platform

SpendHound helps companies manage software spend for free. In return, customers provide data for SpendHound’s parent company to use in market research. Expanding what customers can track means more data for analysis.

Role:Product Designer
Period:2023–2025
Team:1 Product Designer (me), 5 Developers, 1 Project Manager, 1 Product Owner

Key contributions

I designed features that let companies tailor software records beyond predefined fields and act on spend issues from the dashboard without switching between pages. These features enabled customers to manage company-specific information within SpendHound, expanding the range of data the platform could collect for analysis.

I introduced upfront feature documentation that aligned Design, Engineering and Product on expected behavior and scope, helping Product decide what to release first and what to defer. This helped prevent inconsistencies and missed requirements that had previously led to entire sprints of bug fixing.

Problem framing

Fragmentation in a Data-Heavy Product

The core challenge was imposing structure on ambiguous requests, aligning solutions with technical constraints, and preventing the system from becoming increasingly inconsistent as it scaled.

The product was evolving into a complex, data-heavy system with no established process for grooming design work or aligning design decisions with architecture and development constraints. Features were defined as short Jira tickets with minimal requirements, and the interface relied on large tables, permission-based logic, and an expanding data model, where small changes could break existing workflows. All solutions had to fit within strict Ant Design patterns and backend limitations.

Design strategy

Turning Fragmentation into Scalable Design

To handle ambiguity and system complexity, I focused on introducing structure before and during design:

  • Breaking down ambiguous requests: I interpreted high-level tickets into clearer goals, user flows, and system-level questions, surfacing missing requirements, edge cases, and dependencies early.
  • Designing with system constraints in mind: I aligned early with backend capabilities and existing UI patterns, applying the best solution given technical and product realities, and relied on table-based structures already used across the product.
  • Defining rules before interface: I ensured data types, validation, and constraints were clear before designing the UI.
  • Prioritizing consistency: I evaluated new patterns against existing ones and moved toward unified solutions to reduce long-term complexity.
  • Introducing upfront alignment: I structured lightweight functional requirements and aligned early with Product and Engineering to reduce ambiguity and rework.
Key feature

From Brief Requirements to an Actionable Admin Dashboard

Challenge: Creating a completely new data view from just two short Jira paragraphs, under strict Ant Design constraints, with no precedent in the product. The main difficulty was defining a usable structure from very limited input.

  • Task-oriented focus: Highlighted priority areas for Admins using expandable cards and structured tables, ensuring users could complete tasks without hunting through multiple pages.
  • Consistency with existing patterns: Expanded views relied on table-based structures already used in the product, reducing learning friction and maintaining UI consistency.
  • Actionable workflows: Designed interactions that allowed Admins to take action directly from the dashboard, including the ability to hide irrelevant apps, balancing flexibility with control.
  • Managing structural discrepancies: Identified differences between table and list patterns in the product and moved toward a unified approach where feasible, preventing long-term fragmentation.
Admin dashboard overview
Admin dashboard detailed table
Admin dashboard workflow states
Key feature

Designing for Dynamic, Scalable Data Management

Challenge: Expanding the core Apps table to support dynamic customer-defined properties while preserving usability, consistency, and system stability. This required handling large, flexible tables, permission-based logic, and a growing data model, with minimal requirements and no prior precedent.

  • Data-first approach: Focused on clearly defining data types, validation rules, and constraints before designing UI, ensuring dynamic properties could be safely added without breaking workflows.
  • Separation of responsibilities: Distinguished between Admin setup and General User usage, maintaining clarity and preventing configuration errors from affecting day-to-day tasks.
  • Scalability and control: Designed mechanisms for users to manage visible columns and handle flexible content, supporting large and evolving datasets without compromising layout stability.
  • Consistency with existing structures: Ensured new dynamic properties integrated with table-based patterns already present in the product, avoiding new UI paradigms and reducing long-term complexity.
Custom properties configuration one
Custom properties configuration two
Custom properties configuration three
Custom properties configuration four
Outcome

Delivering Value at Scale

  • Delivered a task-oriented Admin dashboard that allowed users to complete actions directly from a single control point, reducing friction and cognitive load.
  • Enabled dynamic Custom Properties in tables while maintaining layout stability, system consistency, and clear separation between Admin setup and General User usage.
  • Introduced functional requirement documentation for complex features, improving alignment with Product and Engineering, reducing rework, and clarifying constraints across future sprints.
  • Unified table-based patterns and identified structural discrepancies, preventing long-term fragmentation and establishing a foundation for scalable feature expansion.

Learnings

Pragmatism over perfection

Shipping actionable, structurally sound solutions mattered more than pursuing ideal UI that backend constraints could not support.

Structure before screens

Defining rules, constraints, and edge cases upfront prevented rework and improved delivery quality.

Process scales with team size

Introducing functional requirement documentation and aligning early with Product and Engineering reduced ambiguity, improved collaboration, and enabled future designers to deliver independently.

System-level thinking is critical

Designing in a complex, evolving product requires balancing user needs, technical constraints, and long-term consistency.