0%
Slimlink — Product Design Case 🔗
Role: Product Designer (end-to-end: landing, mobile, web app, personal account, admin)
Overview
Slimlink is a SaaS for creating short links and QR codes with basic analytics. It supports generating short links and QR, collecting clicks, and managing traffic on affordable plans.
Goals & Constraints
  • Goals
    Increase sign-ups and paid conversions; reduce support load via self-onboarding
  • Constraints
    Short release cycles; strategy of frequent incremental updates; mixed user proficiency; minimal training
My Approach
  • Release strategy
    Prefer frequent small releases over rare big ones
  • Principle
    Design shortens the path “sign-up → setup → pay → usage.”
  • Prompt Engineering
    Custom prompts; model roles “investor/client” to stress-test decisions and risks
  • Organization
    Product & AI tooling training; “hire for strengths”; Figma order (structure, components, guidelines, handoff)
Research & Discovery
Inputs
Business goals; current funnel; support/sales tickets; user feedback
Hypotheses
Clear value proposition and pricing build trust; simplified sign-up raises CR; stepwise setup improves self-onboarding; transparent analytics reduces churn
Validation
Prototypes of key flows; short user sessions; 1–2 week iterations
Preparation for Design Delivery
  • User effectiveness
    JTBD, path to first value, friction in sign-up/checkout
  • Product rituals
    Increment planning, experimentation and A/B cycle
  • Feedback
    Channels (support, sales, NPS/CSAT, behavioral analytics), SLA for insight processing
  • Comms
    Shared terminology, design system, handoff rules, Definition of Done
Role
Support interviews; cluster insights; form hypotheses; translate into UX requirements; design brief & handoff; Figma structure; risk log.
Artifacts
Problem framing & release goals; IA & key flows; analytics taxonomy (GA4 + Amplitude); design principles & microcopy; component inventory & DS growth plan; increment roadmap & DoD
Information Architecture
Design System
  • Visual language
    Calm palette, high-contrast typography, restrained accents
  • Components
    Buttons, forms, statuses, tables, empty states, toasts, modals/drawers, charts
  • Accessibility
    Contrast, focus states, reasonable sizes, responsiveness
  • Content
    Concise headings, precise labels, strict error/helper text
Key Flows
  • Sign-up & self-onboarding
    Short form (email; SSO not in the first release), setup wizard, actionable empty states, first useful result in 1–2 steps
  • Dashboard &
    reports
    Minimum key metrics on top; drill-down by click; empty states explain the path to data
  • Payment &
    plans
    Pricing grid, clear limits, 1–2 step upgrade/renewal from the account
  • Admin
    operations
    Roles/limits, audit, fast triage
UI Detail — Hero: “Short Link / QR code” (Instant Try)
Goal: try the service without registration and get a working result
Why on the first screen
Minimal TTV; shows real operation; reduces bounce by promoting a first action
Events (core)
hero_view → hero_cta_click → result_shown (params: tab, type, has_slug).
Two tabs (Short Link / QR code)
Cover the main entry scenarios; easy context switch without overload
Expected impact
Lower bounce; higher CTR Hero → Result; higher post-result sign-up; higher pay CR via early exposure to analytics/limits; lower TTV.
Decisions
Single card: URL + domain + optional slug; empty slug auto-generated. Slug-helper for Hero next (already live in account/prototype).
Collaboration
Joint event taxonomy with PO & analytics; backlog prioritization; short releases; workshops with support & sales to cut manual work.
Impact (demo metrics)
Impact: (demo; 12 weeks after vs 12 before)

Registrations/week: +65%.

Funnel: (Hero → Result → Sign-up → Pay): 8% → 16%, 7% → 15%, 28% → 42%, 22% → 25%.

Time-to-Value (median): 5.8 min → 2.1 min.

Self-onboarding: 38% → 81%.

Support inbound: (“how to start/pricing”): −32%.

Time-to-First Transaction: 1d 6h → 6h.

Retention D7: +9 pp.

MRR: +37% (demo; no price change; promo & one-offs excluded).
Funnel definitions
Hero CTR = hero_cta_click / hero_view

Result rate = result_shown / hero_cta_click

Sign-up rate = signup_success / result_shown

Pay rate = checkout_success / signup_success

(all rates are conditional on the previous step)
TTV
From hero_view to result_shown (anonymous) or to first_success_action (registered)
Normalization
Before/after comparison controls for channels/geo/device and seasonality; bot & internal traffic excluded
Note
Slug-helper tests were run in the account/prototype; they did not affect the public Hero during the analyzed period
Learnings
Incremental releases accelerate hypothesis testing; actionable empty states speed up the first useful operation; the “investor/client” model role reduces decision bias
Next
Ship slug-helper in Hero (auto-suggestions + Generate button, server auto-generation when empty); expand analytics widgets/exports; refine admin roles/limits; set up repeat-sale and upsell scenarios in the account
Experiments & Data
Analytics Plan (events) — why and how
Why
Link interface decisions to measurable effects (funnel from hero_view to checkout_success, TTV, CR, Retention); shared taxonomy (GA4 + Amplitude) for comparable releases and A/Bs; fast bottleneck detection.
How used
Funnel Hero→Result→Sign-up→Pay; median TTV; D1/D7 cohorts; segments by action type (Short Link/QR). Weekly review → start/stop experiments and prioritize backlog by CR/TTV impact.
Methodology
Sample-size thresholds and significance (p<0.05) for key tests; event sanity checks; bot/internal traffic filters; event versioning when UI changes
Interview Map (summary)
Outcome: confirmed Instant Try on the first screen and soft-signup after result; priority—short path to payment.
Hypotheses → Decisions Matrix
Experiment Log (A/B)
Power control
Key tests ensured ≥80% power for expected effect ≥+3 pp; volumes and duration listed in release notes (demo)
CJM (demo)
Screenshots that are not included in the description
Made on
Tilda