Designer who also builds

Affan

12

years of experience

Figma Origami Framer Claude Design Conductor

What I do

Design systems Create and implement, tokens to shipped components.
End-to-end product design Research, planning, flows, UI/UX, and success metrics.
Zero to one Coming up with new and innovative ways to push the business forward.
Marketing assets Sizzle reels and marketing site redesigns.
Full app development iOS, Mac, web, and the backend behind them.
dyeary

dyeary

available on iOS and Desktop

View demo

{{ takenToIt }}

reducto

A document intelligence platform.

Founding Product Designer · Sept 2025 – July 2026

What do they do?

reducto is a document processing company. Simply put, many companies have heaps of documents. They are looking for a way to take that content out of them. Frontier models aren't really great at getting this content out cheaply, so they turn to reducto. It's the largest company in the space and trusted by many big names.

Harvey
Apple
Legora
Fidelity
01
Studio redesign Rebuilt the entire site end to end with a brand new design system
02
Evaluate Compare pipeline runs against ground truth to tune cost and accuracy.
Redesigned homepageRedesigned edit screen Old homepageOld edit screen
Before After
Reducto Studio, dark modeReducto Studio, light mode

Redesign Outcome

From a fresh component set to a shared system the whole team could build on.

01
Redid every component Every single component in the product, rebuilt from scratch.
02
Helped implement it Coded many of the components myself!
03
Design system in Claude Design Uploaded the system so we could all iterate faster.

Evaluate

Getting the most accurate, cost effective results from reducto

Millions
of docs

Customers run thousands, sometimes millions, of documents at a time. A single job can take the entire weekend, so nobody wants to get it wrong.

Studio playground, configuration tab Studio playground, results tab

Example of health document

Before the big run, they rehearse in Studio

A visual tool on top of our API, where teams iterate on a handful of documents before committing to the whole batch.

01 Pick key documents If the documents share repeating structures, they choose 5 to 10 unique ones.
02 Test and iterate Run them through reducto in the playground and tune until the results look right.
03 Run the full job Once they are happy, they kick off the large run.

But what does happy{{ smileSvg }} mean?

Apple
01
Pull everything out of a resume Apple runs a huge volume of resumes through reducto to extract what's in them.
02
The styling doesn't matter Every resume carries the same kinds of information. Fonts, columns and layout are noise.
03
Strip it, then search it With the styling gone, they can search and filter candidates in their own tools.

Evaluate v1

We created an evaluate feature where we would grade the results of each file. It would give suggestions for improvements and an overall score. The score was developed by a pricer, more accurate model. You can't run those on the larger runs but it's great for testing.

People loved the suggestions but didn't really trust the numbers.

The evaluation tool comparing pipeline runs against ground truth

Evaluate v2

So we stripped out the grading aspect, and added the suggestions to the editing experience. Most people didn't need all the nitty gritty grading details.

Evaluate v3

The score on its own wasn't enough to earn trust. Eventually we'll give people the support to go in and see the grading on a field by field level, so every number can be traced back to the exact value it came from.

Field by field grading in the evaluation tool

Evaluate Outcome

What shipped, what got cut, and what came next.

01
Optimize Schema was a big success It helps the majority of our users improve their results.
02
First evaluation was deprecated Grading is coming soon.
03
Next step: confidence Conveying correctness and confidence at the same time was a hard design problem.

Runbook

AI agents for physical operations.

Founding Product Designer · So far a 1.5 month contract

The AI workforce for field services

Runbook builds long-running AI agents for field services and transportation companies: fire and security inspectors, building controls providers, freight carriers. Runbook handles the busy work around a work order, from first call to final invoice.

We reach any system a person can, through APIs, browsers, Virtual Machines, phone, text, etc. This is done by simulating their workflows within Runbook.

Runbook · The last six weeks

What I worked on

01
Full redesign of the app
02
Revamp of the marketing site
03
Issues redesign

{{ carTitle }}

{{ shot.label }}
{{ shot.label }}
{{ lightboxLabel }} {{ lightboxLabel }}

Setting up a new customer

During onboarding, we breakdown their workflows like this. The general workflow is easy to distill from something called backtesting . This is where we analyze previous work orders and find common solutions between each thing.

However there's a TON of niche situations that can only be attained by follow up engagement with the customer.

Workflow from backtesting
Needs the customer
Work order comes in
Match the site and asset
Estimate the job duration
How long does it really take?
Schedule a technician
Check escalation rules
When should this escalate?
Close out and invoice

Getting the knowledge out

That knowledge typically comes from huge Zoom meetings with numerous heads at the company. They're hours long and can be quite draining.

Our ops people can't keep track of all the special situations.

Onboarding call · Session 3
VP
VP Operations
DL
Dispatch lead
SM
Service manager
FS
Field supervisor
BI
Billing
RM
Regional manager
IT
IT admin
OP
Runbook ops
+6
6 more
Workflow updates
New exceptionTwo sites share one address0:58:20
Step reorderedPermit check before dispatch1:39:52
New exceptionTwo sites share one address0:58:20
Step reorderedPermit check before dispatch1:39:52

Problem statement

How might we capture a customer's entire workflow without hours of draining calls?

New Issues Experience

I created an issues experience. Similar to Linear, our customers could create "issue tickets" that would be assigned to our internal ops. Anytime there was a problem with an existing workflow, our customers could flag it to our ops.

However, there was a problem, no one used it.

The old issue detail: what went wrong, what should have happened, auto-fix attempts, follow-up questions

Why no adoption?

  1. The experience was overwhelming
  2. Did not fit into current ops people's workflow
  3. Very little to no notifications
Page 1: template and title A question with a conflict table and answer box A mapping table with conflicts
A full page of the field questions document

Training & notifications

Slack channel integration where our ops and our customers both got Slack notifications.

We also trained our ops people to train our customers on the new Issues experience.

Runbook#runbook-issues
Assigned to you
How long does a rooftop unit job really take?
Filed by Runbook ops · 2 min ago
Runbook#runbook-issues
Issue updated
When should after-hours calls escalate?
Answered by Dispatch lead · just now

Rich issue details

Embedded HTML content

New issue detail with embedded tables
Old issue detail page
Before After

Autofix vs Conductor

Ops worried customers could see the chat

Embedded autofix 😞

Autofix chat embedded in the issue with follow-up questions

Conductor session 😄

Open in Conductor
Autofix
Status Open

Issues Outcome

Issues filed per day

On average
Before
0
After
66

Time to adopt a new workflow

Down from 4 weeks
Week 1Week 2Week 3Week 4
Before
4 weeks
After
1 week
View the prototype

A proper goodbye

Everyone dressed as me as a goodbye to my contract role. Even though it was 2 months long.

The Runbook team dressed in sunglasses and patterned shirts