# Jill Pierce — Design Technologist

**I design and build tools that make everyday work effortless.**

Somewhere in your company there is a spreadsheet with eleven tabs, a colour code, and exactly
one person who understands it. I build the thing that replaces it.

- **Location:** Washington, DC · Remote
- **Looking for:** full-time or contract roles — product, platform, internal tools, design systems
- **Email:** jillpierceux@gmail.com
- **LinkedIn:** linkedin.com/in/jillpierceux
- **Experience:** 8+ years designing and building · Certified Airtable Builder (2024) · Google UX Design Certificate (2024)

## Positioning

I came into design sideways, through operations — five years running the systems before I ever
opened Figma. I have built somewhere north of fifty product-level apps in Airtable since.

I am not an engineer and I do not pretend to be. I started as an analyst who knew some SQL and
enough data modelling to be dangerous, then wrote Apps Script because nobody else was going to,
and now I work in an IDE and am still learning to push and pull from a repo. What I can do is
build the thing, and say honestly when it needs someone better than me.

## Case study 1 — Association for Talent Development (2015–24)
### Designing the service, then building the operation

Research settled who the company's second-largest revenue stream was actually for. I then designed
and built the system that delivered it — an 80% drop in manual coordination, and forecasting on live data.

| Metric | Value |
|---|---|
| Manual coordination | ~80% reduction |
| Satisfaction (internal reporting system) | 95% |
| Research projects led | 150+ |
| Revenue line | 2nd largest in the business |

**Discover** — Product decisions were being made on instinct. Qualitative research paired with
analytics, synthesized through jobs-to-be-done, produced three archetypes: the accidental
practitioner (wants a sequenced curriculum), the newly responsible (wants one-to-one coaching),
the restless expert (wants open exploration).

**Define** — Those three formats are structurally incompatible. Over 30 courses ran across
in-person, live online and on-demand, each modality in its own file with its own cost structure.
Finance rebuilt the budget by hand each month, knowing it would be wrong by Friday.

**Develop** — Three layers: a catalog of what we offer, an operational layer for what is running,
and a decision layer where sales data met scheduled offerings. Each modality got its own surface,
sharing one course reference and cost structure underneath.

**Build** — The data model (entity relationships across courses, sessions, instructors, locations,
enrollments, including many-to-many structures), the formulas and scripts driving scheduling logic,
cost rollups and automated notifications, and every interface in the system. Facilitator evaluations
rolled up nightly from a CSV, with row-level filtering so each facilitator saw only their own results.

**Outcome** — Financial data attached directly to the activity record, so budget became a rollup of
what was actually happening rather than a separate estimate.

**Reflect** — Adoption was harder than the build. What worked was narrowing to one use case, proving
it, and letting the result recruit the next team. I would plan that sequence of proof points from the start.

## Case study 2 — Verizon, contract (Feb 2025 – Jun 2026)
### Growing a practice, not just building tools

An 800-person organization ran rigorous process for its customers and spreadsheets for itself.
I owned the internal tools platform: the standards, the practice around it, and roughly twenty
things built on top.

| Metric | Value |
|---|---|
| Custom extensions shipped | 10+ (Airtable and Figma SDKs) |
| Separate bases built | ~10 |
| Daily active users | ~60 |
| Organization served | 800 people |

**Team topology** — Merged Jira, spreadsheets and team-owned files into one Airtable base with the
transformation and cleanup needed to reconcile them, modelled ownership so defects resolved by team
and sub-team, then built it as a custom Airtable extension rendered in D3 on live data. Route:
Figma Make prototype → GitHub Copilot to rebuild against real Verizon Design System components →
Airtable SDK for live data.

**Project workflow** — Connected the Google Directory API so stakeholder identity came from the
source of truth. Hand-typed names rot; nobody notices until a handoff fails.

**Enablement** — A standards playbook written as an instruction manual rather than a rulebook, plus
four ways to get help: course access, monthly office hours, a Slack channel, and being available.

**Plugins and extensions** — A Figma plugin piping live product-card data into design tiles
(Figma Plugin API + GitHub Copilot). An AI tool registry shipped as a Google Apps Script web app,
open to anyone with Workspace access, no license required.

## Built with AI

Two D3 data visualizations built with Hyperagent and GitHub Copilot: a chord diagram of genre
composition by decade, and a stream graph of genre volume across seven decades (700 songs).
I direct, it writes the D3. What I bring is what is worth visualizing, how it should be encoded,
and whether the result can be read.

## Toolkit

- **Build & data:** Airtable SDK · Figma Plugin API · JavaScript · D3.js · Apps Script · SQL · Power BI · Looker
- **Product design:** Figma · prototypes · component standards · usability testing · journey maps · WCAG 2.1
- **AI:** GitHub Copilot · Claude · AI-assisted prototyping
- **Certified:** Airtable Builder (2024) · Google UX Design (2024)

Much of my work runs on Airtable. It is the right tool when the operation has to keep running while
you replace it. The judgement is knowing when it stops being the right tool — and saying so before
someone else has to.

## How I work

1. **Design backward from the question** — not forward from the data you happen to have.
2. **Restraint is the design work** — a broad system invites you to put everything on every page.
3. **Adoption is the hard part** — narrow to one use case, prove it, let the result recruit the next team.