From feature set to product: founding design at Sweap
Sweap already had paying customers when I joined as its first product designer, but years of feature-led development had left the experience fragmented. Over 2.5 years I worked across most of the product: restructuring the core event-creation experience, building a no-code registration-site builder, unifying the interface through a shared design system, and establishing a repeatable design-to-development process. The result was a faster, more self-service product: core event setup fell from over an hour to 9 minutes, while the company also saw stronger engagement and account expansion over the same period.
- Client
- Sweap
- Role
- Founding Product Designer
- Year
- 2021–2024
- Live
- Visit ↗
Context
Sweap is a B2B event-management platform covering invitations, registration, guest management, check-in and post-event communication. When I joined, it already had paying customers and a substantial feature set, but no dedicated product-design function. As the company's first designer I initially also supported brand and marketing needs before helping move that work into a dedicated design role.
Different capabilities had evolved independently, creating inconsistent workflows and increasing complexity for both customers and development. My role grew from improving individual experiences into restructuring large parts of the product and defining how product design worked inside the company.
Product scope
My work extended well beyond the registration-site builder shown in the screens below. Across 2.5 years I worked on most of Sweap's core product experience.
The problem behind the redesign
Sweap had grown feature by feature. Event types, registration experiences and supporting tools had accumulated their own patterns and workflows, so customers effectively had to learn several small products instead of one. Core event setup could take more than an hour, support remained involved in routine setup, and engineering repeatedly reinterpreted designs during implementation.
The brief looked like a redesign. The real opportunity was to make the product behave as one system, and establish a design practice that could keep it that way.
How we measured progress
Product priorities were connected to quarterly business and product KPIs. I contributed initiatives against those goals with product and leadership, then used the agreed metrics to evaluate whether shipped work was moving the intended behaviour.
Four decisions that mattered
Turn separate event types into one product model
- What I chose
- I redesigned event creation around the decisions an organiser actually makes, format, date, audience, registration and communication, instead of around Sweap's internal feature structure. Series, recurring and online events became variations of the same underlying flow rather than separate products.
- What it cost
- Restructuring one of the most established parts of a live product while customers were actively using it, rather than continuing to add requested fields to the existing forms.
- What it changed
- Core event setup fell from more than an hour to 9 minutes. New event types could reuse the same interaction model instead of introducing another independent workflow, and Sweap began onboarding its first customers without assisted setup.
Turn registration-site configuration into creation
- What I chose
- Registration sites had previously been configured through a rigid set of fields and checkboxes with little connection between configuration and output. I designed a modular visual builder with live preview, reusable content sections, reordering, non-destructive hiding, global styling, templates and an advanced HTML/CSS escape hatch.
- What it cost
- The builder had to remain compatible with Sweap's existing registration backend. Three rounds of testing were needed to find an interaction model that felt flexible without breaking the underlying data structure.
- What it changed
- Event teams could create and adapt branded registration sites themselves rather than relying on support for routine changes. Templates reduced the work needed to start new events, while account-level content such as speakers and partners could be reused across events.
One part of the wider transformation was the registration-site builder. The screens below show how the old configuration model became a modular visual editing environment.
Migrate a live product onto one system without stopping delivery
- What I chose
- I rebuilt the visual foundation around shared semantic tokens and reusable components, then migrated the product incrementally as each area was redesigned. Events and guests moved first because they carried the highest usage, followed by registration, communication and check-in experiences.
- What it cost
- Engineering first had to refactor parts of the styling layer, and we deliberately avoided a high-risk big-bang redesign. For a period, old and new patterns had to coexist.
- What it changed
- New screens could be assembled from shared patterns rather than designed independently. The same token layer also enabled theme changes, including dark mode, without maintaining separate component sets.
Make product design a repeatable operating process
- What I chose
- As the first product designer, I defined how design work moved from problem framing through exploration, validation, specification and implementation. Each feature had a single source of truth containing its objects, rules, states, open questions and linked designs. Jira implementation work was derived from that specification rather than recreated from memory.
- What it cost
- More discipline upfront from design and product, and several sprints before the new workflow became habitual.
- What it changed
- Design-to-build turnaround dropped by 30%, implementation review went from 2 to 3 loops to 0 to 1, and new contributors could understand a feature from the documentation rather than reconstructing its history from meetings and Figma files.
As the function expanded, the process also became the onboarding framework for additional design contributors. Later in my tenure I supported the expansion of product design and hired and onboarded a dedicated marketing designer, after initially covering much of that work myself.
Three systems had to scale together
The product refresh was deliberately incremental. High-usage areas moved first, and each area adopted the shared foundations as it was redesigned rather than waiting for a single relaunch.
Fragmented product
- Event types behaved like separate workflows
- Core setup required 60+ minutes
- Registration pages configured through checkboxes
- Routine onboarding depended on sales, training and support
- Feature specifications recreated across Figma, conversations and Jira
- No shared product-design operating model
One product system
- Shared flow across event formats
- Core setup reduced to 9 minutes
- Modular visual builder and reusable templates
- First customers able to onboard and set up independently
- One specification became the implementation source of truth
- Repeatable design process connecting product, design and engineering
Outcomes
Directly measured through the work
Business movement over the same period
Account expansion was an important business goal during the redesign period. As Sweap became more coherent across event types and workflows, the company saw net dollar retention rise from 103% to 119%, overall engagement increase 16%, and ARR grow 26% in one reported year. These metrics moved during the wider product transformation and were influenced by multiple company initiatives. I use them as business context rather than attributing them solely to design.
What I would do differently
I would establish both the delivery process and the measurement framework earlier. We improved the handoff process later in the transformation, yet it produced one of the fastest measurable gains at relatively low cost.
I would also instrument the redesign from the beginning around product behaviours rather than pages: time to create an event, self-service activation, adoption across event types, registration-site publishing, template reuse, support dependency and expansion across workflows. That would make attribution between product changes and business movement significantly clearer.
