# Jordan Batch
Senior Manager, UX Design. Dublin, California.
Leading design teams, and building the systems behind them.
I make success more likely and faster through design.
Eighteen years designing, while building design teams where there were none and keeping them through acquisitions. Now attempting to teach the machine spirit taste, so judgment scales as fast as the output.
Driven by advancing human-computer interaction through delight.
## Career Eras
### Enterprise AI
- **HPE** — Sr Manager, UX Design — 2020 → Now
Leads UX for Mist, the AI-native networking platform. Held the design team together through the Juniper and then HPE acquisitions, and built the practice around Marvis, the network assistant. Co-authored four US patent filings, two granted, on conversational network assistants and device onboarding.
### Head of Design
- **Wescover** — Head of Design — 2019
The marketplace connecting people to the makers behind local work. Led quantitative research and the core feature and flow development.
- **Streamlabs** — Head of Design — 2017
Hired and directed a 15-person creative team across product, motion, brand, copy, and audio. Built the pipeline that turned high-fidelity motion graphics into production-ready pages.
- **Backbone** — Founding Designer — 2017
Took a manufacturing ERP from zero to one against a state-mandated compliance deadline. Owned UI, brand, research, and the interface engineering, including a custom React component library. Grew the team from three to nine and reached $300K ARR on $1M+ in bookings.
### Founder
- **PucaTrade** — Design Lead & Engineer — 2015
Lead product designer and interface engineer. Owned onboarding and retention, branding and art direction, community, partnerships, and UI.
- **Grid** — Design Founder — 2014
Design founder on an inspiration and culture platform for creatives, part Pinterest, part reader, part tool. Brand, product, and the teaser film that introduced it.
- **Coin** — Founding Designer — 2012
Founding designer from pre-YC through soft launch. The One Card crowdfunding campaign pulled millions in preorders and 10M+ views. Later acquired by Fitbit.
- **Heighten** — Founding Designer — 2012
Early founding designer on a sales productivity platform. Owned product design, brand identity, marketing, and the interaction language from inception. Later acquired by LinkedIn.
- **Blueboard** — Founding Designer — 2012
Early designer, pre-500 Startups (Batch 18).
### Creative Agencies
- **Takifugu** — Co-Founder — 2012
Co-founded a design studio focused on product and creative services for startups.
- **Punchcut** — Interaction Designer — 2012
Designed software products and concepts for Fortune 100 clients at the SF interface-design studio.
- **ROI-DNA** — Art Director — 2011
Art director at the marketing and demand-generation agency.
- **Sony** — CG Intern — 2011
Computer graphics intern for Sony at NAB 2011. Creative software and 3D video integration and editing.
- **SPARK** — Digital Artist Supervisor — 2009
Supervised a team of creatives producing film and print work for clients including the NBA Orlando Magic and Full Sail University.
## Selected Work
### 2026
#### Changing how design gets made
Bringing LLMs into the product process, and the org challenges that came with it. Winning the resources, and getting a team that was already doing too much to change how it works.
#### One step up the ladder
Six years moving a design team from the bottom of the maturity ladder to a system the whole company works inside. Two full steps climbed, a real reach at the third, 974 features shipped through a process with design as a required gate.
#### The Mist component library
Seven different libraries just for buttons. Six product pods at roughly fifty engineers to every designer, so a shared library was the only real leverage. 36 components to 390, 1,140 variants, 75 screens rebuilt.
### 2025
#### Live View, Mist’s real-time building analytics
Your building, live. Live View was one of Mist’s most-loved features, and it was losing ground. We rebuilt it around the one pain every customer named, following a device between floors, and named the fix for what it was: a floor stack, not a building.
#### Marvis, Mist’s AI network assistant
We went from a small ecommerce-style ML chat bot to a full LLM agent. It builds its responses and surfaces from natural-language intent rather than fixed menus. Dynamic, personalized apps enabled by LLMs are the next shift in HCI.
### 2021
#### Patents, conversational AI and device onboarding
Four filings, two granted, co-authored. The conversational pair came out of Marvis. GUI inside the chat, so you troubleshoot in the conversation instead of leaving it.
[US 12,040,934 B1](https://patents.google.com/patent/US12040934B1/en)
[US 2022/0417742 A1](https://patents.google.com/patent/US20220417742A1/en)
### ∞
#### Alterist, a marketplace for trading card art
I wanted to see how far LLM tools could take a solo designer. It's powered by open source ML models for search, related art, and personalized feeds. Built solo with Claude Code.
[alterist.co](https://alterist.co)
#### Analog Archive, a library of aesthetics
It started as a reference blog and turned into a spec. 1,882 images sorted into eighteen aesthetics across six medium families. The closest I have come to writing my own eye down.
[analog-archive.co](https://analog-archive.co)
#### Graphic design
Freelance pieces for friends and for communities I belong to. Marks, and the physical things they end up on.
#### Photography
Weekends, longer trips abroad, and occasionally a friend's pet. This is the quiet end of my range. Most of what I know about restraint I worked out here first, without meaning to.
[Instagram](https://www.instagram.com/jordanbatch/)
## Case studies
### One step up the ladder
Mist · 2020 to 2026
Every design team stands on a step of a maturity ladder. Most never climb.
A hand drawn diagram of five numbered steps rising left to right. Solid arcs carry the climb from step one to two and from two to three. A dashed arc leaves step three toward four and stops before it lands.
#### What I inherited
At the bottom step, design is a service. It gets called in at the end to make a decision look good, and it is not in the room when the decision gets made. That was the team I inherited at Mist, an enterprise networking company that was acquired by Juniper and then HPE while I was there. This is the story of moving it up, on purpose, over six years.
There are three things you have to move at once.
1. How the org sees design.
2. What design can actually do.
3. How far design thinking spreads into the people who are not designers, so it is still in the room when we are not.
Perception, ability, influence. Move one without the others and it does not hold.
#### Why this matters
This is no shock to any designer, but design adds value. Exactly how much? McKinsey tracked 300 public companies for five years, and the ones strongest at design grew revenue 32% faster and returned 56% more to shareholders than their peers. Adobe ties the top tier of design maturity to loyalty, market share, and lasting advantage. And most teams never climb: when InVision surveyed 2,200 companies, 41% were still on the bottom step and 5% had reached the top. Where design sits on the ladder is a business outcome.
It matters inside the team too. The thing I refuse to have, at any job level, is an execution designer. Someone who takes a decision already made and just draws it. Every designer on my team is expected to think product, to own the why behind their choices, and to push back on anyone, however senior, if the logic does not hold. And they know I will back them when they do. You cannot run a team like that from the bottom step. The org will not let you.
#### The ladder
The industry has drawn these maps a few times. Adobe, McKinsey, InVision, and Nielsen Norman all chart the same climb, from design as an afterthought to design as a driver of the business. The first version dates to 2006. The ones everyone cites came from 2018 on. I had been aiming at the top of it for years, and it was my own playbook I used once I joined Mist.
The one I follow closest is InVision’s. These are my names for its five steps, each defined by where design stands in the org and by what it is not yet doing:
1. **Service.** Design makes it look good. Called in at the end, not in the room. Not yet: a say in what gets built.
2. **Partner.** In the room from the start, as a required step, for the features it works on. Not yet: a repeatable system. The practice lives in a few people.
3. **System.** A repeatable operation the whole company knows how to work with, spreading to teams design does not own. Not yet: measuring its own impact.
4. **Scientist.** Hypotheses and experiments power the work. Design measures its own impact in business terms. Not yet: setting direction.
5. **Driver.** Design sets direction. Integral to the business. The top 5%.
When I joined we were on the bottom step, and we were failing even at that. Seven libraries just for buttons. An app that looked dated and inconsistent, with customers and VPs complaining about the same things. Nothing connected what design drew to what engineering shipped.
#### What I did
I thought of it as a five-year plan on two tracks. One, the visual identity: I phased the component library and the refactor first, so that once it was in place we could uplift the visuals and branding at the same time. Two, growing design’s influence across Mist and the parent company. Looking back, those tracks are ability and influence. Perception is what you earn by doing both.
Three steps, in order. Each one starts with what I did, then how it went.
The five-step ladder with the first step filled in and an arc landing on it. Small in the corner, two hands meeting in a high five: the partner step this section climbs to.
##### Service to Partner
*The weekly critique · A weekly table with product and engineering · The component library, started · A team that thinks product*
There was no top-down mandate for more design, so I had to build it from below. It started slow, by asking more questions of our product partners. Mostly out of curiosity, but also to quietly get them to think like a designer. What I found was not a lack of desire for design. It was a lack of knowledge of what design is and what it can do. One of our engineering leads put it better than I could:
> PMs and engineers don’t always understand all that goes into UX. They just see it as UI design. They don’t see that you’re doing a lot of the legwork, problem solving, and coming up with a lot of the requirements that saves time when it comes down to actual development. That upfront time spent saves a lot of time down the pipeline.
> — Engineering lead, Mist
So most of the work was ground level: providing more value to the people willing to listen, and still working on the skeptics. One of the first changes was a **weekly design critique**. A place to talk shop and share creative ideas. Not just work, but what we were seeing outside the industry. Culture only crystallizes when it is a habit. I added a **weekly product meeting** where I sat with the head of UI engineering and the PMs. I kicked off the **component library** effort with my engineering peers. And once I hired more designers and they made the approach their own, their voices carried the goodwill and change I was building without me needing to be in the room.
I **promoted** my designers as the org leveled up. Most of them came in junior with little product experience, and I got them there by teaching them how to think, what to look for, and by advocating for them relentlessly. I was giving them the assignments leadership would see, and talking them up when I did not need to. One went from intern to mid-level. I trained them to think of the product holistically, and kept prompting them on how their feature would fold into the greater whole, until they found their own version of it.
> My job isn’t just to make a screen for you. I’m here to solve a product problem.
> — One of my designers
My best designers would have done great work without me. My job was to make it more likely, and faster. When a designer hit a wall, we jammed: sat together and built ideas out loud until the direction was clear. And the other half of asking designers to push back is backing them when they do. When it came from above, I took it up the chain myself. Day to day, I removed friction ahead of them where I could, and stepped in when they wanted me to, not before.
It was not free. I was as empathetic and patient as I could be with the PMs reluctant to work in this new way, and I still could not win them all. Some built up resentment to what I was doing. I spent the extra time with them anyway.
By the end of this step, design was in the room from the start. It was not yet a system, and the practice only lived in a few people.
The same ladder, now with the first two steps filled and a second arc landing on the second. Small in the corner, meshed gears: the system step this section climbs to.
##### Partner to System
*The feature process · The machine · The component library, then code-first · The quarterly workshop · The adopted designers*
System is where design becomes a repeatable operation the whole company knows how to work with, and where design took real partnership with product on what to build and how much design each feature deserved. The PM directors came with the list. I worked out the order and phasing with them, feature by feature. I did not win that by asking for it. I won it with process.
With my director-level peers I designed and documented **the process** every feature goes through, from PM inception through design, stakeholder sign-off, QA, and engineering. I will admit it is a bit waterfall methodology shaped, but it works for this team. Two rules made it hold. No UI ticket gets created unless there is a closed UX ticket linked to it. And only one PM and one designer are attached to a feature. Explicit ownership, and it inherently fights off design by committee. Over six years we shipped 974 features through that process. In practice the gate rarely blocked anyone: every vertical had a dedicated designer, and when a PM needed something fast, a fifteen-minute design session settled it. If the idea was good, it went through.
Keeping **that machine** scheduled and fed is one of my core jobs, and I designed it in two parts. Once a quarter I sat with each product vertical to schedule and prioritize the big rocks. Day to day, each PM vertical has a dedicated designer they can reach directly for small work. Important features with messy dependencies get scheduled, and small urgent things do not get blocked by process. It keeps the flow of work moving, and it gives me a machine with a few windows to see in and monitor performance.
**The component library** I had kicked off became the system itself: seven button libraries into one governed source of truth, 36 components to 390, wired to production code. I moved the team to code-first prototypes: a design became something engineers and PMs could click through instead of a screen to interpret, the prototype became the shared source of truth, and design to first draft went from three days to same day.
**The quarterly UX workshop** came next, and it is where research and usability entered the process for the first time. I ran the first one to teach it, then each designer takes a turn leading one, on an outline I wrote, with me coaching from the side. Users are involved early, so we are not guessing in a clean room, and we go wide before focusing down to one direction. Experimentation went up, and so did the quality of the end work.
The practice also had to grow past my own team. Once I had three designers reporting to me, I ran out of funding and the ability to open new reqs from leadership. So I went looking elsewhere in the larger org. There were eight designers and researchers scattered across the parent company, managed by engineers, none reporting to a designer. I reached out one by one and **adopted** them into my weekly UX to work as one team. They stayed where they were in the org tree, and I was not responsible for their assignments or promotions, but I took on a sense of ownership for developing their talent and for being a larger team they could be part of. It became a real team event, a room of their own, and the product got more consistent across all the software teams. Slowly my team’s component library, product thinking, and app architecture became the standard the other teams adopted. Partly because my product team was the most successful and people follow the leader. Partly because I evangelized it.
By the end of this step, design’s process ran across the company whether or not a designer was in the room. What we could not show was the metrics behind it paying off.
The same ladder with the first three steps filled. Two solid arcs, then a dashed one that leaves the third step toward the fourth and stops short: the only broken arrow in the set. Small in the corner, a thought cloud, the scientist step this section reaches for and does not land.
##### Reaching for Scientist
*A hypothesis · Measured after launch*
I want to be honest about where the climb stopped. Scientist is data-driven design. Experiments, analytics, measured impact, hypotheses tied to the business. We grazed it on individual features, but I would not claim we got there as a repeated system yet.
The workshops pushed experimentation up, and so did the work. But experimentation and measurement as a discipline, the kind you can put in front of a CFO, was the step we did not reach. Partly budget. Partly a ratio of 50 engineers for every designer. Partly something design could not fix on its own.
There was a reason the metrics mattered. When a team ships so many features every week, over the years it builds up. Features go unused, redundant, or directly compete with each other. Our vertical product structure made it worse, because each PM was valued on what their vertical shipped, not on the product as a whole. When design was involved early, we captured metrics to understand the problem and shape a **hypothesis**, then **measured** the feature after launch, and a few times I successfully used those numbers to get features cut or consolidated. One small example: Marvis, the AI assistant our customers use to troubleshoot their networks, had four interactive pages left over from the product’s early days. Analytics showed five people had clicked into them in 90 days and none had interacted. I put that in front of the VPs, made the case, and got permission to cut them.
The numbers cut the other way too. A later redesign of the main Marvis Actions page tripled visits to 11% while under 1% of those visitors did anything and the new ones did not come back. Visits without return is a churn signal, not a win. Reading it that way, before the next feature got built, is the habit we were trying to build.
By the end of this step, we could measure a feature when design got in early. We could not yet measure as a repeatable practice.
#### Two steps up
Two full steps up a ladder most teams never move on, and a real reach at the third. Design went from the last stop before shipping to a system the whole company works inside, with a practice that spread to teams it does not own. One core team, held together through two acquisitions. Mutual trust and respect is a hard thing to build. We had it. The numbers underneath it:
- **2 of 5** steps climbed, reaching for the third
- **974** features shipped through a process with design as a required gate
- **1 → 11** designers in the practice: three on my team, eight adopted from across the company
- **36 → 390** components, one source of truth
- **2** acquisitions the core team held together through
The climb, lane by lane
**Service → Partner**
- Perception: questions for PMs, weekly with product
- Ability: the library started, designers promoted
- Influence: the weekly critique, carried without me
**Partner → System**
- Perception: the process, 2 gates, quarterly planning, a say in the order
- Ability: 36 → 390 components, prototypes in code, quarterly workshops
- Influence: 8 designers adopted, our standard spread
**System → Scientist**
- Perception: no change
- Ability: metrics up front, cut on the numbers
- Influence: no change
#### What I learned
##### Maturity is a team sport
Here is what the ladder diagrams leave out. Past a certain step, design cannot climb alone. To get to the top, the other orgs have to level up and follow. Product, engineering, leadership. There is only so far you can go on your own inside your org. Design maturity is capped by the maturity of everyone around it. Adobe’s model says it plainly: "A design-centric company doesn’t just happen. It takes planning, strategizing, and confidence in moving forward." It takes the company, not the design team.
The clearest proof that influence worked is also where perception stopped. Ideas that later became roadmap priorities started from my UX team and got elevated in meetings design was not in. Months later I heard, in their words, "I see now what you were saying." That is lag, not neglect: influence had run ahead of perception. Being right early is half the job. Being legible to the people who decide is the other half: putting the work in front of them, with design’s name on it, before someone else carries it in. Five years in, I put this ladder itself in front of leadership and asked where we sat. A seat at the table is easiest to have from the start, and hardest to earn late.
That is also the honest answer to the argument about who owns deciding what to build, product or design. Product is accountable for the call. But the call only holds when design, engineering, and the business are bought in, because the work is iterative and nobody gets it right in one pass. What design owns is getting to the root cause and the experience, and earning enough trust to be in the room when the call gets made.
##### Ship to earn the seat
You cannot boil the ocean. Every step we climbed, we climbed one process, one component, one shipped win at a time, and then we spent that credit. The seat follows the proof.
##### Set the target, not the path
The workshops taught me the balance: a direction tight enough that everyone knows their role, and loose enough that the team still surprises you.
##### The least invested move first
The people with the least to defend moved first; it was the junior PMs who attached to the change the quickest. The resistance was worth the extra patience, and I would plan for it from day one next time, because resistance is usually the cost of having actually moved something.
And the steps we did not reach were not design’s to climb alone. That is the next climb, and it needs the whole company on the ladder.
Read it at https://jordanbat.ch/work/one-step-up-the-ladder
### The Mist component library
Mist · 2023 to 2026
What do you do when your app has seven different libraries just for buttons? You get to work.
The new Mist library: a set of custom line icons beside its components, a Save, Cancel, disabled Locate and status tag, a site selector, and a switch port panel with its CPU, memory, temperature and PoE indicators.
Close up: a date range component open on its Custom Date tab, beside the type scale set in network copy, from Switches and Virtual Chassis down to the monospace hostname sw-ex4400-04.
A Mist switch detail page rebuilt on the new component library.
The system up close, and a page rebuilt on it
#### What I inherited
That was a real finding. It was also the symptom of a much bigger problem, and fixing it became the largest and longest effort I have led.
I lead UX across six product pods at Mist, each with its own dev team, at a ratio of roughly fifty engineers to every designer. I inherited an app and a visual system that everyone called dated, VPs internally and customers externally.
An audit sheet of buttons from seven separate libraries in the same app: ui-common, ui-kit outline, ui-kit Primary, link buttons, marvis chatbot, toolkit and misc. Fifty-three buttons in all, in different shapes, radii, blues, reds and letter cases, with no two sharing an edge.
Fifty-three buttons, seven libraries, one app
At that scale, design could not hold the line by hand. If a handoff did not spell out that an element was reused elsewhere, engineering rebuilt it from scratch. Even when we did call it out, the shipped UI drifted: spacing off, type sizes off, consistency gone.
A shared library was the only real leverage at that ratio. It bakes consistency into the work itself, frees the designers for the work only they can do (designing, not nitpicking agreed standards), and makes a design decision keep holding long after it leaves our hands.
We wanted a rebrand. But there was no foundation to build it on, and there is no point polishing hover states and moments of joy with no component library to make them repeatable. So before any of that, I set out to build the foundation.
#### One page at a time
The trap I wanted to avoid: I have watched teams try to rewrite the whole app on a branch of its own and never merge for years, while the real product keeps shipping bugs and features around them. You never catch up.
So I aimed small on purpose. Make the new components look slightly better, but consistent with how the app already looked. Then rip and replace one element at a time, page by page, arming the dev team with more each week, until the whole app was componentized. The rebrand could come after.
#### Winning the resources
The hard part was not design. It was that this would eat engineering resources for a long time, and open-ended asks like that do not get funded on ambition alone. So I tied it to what the business already wanted: accessibility, which our government contracts required, and dark mode, which customers kept asking for. My foundation became the way to deliver a mandate leadership already had to pay for.
And you cannot build something this size on your own. I found champions to carry it with me, the manager support to protect the time and the engineering peers to do the work. Everyone had their own roadmap pulling at them. The job was getting us moving together anyway, by showing we wanted the same thing and both sides won.
#### The system
We audited every page, consolidated overlapping patterns into single components with variants, and tracked all of it in Notion, every component against every page. We chose Chakra as the base, with Storybook and Figma Code Connect as the versioned source of truth. We took an atomic approach, starting with the token system, primitives and semantic color tokens for color, type, and spacing, before the most fragmented components (the buttons that opened this). Light touches first, to build momentum.
The Notion tracking board for the component library: a table with a row per component and columns for designer, Figma link, whether the audit is done, status, the pages it is used on, version, Storybook link and Jira ticket.
Every component against its page, version, Storybook entry and ticket
One craft call worth naming: with a tiny team and a huge scope, we did not reinvent what open source already did better. We used shadcn as the icon base and designed custom icons only for the concepts that were uniquely ours. Design’s job here was to repurpose great work and fill the gaps that were actually ours to fill.
#### The pivot that changed the trajectory
Halfway through, it stalled. Engagement dropped, feature priorities kept pulling people off, and progress slowed, myself included. My call to get the speed back was to bring LLMs into the work. We had finished the audit and knew every component we wanted and where it lived, so I pointed a smaller, more engaged team plus AI at closing it out.
On design, Claude audited our Figma, cleaned up missing states, and organized components into a consistent format. Once the Figma MCP opened up canvas-to-code and back, it edited our Figma directly with consistent output. On engineering, a single hardened pipeline turned Figma components into Chakra React at speed, one dev instead of many, with humans in the loop to verify. No more two sources of truth: what lived in Figma was what shipped in code.
A component playground: a Toggle rendered live beside a panel of its props, size, state, checked, label and label text; variable modes for tokens and typography; and a Code Connect panel marked Connected, showing the component file and the React snippet that imports it from ui-kit-next. Beside it, a Chromatic and Figma Code Connect lockup over the component’s props table.
Props, token modes, and the component’s real code in one place
The bigger lift came next: pointing the agents at the product itself, ripping out the old UI and dropping in the new components page by page. That collapsed the final stretch, the part that usually drags on for a year while a team hand-updates every screen around their day jobs. A small team plus agents did the mechanical work, and we stayed in the loop to verify.
#### What it became
- **36 → 390** components, 2023 audit to library
- **1,140** variants and states
- **75** product screens rebuilt by 2026
The foundation that finally makes the rebrand possible.
#### What I learned
A year-long effort makes people numb, myself included. What kept it alive was reminding the team what we had already done, and celebrating the wins, the small ones like a beautifully refined icon and the big ones like pages shipped.
And timelines get less accurate the longer the horizon. Champions get pulled to other fires and you find new ones. Resources get borrowed for short-term work. You adapt, you adjust, and you do not lose sight of why you started.
Read it at https://jordanbat.ch/work/mist-component-library
### Changing how design gets made
HPE · 2026
Leading a team through the industry’s shift to AI.
Vercel deployments: prototype deploys with their shareable URLs
Near instant preview builds to share with Vercel
#### The gap
There was a knowledge gap forming on my UX team. Half of us were AI pilled and doing our best at our "second job" of staying up to date on the latest LLM news and abilities. This showed in the speed and quality of work the designers were doing. I saw that soon a gap would form too large between the designers keeping up and those left behind. So I made the call to train up everyone on the team together, along with creating new process and tooling we could use to evolve together.
We are a generalist UX team covering every design specialty with four people. We are already doing too much, and the ask keeps growing. AI is how we could stretch further than we have any right to.
#### Making the case
I started by creating a presentation to leadership on what I wanted to do. I explained what LLMs were capable of, the benefits they would give us, and also showed delivered features we made already using these models. This was at a time where the industry was still in the early minority phase of adopting LLMs into their product building process, and my company’s leadership was not yet convinced AI could ship production code, let alone aid in design.
We initially did not get funding to use the best models, which at the time for designers was a non-negotiable. So I paid out of pocket for the team to have Claude Code. I later was able to evangelize to the senior VP of Engineering why we needed it, and got the budget.
#### The repo
I moved us from Figma-first design to code-first prototypes. We wanted instant shareable URLs to give to engineering, PMs, and design peers, to not just scroll around static Figma screens, but to actually interact with a real demo. I designed this new UX repo to have three different stages of complexity as we grew:
Three stages: 1. Rough HTML and React prototypes using scraped pages from our app. 2. Importing our component library directly as a dependency, for accuracy and speed. 3. A direct branch of production, so the code the designers produce is actually what ships.
The three stages of the repo
#### Getting the team to adopt it
Learning anything new is hard and people are creatures of habit. But the team had already seen what some of their peers were designing for speed, interactivity, and expression of their ideas. They wanted in. I taught the team git and how to work inside an IDE. I spent one-on-one time getting each of them set up for success, but the right attitude was there. I designed the new tooling like I would a feature, with as little friction as possible so the adoption was more likely.
#### The outcome
The team all being brought up to the new wave of the product design process, utilizing LLMs.
- **3 days → same day** design to first draft, at higher fidelity
- **weeks → hours** from "we designed this" to "you can try this"
- **20+ features** shipped through the new prototype process
- **the whole team** levelled up to code-first, together
The UX prototypes index: around twenty named prototypes listed as links, among them Marvis Troubleshoot Partner, Live View, Flow Based Telemetry and Configuration Redesign, with several of the live prototype screens fanned out beside it.
The prototype index, one live URL per feature
Experimentation went up. It was quicker and faster to iterate through ideas in design, which led to better UX.
The prototypes became the shared source of truth. Many features would have 10 to 20 people involved, and often at the end of those meetings I would hear the same thing: please update the UX prototype to reflect our new changes. We still exported to Figma to see all the screens and discuss the work, but people loved being able to click around and go through flows naturally. With a team of generalist UX designers we were aware of the benefits of clickable prototypes, but with such a small team we rarely were able to make them in such an agile environment. Now our design artifacts were the prototypes. It allowed the design team to be so much more expressive and detailed in our communications. And that is one of the superpowers of design: get everyone in a project aligned through visuals. It stops being different pictures in people’s heads, and converges into a shared vision.
#### What I learned
Skills and designing the guardrails for the agents (harness engineering) is the next "design library" that we need to maintain and build. I do not think it is the final form either, so it will be interesting how this evolves. Our role as designers is shifting from creator to definer. More systems building.
The risk: with this new process, yes we are faster and can deliver a higher level of execution with our existing team, but the cost is subtle. Computers are "light brights for bad ideas," and often the best ideas come from just sketching on paper. It is still early for the industry as a whole to adopt LLMs as part of their process, and I am paying sharp attention to the trade-offs of us all coming to a generic middle. A computer should not replace your thinking, just enable and enhance it. Especially for a creative field like design. Yes we are creative scientists, but we must be careful not to automate the creative part of that role.
Read it at https://jordanbat.ch/work/changing-how-design-gets-made
## Writing
To be a good chef you have to eat a lot of food. To be a good designer you have to consume a lot of media. I have been cataloguing other people’s images for decades, and I collect ideas the same way.
Some of these are borrowed, but I’ve adopted them all the same.
### Win, then strike.
In kendo it is katte utsu. You set the position so the point is yours before the sword moves. Striking and hoping to win is the beginner’s mistake.
Product is the same. The win is in the setup: the research, the prototype that ends the discussion, the process the team already believes in. By the time you ship, the outcome is already decided.
### Hire for taste. Process is teachable.
Hire for a visual eye and some product sense. Everything else can be taught. You cannot teach instinct or the eye, and AI did not change that.
It commits you to people who arrive unfinished. The cost is teaching them how to think, and then advocating for them in rooms they are not in.
### You don’t control anything, you only have influence.
Control is like water. You cannot force it to stay in your hand, you can only guide it down the stream.
Even a junior gets told to redo bad work. Even a senior redoes it when the people above don’t like it. Everyone has a boss. The CEO reports to a board.
I assumed founding the design function gave me control over design. It didn’t. What I had was influence and the trust I’d banked.
### Turn the disagreement into a test.
If you are the only no in a room that has already decided, don’t try to win the room. Buy an experiment.
Ask for a week, and staff it with someone from the other side. Scope it so the answer comes back as a fact rather than an opinion. Then the evidence decides, and nobody has to lose an argument.
It only works when the test is cheap and fast. And if the answer comes back the other way, you have spent the capital and lost anyway.
### A product is recognized by what it refuses.
In competitive games you know a character by silhouette alone. A silhouette is nothing but negative space. What makes it recognizable is everything that got cut away.
Product pillars work the same way. A pillar gets its shape from the jobs you take off it, not the ones you pile on.
So every product ends up deliberately worse at something it could plausibly have done.
### Do less, and do it better.
Fewer things, each taken further than anyone asked for.
Work beyond what is reasonable. At a certain point it is no longer for the user or the business, it is work for yourself and pride, and that is ok. You do it because *you* notice the difference.
I would rather live in a world with prideful craft than generic good enough.
### A team is a machine. Build small windows into it.
The output is not the job. The thing that produces the output is the job, and it has to be inspectable while it runs, not reconstructed afterward.
Give it two speeds. Something slow that sets priorities on a cadence, and something fast that lets urgent work reach a person directly without queueing behind process.
The cost is that your hands leave the work. You are measured on a system now, and a system is slower to tell you whether it is any good.
### Prototypes over decks.
A deck describes the thing. A prototype is the thing. One of design’s superpowers is getting people aligned, and nothing aligns a room faster than something they can use.
A prototype is persuasive before it is right. The first working version tends to become the plan, so what you choose to build first matters more than how fast you build it.
### Take choices away from people.
Steve Krug got there first: don’t make me think. It should feel like you predicted what someone needed and handed it over before they asked.
That means deciding things on their behalf that a more permissive product would leave open. Let the system commit to an answer and let the person correct it, rather than making them assemble it from parts.
It is a tough balance and I have not resolved it.
### Over-communicate early. Adjust as you learn each other.
Heavy at the start with someone new, until the task and the alignment are set. Then lighter, as you learn how the other person works.
If I go quiet later, that is the calibration, not neglect.
### Never say AI.
Nobody outside the building cares which technology did the work. Naming it asks someone to hold a fact they have no use for, and in some rooms it is a fact they actively distrust.
Use the words your users already own. Say what the system is looking at, never what the system is.
### The team eats first.
The bigger work goes on the calendar like anything else. When someone on the team needs that hour, they get it.
The cost is real. Hold it strictly and the bigger work starves, and there is no version where both get protected. I have not solved it, and anyone who says they have is either not protecting the time or not answering their team.
### Bias toward action.
Doing produces information that discussing does not. Most decisions are cheaper to make than to keep having.
The exception is anything you cannot take back. Those earn the meeting.
### Do things that don’t scale.
Paul Graham’s line, about startups. In the beginning scale does not matter. Get it working, and if the signal is there, scale it after.
Doing it by hand is also research. You learn what the system actually needs instead of what you imagined it would need.
The cost is that manual work keeps feeling like progress long after it stops being progress.
### Launch, then refine.
Make it real and live quickly, then polish. You can’t boil the ocean.
The first version will not hold the whole vision. Some of it needs things that do not exist yet, some of it just needs time. Plenty of good work lands on the cutting room floor.
### The hard call is deferring something good.
Killing a bad idea is easy. The hard one is when the team is right, the work is good, and you still say not yet.
### Ugly is survivable. Confusing is not.
What cannot be unfinished is the process through a task.
You get one shot at someone trying a product, and if the process feels off they leave and go back to what is familiar.
Still, strive to make it beautiful. Survivable is permission to ship, not a license to settle.
### The default output is everyone’s output.
Give a model no constraints and you get the median of everything it has seen. Competent, generic, and identical to what the next person gets for the same ask. That is what slop is. Not bad work, average work at volume.
So the work moved. It is not better prompting. It is encoding what you actually want, the component library and the rules and the patterns you would have art-directed anyway, so the floor comes up to your standard instead of the industry’s.
I am still building this. Ask me in a year whether it held.
### Alignment is the only part that didn’t get cheaper.
I used to front-load design because design was cheap and code was expensive. Get it right on the canvas, avoid the rework. That trade is mostly gone.
What didn’t move is the cost of five people agreeing. That was never a production cost. It was always a human one.
If anything it got worse. When everyone can generate something plausible, there are more artifacts to align around, not fewer.
### Software has complexity. You either put it on the engineers to build, or on the user.
There is no third place for it to go. Most arguments about scope are really arguments about which of those two is going to carry it, and almost nobody says that out loud.
### Wanting to lead does not suppress the desire to make.
Inside me, there are two wolves. One wants to craft insanely polished, usable experiences. The other wants to nurture designers and build teams to take on monumental challenges. Both are hungry.
Some problems are too large for one person, and those are the ones worth wanting. The pull is being in a room where people push each other into making something none of them would have made alone.
What it costs is the making itself. You trade doing the work for making the work possible.
### Art is subjective. Design is not.
Designers are creative scientists. A design artifact achieves its goal or it does not, and no amount of taste argues with the result.
The trap is counting only what you can measure. Some goals are felt, not counted, and those are the easiest to quietly drop.
### Too rigid and you snap. Too loose and you fold.
An opinion has to carry weight or it is not an opinion. It also has to move when someone shows you something you did not have.
Hold one too hard and you spend your credibility defending a position instead of getting to the answer. Hold it too lightly and nobody can build on what you say, because it might not be there tomorrow.
You are not holding it to win. You are holding it so someone can push against it, and so the two of you end up somewhere neither of you had alone.
### Nothing is ever on course.
Work rarely runs exactly as planned. It drifts constantly, and the job is noticing early and correcting small, instead of noticing late and correcting hard.
A plan is a heading, not a track. Teams that believe they are on course stop checking, and by the time drift is obvious it costs a quarter.
Not every wobble is drift. A team that changes heading every week has no heading at all.
### Lead with empathy.
When someone is not living up to their role, check in on them before you react to the output.
We are all human. Most people want to do good work, so when someone is not, there is usually something under it: an unclear brief, a bad stretch, something outside the job, a role they have outgrown. Being cold about it costs you the chance to hear what it actually is.
Applies the same for a peer in engineering or product as it does a direct report.
### Trust your gut to start. Use data to finish.
The first move does not come from research. It comes from taste and pattern recognition, and waiting for data to tell you where to begin just means beginning later.
A gut call is a hypothesis. Put it in front of people and let the evidence say whether it held. Scientific method, applied to creative minds.
Gut gets you moving. It does not get you finished.
## Contact
- Email: jordanbatch@gmail.com (mailto:jordanbatch@gmail.com)
- LinkedIn: linkedin.com/in/jordanbatch (https://www.linkedin.com/in/jordanbatch/)
- GitHub: github.com/batch (https://github.com/batch)
- Instagram: instagram.com/jordanbatch (https://www.instagram.com/jordanbatch/)
- Résumé: View PDF (/jordan-batch-resume.pdf)
← back to the site