Design Leadership Case Study

Developer
Platform & Nexus API

My platform-building experience is what brought me here, and it's what helped move things in the right direction. Over 11 months, I helped the team find real alignment, shipped two interconnected platforms, and built the design team from scratch along the way.

Role
Design Manager (IC + Leadership)
Duration
11 months to MVP launch
Team
Solo → 3 designers (hired & built)
Scope
Strategy, Design, Product, Team
60+
Dealerships onboarded
within 6 months
200+
Custom applications
built by dealership teams
40%
Reduction in custom
development costs
85%
Apps built by non-developers
(validating no-code UX)
Starting Point

Joining a project that needed
a fresh perspective

I was brought in specifically for this project. The VP of Design had seen my platform-building experience at a leading fintech and reached out because the project had been through multiple design iterations without gaining traction. Previous teams had struggled to move the product forward in a meaningful way. The challenge was clear: the company needed someone who understood the complexity of building developer-facing platforms, not just designing screens, but thinking through the entire ecosystem of tools, workflows, and abstractions that make a platform work.

When I joined, I had no idea how low-code platforms worked. I didn't know what an "entity" was. I didn't know what a "field" was in the context of application building. But I had built complex platforms before, and I knew the design challenges were not really about understanding every technical detail on day one. They were about understanding the problem space, aligning the team, and making deliberate design decisions that serve real users.

The company's core platform was used by hundreds of dealerships. But every time a dealership had a unique use case, they had to go back to the company for custom development. It was a costly bottleneck. The Developer Platform was built to change that.

The root cause of previous failures wasn't design skill. It was organizational alignment. The development team had fundamental open questions about scope, users, and direction that had never been resolved. Engineering and product weren't talking to each other. People were building toward different visions. No amount of wireframes was going to fix that.

Design Leadership Intervention

Cross-functional stakeholder
alignment workshop

My first move was to design and facilitate a structured stakeholder alignment workshop rooted in collaborative discovery. This wasn't a standard kickoff meeting. It was a deliberate intervention to surface hidden assumptions, resolve conflicting mental models, and get engineering, product, and design on the same page.

Session 1
Problem Framing & Assumption Mapping
Each function independently documented their understanding of the problem, the users, and what the product should do. When we compared notes, the misalignment was immediate. Engineering was building a developer-centric tool. Product was envisioning a no-code solution for business users.
Session 2
User Segmentation & Prioritization
Using a modified Jobs-to-Be-Done framework, we mapped out all potential user types, their contexts, and what they were trying to accomplish. A prioritization matrix helped us decide which personas to serve first. The team collectively agreed on it, which meant real buy-in rather than a top-down call.
Session 3
Goal Setting & Success Criteria
Using an OKR-style framework, we defined what success looked like for the first release. Each function contributed to the goals, so engineering feasibility, business needs, and user outcomes were all in the room. We walked out with a shared definition of done.

This workshop changed everything. It was the single highest-impact thing I did on the entire project. The teams before me weren't lacking talent. They were lacking a shared understanding of what they were building and why.

Working Model

Deep collaboration with engineering

The workshop was just the start. I kept that collaboration model going throughout the entire project. In platform design, especially low-code platforms, the line between design decisions and engineering architecture decisions gets blurry fast. You can't design a good entity creation flow without understanding the data model. You can't design a workflow builder without knowing the execution constraints.

⟐
Technical Deep-Dives
I scheduled recurring sessions with lead engineers to walk through the technical architecture: entity storage, workflow execution, permission cascading. I built domain knowledge. They got context on design decisions. These were learning sessions, not status updates.
⟡
Shared Problem-Solving
For challenges with real technical implications, like the real-time App Builder preview or branching logic visualization, I brought engineers into the design process early. We whiteboarded together and prototyped together. It cut out the wasteful design-then-rejection cycle.
⬡
Open Questions as Shared Artifacts
A living document visible to engineering, product, and design. Any unresolved question went in with an assigned owner. We reviewed it weekly. It directly addressed the root cause of why previous teams had stalled.
◈
Co-Created Component Library
Engineers contributed technical constraints on what could be built as reusable components. I contributed interaction patterns and visual standards. Because we built it together, there was no ambiguity when it came time to actually build. No surprises, no rework.
User Research

Four personas identified,
two prioritized

Through the alignment workshop and contextual research with dealership staff and internal developers, we identified four distinct personas. The critical decision was narrowing our MVP scope to just two of them: the users with the most immediate pain, and the ones whose needs would validate the platform's core value.

Persona 01
Dealership Employees
Non-technical staff like service advisors, sales managers, and operations leads. They run into business problems every day but have no coding skills. They needed the simplest possible experience with no jargon and no complexity.
Persona 02
Dealership Developers
In-house IT teams at larger dealership groups. They understand technical concepts and want sophisticated tools, but they're not starting from scratch. They want to move fast with powerful abstractions.
Persona 03
External Developers
Third-party developers or consultants. Technically proficient but lacking dealership domain knowledge. Deferred to avoid scope creep in the MVP.
Persona 04
Non-Dealership Business Users
Business users from adjacent roles who know what they want to build but can't code. Parked for future phases to maintain focus.

This narrowing gave us focus. Instead of trying to be everything to everyone (a trap that low-code platforms fall into all the time), we could design intentionally for two clear user types.

Research

Competitive analysis &
internal product audit

Externally, we evaluated Salesforce, Microsoft Power Apps, Pega, ServiceNow, Zoho Creator, Airtable, Kissflow, Quickbase, AppSheet, Nintex and others. We looked at target audience, pricing, support, strengths, and weaknesses, with quantitative scoring across ease of use, data control, workflow management, and platform compatibility.

What kept coming up: the market had split in two. You either got a simple tool that hit a ceiling quickly, or a powerful tool with a learning curve that alienated non-technical users. Our opportunity was in the middle: genuinely simple for dealership employees, but powerful enough for developers.

Internally, I led a full audit of every existing application on the core platform: every screen, workflow, data relationship, and edge case. Previous teams hadn't done this. We catalogued the most complex screens as stress tests. If the platform couldn't reproduce them, it wasn't ready. The audit also surfaced recurring UI patterns that became the foundation of our component library, and it gave engineering a concrete answer to what "flexible enough" actually meant.

Competitive Analysis Comparison
Architecture Decision

Two-layer architecture:
Experience vs. Studio

The combined insights from competitive analysis, internal audit, and user research led to the most important structural design decision: splitting the platform into two distinct environments, each optimized for its primary user without compromising the other.

Experience Layer
Where apps are used
Clean, simple, focused on task completion. No technical jargon, no exposed complexity. Applications built in Studio appear here as polished tools that feel native to the platform ecosystem.
→ Primary: Dealership employees (Persona 1)
Studio Layer
Where apps are built
Entity management, workflow builders, permission sets, governance tools. The full creation environment for developers and technically-inclined users. This is where the power lives.
→ Primary: Dealership developers (Persona 2)
Two-layer Architecture Experience vs Studio
Signature Contribution

The App Builder:
grid system & drag-and-drop

The App Builder needed to handle anything from a simple data entry form to a full NOC dashboard with real-time monitoring widgets. Our internal audit had confirmed just how complex the bar actually was.

I designed a modular grid system flexible enough for any layout while keeping things visually consistent. It wasn't just a layout tool. It was a design system constraint that ensured every application built on the platform would feel cohesive and professional, no matter who built it.

Snap-to-grid behavior kept layouts clean without restricting creativity. A pre-built component library lowered the floor for beginners. WYSIWYG editing eliminated the gap between building and using. Responsive breakpoints were baked in so users never had to think about screen sizes.

We validated the grid against every complex screen from the internal audit: inventory management, service scheduling, multi-panel reporting, and NOC-style monitoring. One grid system covering all of it confirmed the architecture was solid.

The App Builder Grid System
Complex UX Challenge

Flow Builder:
making logic tangible

The Flow Builder handled if-then logic, conditional branching, data transformations, and API calls through a visual interface. This is where low-code platforms tend to live or die. Our competitive analysis confirmed it was a universal pain point: Pega alienated beginners, while simpler tools couldn't handle complex logic.

We phased delivery in close collaboration with engineering. Phase 1 focused on linear workflows, which covered roughly 70% of actual dealership use cases. Phase 2 added branching, loops, and error handling. The engineering team's input on execution constraints, things like synchronous vs. asynchronous operations and runtime evaluation, directly shaped the interaction model. We added explicit "wait" nodes because engineers helped us understand that certain operations just couldn't be instant.

The visual language used node-based representations with color coding for triggers, conditions, actions, and endpoints. We tested several visual metaphors before landing on the one that performed best with non-technical dealership staff.

Flow Builder Interface
Product Strategy

Phasing as a design decision

I made a counterintuitive call: build Studio first, not Experience. The engineering load for Studio was heaviest: entity management, workflow engines, permission systems. Starting there gave engineering maximum runway. It also meant internal developers could start building on the platform right away, giving us real usage data before the Experience layer was even done.

Before
01
Dealership identifies a new use case
02
Approaches the company for custom development
03
The company scopes and builds the application
04
Application shipped to the dealership
Timeline: 2–3 months
After: Developer Platform
01
Dealership identifies a new use case
02
Opens Developer Platform
03
Builds or customizes their own application
04
Deploys immediately. Iterates on real usage.
Timeline: 2–3 weeks
Team Building

From solo IC to design team

For the first three months, I was the only designer, also acting as de facto product strategist: defining the roadmap, prioritizing features, and doing hands-on design. My product management background made it possible, but it wasn't a long-term setup.

When we moved into Experience layer work, I hired two designers. I looked for people who could operate with real autonomy in a complex domain and were comfortable with ambiguity. I held onto system design, interaction patterns, and design principles. Designer 1 owned the Experience layer. Designer 2 owned Studio features. We synced twice a week to stay consistent. Both designers were fully embedded in the engineering collaboration model: attending deep-dives, joining whiteboarding sessions, contributing to the shared open questions doc.

Part Two

Nexus API: opening
the ecosystem

With the Developer Platform running and the team operating independently, I moved onto the next challenge. The Developer Platform had empowered dealerships to build within the company's ecosystem. The Nexus API was about opening that ecosystem up entirely: bringing in vendors, partners, and external developers who wanted to integrate with and build on top of the platform.

01
Vendor Standard User
Third-party vendors connecting products to the platform. Need API access, documentation, simple authentication.
02
Vendor Admin
Vendor-side administrators managing integrations. Need governance, monitoring, access management, compliance tools.
03
Internal Support
Internal staff troubleshooting issues. Need diagnostics, logging, vendor access management. Reactive workflow.
04
Dealership
End beneficiaries discovering and enabling integrations. Mental model: app store, not admin panel.
Workflow mapping exercise in FigJam

I led a workflow mapping exercise in FigJam with color-coded swim lanes per persona and explicit handoff points. The map quickly showed us where the friction was: vendor onboarding had too many handoffs, support teams had no visibility into vendor activity, and dealerships needed something closer to an app store experience. We phased delivery the same way we had on the Developer Platform.

Nexus API Workflow Process
Phase 1

Core API Access & Documentation

API portal, authentication flows, documentation, and sandbox environments. Get vendors connected and building.

Phase 2

Governance & Monitoring

Usage dashboards, access controls, rate limiting, audit logs. Tools for admins and support to manage the ecosystem.

Phase 3

Marketplace Experience

Curated integration discovery with reviews, ratings, and one-click enablement for dealerships.

25+
Vendor integrations
in first quarter
70%
Active dealerships enabled
integrations within 3 months
35%
Reduction in integration
support tickets
Days
Vendor onboarding time
(down from weeks)
What I Actually Did

Design leadership in practice

"Design Manager" means something different at every company. Here's what it actually looked like on this project: a mix of strategic leadership, hands-on design work, team building, and cross-functional influence.

◆
Strategic Leadership
  • Defined product strategy and influenced roadmap for both platforms
  • Made critical scoping decisions on which personas, features, and problems to prioritize first
  • Designed and facilitated the alignment workshop that unblocked the project
  • Authored the design principles guiding all platform decisions
◇
Hands-On Design
  • Personally designed the App Builder grid system and drag-and-drop model
  • Created the Flow Builder visual language and interaction patterns
  • Designed information architecture for both platforms
  • Led the internal product audit establishing the complexity benchmark
○
Team Building
  • Hired and onboarded 2 designers, scaling team from 1 → 3
  • Established design processes, critique cadences, documentation standards
  • Structured parallel workstreams while maintaining design coherence
  • Mentored designers through complex system design challenges
□
Cross-Functional Influence
  • Bridged the gap between engineering and product when communication broke down
  • Built deep ongoing collaboration model with engineering
  • Leveraged PM experience to advocate design decisions with business justification
  • Influenced sprint planning and release sequencing based on user impact
Reflections

What I learned

Start with alignment, not artifacts
Two talented design teams had stalled on this project because they jumped into interface design before the team had alignment. The stakeholder workshop was the highest-impact thing I did on the entire project. It's a practice I bring to every complex initiative now.
Domain ignorance can be an asset
Not knowing what an "entity" was forced me to design for clarity. If I couldn't understand something, a non-technical dealership employee certainly couldn't. My ignorance became a design tool that kept the team honest about unnecessary complexity.
Design and engineering must think together
Platform design has too many technical interdependencies for a traditional design-then-handoff workflow. The best decisions came from shared whiteboarding sessions where designers and engineers reasoned through problems together.
Audit your own product, not just competitors
Reviewing every existing screen on the core platform to establish our complexity benchmark was one of the most valuable research activities. It grounded platform design in real-world complexity and gave engineering the concrete specificity to build with confidence.
Phasing is a design decision
Building Studio first gave us data. Narrowing to two personas gave us focus. Phasing the Flow Builder gave us speed. These weren't project management decisions. They were design decisions that shaped the product.
Platform design is systems design
It's not about individual screens. It's about creating a coherent system where the grid, navigation, entity model, and permission structure all work together. The grid system wasn't just a layout tool. It was a constraint that ensured quality across every application built on the platform.