{{ td.l }}: {{ td.d }}

How I worked

Redesigned end to end, with the in-house studio

I worked with SysAid's in-house studio, led by Tomer Gilat, alongside the product manager, engineering and our design partners, who joined interviews, live sessions and prototype tests. Together we ran competitor and user research with qualitative and quantitative interviews, then took the queue and ticket page from wireframes to tested prototypes. What came out was a design system and an entirely new end-user UI.

Methodology map. Daniel works alongside SysAid's in-house studio, led by Tomer Gilat, with the product manager, design partners, engineering and senior stakeholders. The work moves in five steps, from research to a design system, a new end-user UI and Template Designer. — Methodology map · Reconstructed for this case study Each step fed the next, from first research to the shipped system.
Read as text

**Context**: Classic, the legacy platform in use since 2002 → Spaces.
**Who**: me, Senior UI/UX Designer · SysAid's in-house studio, led by Tomer Gilat · product manager · design partners · engineering and senior stakeholders.
**1 Research**: competitor and user research, design partners, qualitative and quantitative interviews. 18 interviews · 240+ surveys · 6 competitors.
**2 Synthesis**: 3 recurring themes · 4 segments · 4 principles.
**3 Wireframes**: the queue as a clear table with fast filtering · the ticket page as a labeled, sectioned layout.
**4 Prototypes and testing**: 3 usability rounds on service-record resolution, related items and action-item workflows.
**5 Delivered**: a design system · an entirely new end-user UI · Template Designer.
Sources: the case text and Daniel's notes. No invented data.

Research & discovery

Synthesis board from the joint research: 18 interviews, 240+ survey responses, 6 competitors and 3 testing rounds, grouped by source. Three themes recur: the queue was overwhelming, bulk work was slow and non-technical teams could not shape their own templates. — Synthesis board · Reconstructed for this case study From the joint research with SysAid's in-house studio, grouped by source so each finding shows where it came from. Findings paraphrased; no verbatim quotes exist.
Read as text

**Methods**: 18 user interviews (admins and agents) · 240+ survey responses · 6 competitors benchmarked · 3 usability testing rounds.
**Who**: SysAid's in-house studio (led by Tomer Gilat), the PM and design partners.
Design partners (interviews, live sessions, prototype tests). Valued: the reliability of Classic. Pain: complex UI · limited customization · clunky asset management.
**Customer surveys. Valued**: customization · API integration · ticket tracking. Pain: customization complexity · unresolved tickets.
Competitors (ServiceNow, Jira and 4 more). Valued: strong customization and dashboards. Pain: overwhelming UI · steep learning curves, industry-wide.
**Segments**: small existing, need simple workflows, struggle with the outdated UI and migration · large existing, need advanced customization, face workflow strain · small new, want intuitive design and quick onboarding · large new, demand scalability, wary of steep learning curves.
**Recurring themes**: the queue was overwhelming · bulk work was slow · non-technical teams could not shape their own templates.
Sources: the case text and Daniel's notes. No invented data.

Who we designed for

The principles it led us to

Strategy

Every fix traced to a problem

The research pointed at four clear problems with the legacy queue. I designed a deliberate answer to each, and each answer shipped as a feature.

Decision map with four rows. Each problem in the legacy queue leads to a design move, the feature that shipped and, where known, the shift it made, such as editing a ticket field going from 6 clicks to 1. — Decision map · Reconstructed for this case study Getting buy-in meant tying every decision back to a real problem and a measurable result.
Read as text

**Row 1. Theme**: the queue was overwhelming. Problem: an outdated interface, dense tables and text that made it hard to spot what was urgent. Move: a modern queue with chips, avatars and dynamic cues. Shipped: graphic chips. Shift: not stated.
**Row 2. Theme**: bulk work was slow. Problem: losing to competitors with a dated look. Move: time-saving power, with inline editing and bulk actions. Shipped: inline edit, every cell edits in a single click. Shift: editing a ticket field, 6 clicks → 1 click.
**Row 3. Problem**: a steep learning curve. Move: personal queue views to add, reorder and save columns. Shipped: custom columns and queue views. Shift: queue columns, fixed → configurable.
**Row 4. Theme**: non-technical teams could not shape their own templates. Problem: dependence on support, where small changes needed pro services. Move: self-sufficiency. Shipped: Template Designer, no-code. Shift: building a ticket template, pro services → self-serve.
**Foundation, across all rows**: one governed design system. Shift: UI components, ad-hoc → 50+ governed.
Sources: the case text and Daniel's notes. No invented data.

The redesign

The main ticket table

The heart of SysAid. I rebuilt it around scannability and speed - clearer hierarchy, status and priority cues, bulk actions and multi-select - so agents move through queues with far less friction.

Wireframes & prototypes

Main ticket table before: alert dots, SR type, Priority, Category, Title, Status, Request user and Admin group as plain text in a dense grid — Main ticket table · before and afterDense plain text became visual cues, so agents can see what needs attention first.
Priority: plain text became colored chips that read at a glance.
Due date: time left shows as a bar, so urgent tickets stand out.
Status: labeled chips replace plain text, so a ticket's state is quick to scan.

Main ticket table after: Title, Priority chips, Urgency, Due date bars, Status chips and assignee avatars — Main ticket table · before and afterDense plain text became visual cues, so agents can see what needs attention first.
Priority: plain text became colored chips that read at a glance.
Due date: time left shows as a bar, so urgent tickets stand out.
Status: labeled chips replace plain text, so a ticket's state is quick to scan.

What makes the queue fast

Ticket page & insight panel

I rebuilt the single ticket into a focused two-column view with a contextual insight panel (open SRs, relevant KB, time-to-repair) and a clear activity journey - plus complex reusable components like the multi-select assignee.

SysAid ticket page before — Ticket page · before and afterA focused two-column view, with an insight panel for open SRs, relevant KB and time-to-repair.

SysAid ticket page after — Ticket page · before and afterA focused two-column view, with an insight panel for open SRs, relevant KB and time-to-repair.

The right-side tabs I designed

Flagship feature

Template Designer - a no-code builder

A huge feature I owned end to end: a low-code / no-code builder that lets non-technical people compose ticket templates for their organization - sections, fields, workflows and per-field properties - by dragging from a field library, with a live preview. It put template creation in the hands of the teams who actually run the processes.

SysAid Template Designer — Template DesignerTeams drag sections and fields from a library and check them in a live preview, with no code.

Foundation

The design system

I created and maintained the design system from scratch - color, typography, an icon set and complex components with every state documented - so the whole platform stays consistent and ships faster.

SysAid design system — Component sheetEvery state documented, so the platform stays consistent and ships faster.

Outcomes

What changed for admins

Where they started

The system they had

This is the interface operators actually worked in before we arrived - a dense grid of near-identical panels, color-coded state, and repeated controls with no hierarchy or search. Everything competed for attention at once. It set the bar the new system had to beat, and it is the reason a flexible, no-code, search-first console mattered so much.

The legacy systemIn daily use for years before the redesign - blurred for classification. Dozens of identical panels, color-coded state, repeated controls, no hierarchy and no search.

Research and collaboration

Research without access to users

Classified meant no interviews, no analytics, no recordings and no way to benchmark competitors. So I worked through the people closest to the system. The Product Owner was effectively its super-user, who built and operated the screens and brought insight from the field. With the Product Owner and the development team I ran recurring on-site sessions at the client's offices, gathered as much internal client data as I could and mapped the commands operators fire most, the failures they chase daily and how critical uptime is to the whole operation. Then I iterated, by trial and error, until one design served every user level. Every decision traced back to that picture.

Research-channel map. Inside a classified program with no user access, analytics or remote sessions, Daniel worked through the Product Owner, the system's super-user, and the development team. Operators were reached only through the Product Owner, and the work moved in a loop of trial and error. — Research-channel map · Reconstructed for this case study The people closest to the system stood in for the users I could not reach. Labels abstracted for classification.
Read as text

**The frame, a classified program**: no access to end users · no analytics · no remote sessions · competitor research blocked, because systems like this are classified.
**Outside the frame**: operators, reached through the Product Owner.
**People inside**: the Product Owner, the system's super-user, who built and operated the screens and brought insight from the field · the development team.
**Methods inside**: on-site working sessions at the client's offices · internal client data, as much as could be gathered · a legacy system audit · a frequent-actions inventory of commands, checks and calibrations, ranked by frequency and criticality.
**The loop**: iterative trial and error across different user levels · a Concept Design Review with the client and development · every iteration reviewed against real usage.
**Note**: all manual, a pre-AI workflow.
Sources: the case text and Daniel's notes. No invented data.

Prioritization

From daily work to what shipped

With no analytics to lean on, prioritization came straight from the ranked frequent-actions inventory. Commands, checks and calibrations, ranked by frequency and criticality, became requirements, principles and a prioritized plan. Below, each daily need sits next to the answer that shipped and the shift it made.

Requirements map. Five daily needs from the frequent-actions inventory, each traced to the answer that shipped and the shift it made, from menu digging to tab and search and from a dev task to drag and drop. — Requirements map · Reconstructed for this case study With no analytics, the ranked inventory was the only evidence for what to build first. Labels abstracted for classification.
Read as text

Ranked by frequency and criticality → requirements, principles and a prioritized plan.
**Reaching a screen. Answer**: tabs, where every new tab opens on search plus the common pages. Shift: menu digging → tab + search.
**Firing a frequent command. Answer**: quick actions on the common pages. Shift: seconds, not menus.
**Running checks and calibrations. Answer**: macros, step by step, with live progress and failure drill-down. Shift: expert-only → guided macros.
**Chasing failures. Answer**: one real-time console with a live status panel. Shift: scattered → one console.
**Building a new operator screen. Answer**: UI Builder, dragging elements from the ICD, no code. Shift: dev task → drag and drop.
**Across all five, different user levels**: operators with 20+ years kept the dense layout of about 60 elements, and hierarchy and search were added instead.
Sources: the case text and Daniel's notes. No invented data.

Concept Design Review

Two concepts, one validated direction

Before committing to build, I ran a CDR - a Concept Design Review with the client and development - to validate a direction both operationally and technically. I brought two concepts to the table.

Decision matrix comparing two concepts reviewed with the client and development. Concept A, a tabbed workspace, was selected for real-time speed. Concept B, an aircraft hologram, looked striking but was set aside. — Decision matrix · Reconstructed for this case study Reviewed with the client and development before anything was built, so the direction held up operationally and technically.
Read as text

Reviewed with the client and development, operationally and technically.
Concept A, tabbed workspace, selected. Navigation: browser-like tabs, each a full screen of operational elements. Real-time operation: built for it. Speed and feel: the least time and fewest clicks possible, fast and familiar. Outcome: earned technical and practical validation and became the operator console.
Concept B, aircraft hologram, explored. Navigation: a 3D model of the aircraft as the navigation surface. Real-time operation: never gave real comfort for it. Speed and feel: looked striking, but more gimmick than tool. Outcome: set aside.
Sources: the case text and Daniel's notes. No invented data.

The client and development loved the tabbed workspace, and it earned the technical and practical validation to move forward - it became the operator console that follows.

Decision log

Trade-offs I made

Real programs are full of tension between the ideal design, engineering reality and how people actually work. A few calls I owned:

The idea

The tension

The call

The solution

The operator console

Live telemetry streams into configurable sections - sensors, meters, cameras, toggles and commands - while a status panel surfaces connection state and activity failures the moment they happen. Operators see, decide and act on a single screen, at speed.

IAI real-time monitoring console — Operator consoleTelemetry, commands and failures on one screen, so operators see, decide and act at speed.

Automated macros for maintenance & calibration

Routine check and calibration flows run as macros - step-by-step sequences with live progress, remaining time and a drill-down into every failure with its recommended action. Work that used to demand deep technical knowledge became a guided flow operators move through quickly.

IAI macro runner with failure drill-down — Macro runnerLive progress, time remaining and a drill-down on every failure with its recommended action.

Browser-fast navigation

Screens live in tabs, and every new tab opens on search plus the most common pages with their quick actions attached - so reaching any screen or firing a frequent command takes seconds, not menus.

IAI new tab - search and common pages — New tabSearch plus the common pages and their quick actions, so any screen is seconds away.

Flagship feature

UI Builder - operator screens without code

The interface is fully flexible: an admin composes the screens their operators work on by dragging elements straight from the ICD onto sections, tuning each element's properties in place, and publishing. Low-code and no-code by design - building a screen requires no technical sense, so the interface adapts to the operation instead of the other way around.

IAI UI Builder - composing a screen — UI Builder · composingAn admin drags elements from the ICD onto sections, with no code.

IAI UI Builder - element properties — UI Builder · propertiesEach element's properties are tuned in place, then the screen is published.

Craft & methodology

The system behind the system

Real frames from the IAI design-system and Element Index files in Figma - the reference developers implemented against.

Outcomes

What changed in daily work

Requirements

Requirements-led, to a strict brand book

This was a short project, led by requirements rather than a research phase. I worked closely with the PM, the development team and the Clalit studio, to a brand book with specific do's and don'ts. Each requirement below has the design response it got.

Requirements map · Reconstructed for this case study With no research phase, the brief and the brand book set every requirement.

Read as text

At the center: a workshop portal for members of every health plan.
Audience: every age, every level of digital comfort, diverse abilities. Response: a prominent search field and layered filters up front.
Catalog: a wide range, held in person or online, from smoking cessation, alcohol withdrawal and weight management to many more. Response: filters for topic, audience, region, language and format, and the essentials on every card.
Accessibility: strict adherence to accessibility principles. Response: high-contrast modes and accessibility testing throughout.
Responsive: one experience from mobile to desktop. Response: catalog, filters and registration rebuilt for touch.
Brand book: a clear brand book with specific do's and don'ts. Response: a portal style guide aligned to it.
Registration: guide people through registration without friction. Response: one clear path to register.
Around it: a short project, 3 months from brief to handoff · close collaboration with the PM, the development team and the Clalit studio.

Sources: the case text and Daniel's notes. No invented data.

The experience

From discovery to done

User flow in five steps, from the workshop catalog to a booked place, with an empty-state branch that leads back to the catalog when no online sessions are available. — User flow · Reconstructed for this case study Mapped as one path because the audience spans every age and level of digital comfort.
Read as text

**1 Discovery and catalog**: search, filters (topic, audience, region, language, format) and cards with date, time, seats and cost.
**If no online sessions are available**: an empty state keeps the member oriented and offers a way back to step 1.
**2 Workshop page**: session details, the session list, a booking summary and a single path to register.
3 Sign-in and registration.
**4 Summary and confirmation**: personal details, consent and one clear action.
**5 Success**: an on-brand thank-you with Clalit's mascot.
The same flow on desktop and mobile.
Sources: the case text and Daniel's notes. No invented data.

Craft & consistency

A style guide to keep it whole

Style guide{{ activeCase.styleCap }}

Responsive

Built for every screen

MobileBrowse the catalog, filter by region and open a workshop, all designed for touch and small screens.

Overview

One designer, product to brand

Product

Brand

Prefer to watch? The Clara film, 2:57.

Jump to the Film chapter.

Part 1 · Product

Research

Operators needed control, not chat

Competitor landscape. Wonderful, Jeen.ai and Blocks each cover one part of the job. None gives one operator outcomes, spend and retrieval in one place, and that gap became Scully's brief. — Competitor landscape · Reconstructed for this case study Mapping the market first showed what Scully had to be: the one place none of them offered.
Read as text

**Wonderful**: sells outcomes and hides the machinery.
**Jeen.ai**: an AI operating layer sold to IT.
**Blocks**: lets anyone build an agent in plain language.
**The gap**: one hides the machine, one governs it for IT, one opens building to everyone. None of them gives one operator outcomes, spend and retrieval in one place.
**Scully's brief**: outcomes, spend and retrieval in one place, for one operator. That gap became the brief.
**Method**: competitor research, run fast with the AI agent team.
Sources: the case text and Daniel's notes. No invented data.

Decision map. The market gap and four product roles lead to three calls: the fleet view opens with outcomes, cost gets its own page and Hebrew is built in. Each call sits next to what shipped. — Decision map · Reconstructed for this case study The roles came from the product, not interviews, so every call had to trace back to the market gap.
Read as text

**Inputs, shared by all three calls**: a market gap (no one place for outcomes, spend and retrieval) · four people from the product's real roles: operations admin, analyst, content lead, viewer · constraint: not based on interviews.
**Call 1**: the fleet view opens with outcomes. Shipped: the fleet dashboard, outcomes first, then the one alert worth opening.
**Call 2**: cost got its own page, because an over-budget agent is an incident, not a setting. Trade-off: it cost a slot in a short navigation. Shipped: FinOps, spend per agent against policy, with the one over budget named.
**Call 3**: Hebrew is built in. Shipped: bilingual EN/HE, RTL.
Sources: the case text and Daniel's notes. No invented data.

How I worked

One designer, a team of AI agents

Agent orchestration map. Under very tight timelines, seven kinds of AI agent feed into Daniel, the only human designer, who owns product, design and marketing. Seven shipped pieces of work come out the other side, with a four-step pipeline underneath. — Agent orchestration map · Reconstructed for this case study One owner for every call, with each task given to the agent best suited to it.
Read as text

**Constraints**: very tight timeframes · strict prioritization by urgency.
**AI agent team**: UI/UX · animation · product branding · brand book · tone of voice · competitor research · user testing. The agent best suited to each task was the one used.
**At the center**: Daniel, the only human designer. Owns product, design and marketing.
**What shipped**: back office, 16 feature pages · design system, 478 variables and 5 color modes · development storyboard · marketing website, scully-ai.com · brand book · film · brand portal.
**The pipeline**: 01 Prototype, live in Claude Design, every state real · 02 MCP into Figma, tokens and structure moved across, not redrawn · 03 Two Figma files, the system and the screens, linked · 04 Developers build from the files, not from screenshots.
Sources: the case text and Daniel's notes. No invented data.

System and handoff

A system you change in one place

Five modes{{ activeCase.dsThemeCap }}

Five color modes · 0:17 · No soundRecorded in the clickable prototype. One set of components serves every mode, so no screen is designed twice.

What you see

The same dashboard in Dark Graphite, Dark Emerald and Dark. The theme toggle switches to Light Snow, then Light, and back to Dark and Dark Graphite. Layout and components stay the same; only color changes.

Every feature is a script

Script cover{{ cv.c }}

Flagship

Sixteen features, four that carry it

{{ fs.t }} {{ fs.c }} Dark

Watch two of them run

Workflow editor · 0:24 · No soundRecorded in the clickable prototype. Problems show up where they are fixed, not after an agent goes live.

What you see

An Execution step is added to a workflow. Validate flags 3 problems and the inspector lists them. An agent, an instruction and a tool are chosen, and Validate passes: 7 steps. Run Test then shows each step with its timing, all ticks green.

RAG Config Builder · 0:25 · No soundRecorded in the clickable prototype. Each setting arrives with its reason, so teams can check it before trusting it.

What you see

An agent is described in plain language and a sample file of 1,284 records is uploaded. Generate streams a configuration. The result is marked valid, with an Explanation of the search backend, weighted fields, filters and scoring. Sample output, prepared for the prototype.

Decisions

What I chose, and what I left

Part 2 · Brand

Identity and system

One lockup, one accent, a calm voice

Navy on cream

Navy on white

White on navy

White on a dark image

1Navy lockup on cream and white.
2White lockup on navy and dark images.
3No third version: no amber, gray, gradient or outline.

Two versions onlyThe ground picks the version, so no one decides it case by case.

Cream#f4f1e9 · about 60%Ground · brand-cream
Navy#0a0f2e · about 25%Ink and headlines · brand-navy
Warm grey#55504a · about 10%Body text · text-body
Amber#fe9f03 · 5% or lessAccent · brand-amber

White (brand-white #ffffff): cards only.

Proportion, not paletteAmber stays at 5% or less so it can point without shouting.

Agents that do the work, under your rules.

Switzer 400 · headlines

Plain, specific and calm. The senior architect who's done it.

Inter 400 / 500 / 700 · reading

Type rolesOne family to speak, one to read, so every page sounds the same.

Road not taken · Oct 20After 20+ directions, I took a house-of-agents logo as far as a film; my manager did not approve it, so the live lockup stayed.

A design system for people and AI tools

Components: 35
Color tokens: 39 x 2 themes
Imagery families: 7
DS: v1.6.1

Light Silk · default ground

Navy Silk · the one dark moment

Silk family · since v1.6.0Born on the portal, Silk replaced the old Light waves backgrounds for new work.

Color pairs with contrast ratios
Pair	Ratio	Level
Ink on creambrand-navy on brand-cream	16.6:1	AAA
Text body on creamtext-body on brand-cream	7.1:1	AAA
Accent text on creamaccent-text on brand-cream	5.3:1	AA
Amber on navybrand-amber on brand-navy	9.1:1	AAA
White on navybrand-white on brand-navy	18.7:1	AAA
Text muted on creamtext-muted on brand-cream	3.3:1	Large only
Amber on creambrand-amber on brand-cream	1.8:1	Never text

Rated pairsWhen words need the accent, darker accent-text stands in and passes AA.

Brand book · Extended p76Showing the wrong version next to the right one stops a rule being misread.

Silkopeners

Navy platescharts and data

Glassproduct

Clayarchitecture

Sectorsindustries

AI agent

Portraitsagents

Film stillsvideo

Navy Silk opens and closes; navy plates hold charts. The amber line is never cropped out.

Seven familiesAll made in-house, no stock and no baked text, so every image stays ours.

A book for the rules, a portal for everyone else

Extended edition

113

pages · rules and wording
26

pages · slim edition, for teams and agencies
Recipe kit

106

pages · the prompts behind the imagery

Three editionsOne book, cut per reader, so nobody reads 113 pages to make a slide.

Recipe kit · 1a Sculpted ribbon plate · part 1 of 2

Fixed: keep word for word
{Slot}: change within the range

Pure abstract texture photograph, no typography whatsoever. Soft sculpted matte ribbons of warm cream and pale ivory with faint cool pale-blue shadows, gentle diffused studio light from the upper left, subtle fine grain. {FORM: Parallel ribbons flow horizontally edge to edge; near the center, slightly above the middle, they gently crowd together and rise into one smooth calm audio-waveform swell, tallest at the center, tapering to flat quiet ribbons at both sides.} A single very thin warm amber highlight line runs along the top of the crest of the tallest ribbon only, not in a groove.

Slot range: 3 approved forms (horizontal swell, concentric arcs, diagonal pulse).

Recipe kit · promptWritten for whoever generates next, so the look survives without me in the room.

Brand portal · privateBuilt in the website's look, so the portal itself teaches the brand.

01StoryScully does real work and says it plainly.

02VoicePlain words, real outcomes, a source for every number.

03LogoThe lockup is our signature, so we never edit it.

04ColorCalm is a color choice: mostly cream, amber only to point.

05TypeQuiet type sounds confident: Switzer to headline, Inter to read.

06ImageryOne family per frame keeps every image calm and ours.

07Use itMost work needs no approval; the rules exist so you can ship.

08FilesCopies of copies are where a brand breaks first.

Eight sectionsEach section opens with one line of why, before any rule.

Brand book, slim editionThe 26 boards behind this page.PDF · 6.6 MB
Lockup, navyFor cream and white grounds.SVG · 12.3 KB
Lockup, whiteFor navy and dark images.SVG · 12.2 KB
Small SFavicons and app icons, 32px or smaller.SVG · 0.7 KB
Silk backgrounds · 1920For slides, social and web.ZIP · 8 JPG · 2.0 MB
Silk print mastersFor print and large screens.ZIP · 8 JPG · 21.5 MB

FilesSame names as the design system, so nobody works from a copy.

Portal message when reduced motion is on: Motion is reduced to match your device setting.

The portal's Pause button for the moving hero, reading: Motion off

prefers-reduced-motion: reduce

Reduced motionMotion is optional: a Pause control, plus a full version for reduced-motion settings.

Three sources, one version line

Brand book (Figma)Rules and wording
From Brand book to Portal: wording: the book wins
PortalSlim edition and downloads
From Design system to Portal: files: same names
Design systemValues and files
From Portal back to Brand book: sync-check.py: portal text vs book

Every plan that touches one ends with a sync step.

Brand syncOne home per fact, so there is only one place to be right.

Brand book v2.2 · DS v1.6.1 · Nov 2026book footer, 108 of 113 Extended and 24 of 26 Slim pages
Brand book v2.2 · DS v1.6.1 · Brand owner: Daniel Motzaportal, 8 section footers
version: 1.6.1DESIGN.md front matter, which names book v2.2

On all three: Brand book v2.2 · DS v1.6.1

One version lineAnyone holding a page can tell at a glance if it is current.

Website

A website an executive gets in 30 seconds

See it live: scully-ai.com (opens in a new tab)

Film

A film led by one agent

Clara film · 2:57 · 15 MB · Has sound

What happens in the film

Outcomes

{{ w.t }}

{{ t.wk_heading }}

{{ w.title }}

{{ t.rc_heading }}

{{ t.ab2_heading }}

{{ t.lead_kicker }}

{{ t.lead_sub }}

{{ t.pr_heading }}

Discovery & research

Strategy & definition

Design & systems

Prototype & validate

Ship & iterate

Discovery & research

Strategy & definition

Design & systems

Prototype & validate

Ship & iterate

Tools I use

{{ t.ct_heading }}

Lost in deep space.

Houston, we have a problem.