# 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 → Sep 2026
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
#### 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)
#### Battery gauge, exploration in feel
Same needle, four personalities. The Honda is heavy and deliberate, the Nissan slow and worn, the STI eager, and the Mine’s snaps to the reading and lands dead.
[Try it](https://jordanbat.ch/work/gauges)
#### Photo book, exploration in feel
Trying to bring the delight of a real book to a screen. A linen cover, a foil crest, yotsume toji binding, and pages that lift as you reach for them, showing which way they’ll turn. Tuned by hand across 90 controls in 12 groups.
[Open the book](https://jordanbat.ch/work/book)
#### 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. 95 component sets and 295 standalone, 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-used 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)
### 2018
#### Backbone, a component library for a manufacturing ERP
Productivity tool first. Do the job three inputs can do with just one. A custom React library and interface component system, built as the solo designer supporting a team of developers rapidly developing features.
### 2015
#### Grid, an inspiration and culture platform for creatives
Grid is a mixture of products currently being used by creatives combined with many ideals we believe the web has not caught up on. Discover the indescribable. Share what inspires you. A human presence. Personalized recommendation.
[Watch Vimeo.com](https://vimeo.com/126028741)
### 2012
#### Coin’s segmented typeface
Other segmented displays shifted weight and lost their spacing, especially the 1. So Coin’s e-ink display got its own typeface, letters and numbers alike, drawn inside what the board could power.
### ∞
#### 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/)
## Battery gauge, exploration in feel
Exploration · 2026
I was inspired by the gauges in 90s Nissan Skylines. One voltmeter drawn four times. The needle is a mass on a pivot. Move the plate up and down and it swings; move it side to side and it barely does, because only the motion across the arm can turn it.
Each badge has its own spring: stiffness, damping, mass. The Honda is heavy and deliberate and overshoots once. The Nissan is slow and worn, and wobbles around the reading. The STI is eager, quick with a clean overshoot. The Mine’s snaps, nearly critically damped, and lands dead with no ring. Pick the plate up by an edge and it tips toward the side that holds it, the shadow reaches further, and it swings depending how you move it.
The four were tuned by feel in the browser, one number at a time.
## Case studies
### Alterist, a marketplace for trading card art
2025 to now
I wanted to see how far LLM tools could take a solo designer. Far enough to build a two-sided marketplace alone, and run it.
An Alterist piece page: a hand-painted Alibou, Ancient Witness by Miri_Mial held in a hand, listed at $240 with free shipping and a Purchase button, beside it the original card and its style tags.
#### The opportunity
Magic: The Gathering is a collectible card game. Artists paint over the cards, for display or play, and a cheap card can become transformed into a work of art. Altered cards sell for $200 to $2,000 inside a franchise that does over a billion dollars a year, and no purpose-built marketplace exists. Artists sell in the back alleys of the internet, Instagram DMs, Reddit threads, Facebook groups, on PayPal invoices, with their past work buried in feeds.
The goal: a purpose-built home with hosted portfolios, a two-sided marketplace, and visual discovery like Pinterest. Prove AI-augmented discovery as the differentiator, and test what solo AI development ships in velocity.
#### Upload, the first feature
My first philosophy was let artists spend more time painting, less time on data entry. The one clear side to build first was the artists: make them happy, give them reasons to keep coming back, then solve for buyers. Upload is the behavior I needed; it seeds supply, data, and trust. So it had to be almost clickless.
##### Almost clickless
The artist drags images in and gets immediate previews to crop, a skeleton loader for the fields, and a loading message that says what the system is looking at, like a video-game loading screen.
The upload: the fields wait as skeletons while the hints cycle through "Checking the set symbol", "Identifying the edition", "Matching the printing" and "Studying the art style", then the card name, printing and tags fill in.
Hints say what’s being checked while the card is identified.
##### Never say AI
I never mention AI in the interface. My users are artists, sensitive to their work being scraped to train models, and to AI art in general. Technology should be invisible and feel like magic; it does not matter to my audience how something works, it matters how delightful the experience is. So instead of AI, I used the words they already know: "Looking for collector number." "Checking set symbol." Familiar language builds trust with the system.
##### Designed around twelve seconds
Twelve seconds became the magic ceiling to design around. Most cards are identified in about 7 seconds, and 9 in 10 inside 11, so I paced the page UX to take about that long: by the time the artist is done, submit just works. I took inspiration from Instagram’s launch: they’d start uploading your most recent photos before you’d even finished picking or cropping, so it felt magically quick the moment you hit share.
Uploading four alters from a phone: photos go into a tray while the fields fill from skeletons with messages like "Looking up the collector number" and "Reading the artwork", then a review screen confirms each card and printing, and Publish all.
On a phone: keep adding cards while each one is read.
Hard images could run upwards of 30 seconds, and most people would delete the image and upload again. So after 12 seconds a subtle button appears to skip the analysis and enter the card info manually.
Underneath that simplicity, two things start in parallel: the upload to cloud storage, and a call to Gemini, Google’s model, that identifies and tags the card. The moment the model answers, a custom algorithm matches it against every Magic card ever printed. The artist sees none of it. They just see it work.
How one upload works: the artist drags in a photo of a painted Palantír of Orthanc. At the same time the photo is stored and the model reads it; when both are back, the lookup narrows from every card ever printed to the printings of that name, checking number and set first, then set code, set name, and the newest printing, and the match arrives preselected in the printing picker before the artist publishes. Every upload is later graded against what the artist picked.
Diagram showing data flow and upload UX.
##### The problem: artists trusted it too much
The name was always right, the printing often wasn’t, and the printing matters because the page shows the original card so anyone can see how transformative the artist’s work was.
With every feature, even before launching it, I built the analytics and admin tooling to monitor the successes, the failures, and learn: 18 admin dashboards across payments, disputes, uploads, and search. Every upload is audited, with the AI’s reasoning on every row, so I can test models live. In the first test, in January, the model that read printings better lost: it blew the 30-second limit almost three times as often, and past that point artists give up and type it in themselves. I retired it. The person waiting never sees the accuracy.
The upload audit dashboard: every upload logged with its duration, the model’s reasoning, and the corrections the artist made.
Admin page: every upload with its time, the model’s reasoning, and the artist’s fixes.
The audit showed how big the problem was. The dashboard said 13.5% of uploads failed; counting the silent failures, it was 21.4%. And the model called 92% of its reads high confidence while a third of those printings were wrong. A better prompt was not going to fix that.
1. **The decision:** treat the model’s answer as a hint, not an answer. Its guess arrives preselected in a picker, with a visual preview of the exact printing next to the field, so a wrong one is easy to catch and fixing it takes one pick.
2. **The tradeoff:** a newer model read printings better but pushed five times as many uploads past the 30-second limit. So uploads always run a live A/B between models, and speed gets a vote.
3. **The benefit:** the A/B plus the redesign fixed it. Printing accuracy went from 74% to 85.7%.
#### Getting artists paid
Getting artists paid is the part that decides whether they actually stay. I went in with a few assumptions about what artists needed, and the interviews completely changed my direction.
##### 95%, in their own currency
I had designed a clean 90% split to the artist. My first interview killed it: my best artist, in the Netherlands, already keeps 94 to 99% selling direct, and my 90% in USD would have netted them about 87%, because when an international artist sells to a US buyer, currency conversion quietly eats 3 to 4% of what they earn. So I rebuilt the economics: artists keep 95%, guaranteed, in their own currency, and the buyer covers the fee.
How money moves through one sale: the artist lists a painted card in euros, and a buyer abroad sees and pays one price in their own currency. Underneath, the daily exchange rate, a 5% conversion buffer, the 3.5% buyer fee, and PayPal’s fee, checked twice, run in order; PayPal splits the payment in one capture and the artist’s 95% arrives in their own currency.
Diagram showing platform money flow logic.
The learnings from the interviews led to what the core product promises would be:
1. The artist is paid the moment a buyer completes their purchase, not after delivery, not after a holding period.
2. If a dispute is opened, the evidence is submitted automatically, and if a chargeback does succeed, Alterist makes the artist whole.
3. If a package is lost or damaged in transit, the artist keeps the payout, as long as they provided tracking.
4. Artists list and get paid in the currency they choose, while buyers see prices in their own currency, with no impact to the 95%.
Listing a piece for sale: the price entered in euros, the line "You’ll receive 95% after fees. Include shipping in the price.", and the base card’s price history beside it.
Small moments of delight: what you’ll receive updates as you type the price.
##### Connect, not apply
My first build asked artists to verify their identity for a new payments account. I tested onboarding with a few of my close artist users, and the consistent feedback was that the know-your-customer identity steps were just too many. For an artist who only wants to list a card, that friction is fatal. Every artist already uses PayPal and every buyer already has an account, so onboarding became one click to sign in to their existing PayPal, and they could start listing and selling immediately. The artist is the merchant of record on their own PayPal account, and Alterist never holds the money.
##### The price you see is the price you pay
Checkout is the most complex thing that feels simple: one price and one PayPal button. The rule I designed around: the buyer sees the price in their own currency and is charged exactly that, because a price changing between browse and checkout is bad UX. If the piece sells, is delisted, or changes price while the buyer is on the page, checkout tells them before they pay. Buyers check out as guests, and the receipt email invites them to create an account.
##### After the sale
Once they pay, buyers get automated order updates in the app and by email, and they get richer once the artist adds tracking. Pasting a tracking number costs an honest artist ten seconds, and it protects both sides: it triggers the automated dispute evidence, qualifies the artist for the chargeback make-whole and the shipping coverage, and drives the buyer’s delivery confirmation, which stops anxious disputes from ever opening.
Automated updates: in the app and by email, the artist and the buyer are notified at every step, purchased, shipped, then delivered, each with the order number and tracking.
Automated updates for artist and buyer: sold, shipped, delivered.
#### Personalization
The buyer side is discovery: by aesthetic, object, and art quality, not rigid tags. Every piece is encoded once, four open source models in a single GPU pass: one each for style, subject, and art quality, and one that matches plain-English search to images. Those embeddings then do the work across the product in three places.
The search dropdown resolving a partial query into real cards, sets, styles, and artists, each with a thumbnail and a count.
Suggestions fill as you type: concepts, cards, sets, styles, and artists, each with its own visual cue.
##### Search
I modeled the search dropdown on Pinterest. I’m one designer, so if a company that size has spent years iterating an interaction, I should study why it works and take what applies. As you type, the dropdown fills with a mix of free-form concepts, card names, sets, artistic styles, and artist names, each with its own visual cue. The suggested text is bolded except for what you’ve already typed, so your eye lands on the suggestion, not your own input.
The risk was scope: a new user doesn’t know one box can search by style, card, set, or artist. So I did two things:
1. Clicking into the box greets you with one suggestion per result type, which teaches how much the search can do.
2. Your own search history shows in the same style, which smooths every return visit and reminds you what you’ve already done successfully.
On a phone: the menu opens over the page, then search expands across the top and fills with suggestions as you type.
On a phone: the full menu, then search across the top, with the same suggestions as you type.
Under the polish, search runs two tiers behind one input: exact matches land instantly, then the ML results stream in behind them into the same grid, so the GPU wait is invisible. I treat latency as a design material.
##### Related art
Every piece page shows related art, matched by the image itself, not its tags. The first version weighed style and subject equally, and my own testing showed subject taking over: two Van Gogh-style alters of different subjects would not surface for each other. So I let style lead and subject break ties, and added a third model that knows art-history styles. Each of those is one number, so tuning is a quick adjustment, not retraining a model. Now pieces that share a look find each other even when they paint different things. Van Gogh alters still only partly find each other, so that case stays open.
##### The Curated homepage
No one can hand-curate a homepage every day. ArtStation, the artist portfolio site, had a similar problem: junior artists upload their work too, and if the home page were left to just "most recent," the quality bar would be so poor the pros would not want to join. By showing the best, the pros feel this is a place for them, which lifts the brand and inspires the junior artists to be part of such a quality community.
So the software curates it, for each user. It learns your taste from what you favorite, follow, and dwell on, and clusters it into a few centers instead of one blurry average, so comic outlines and painted landscapes both come through. The tab is called Curated, never Featured. Featured doesn’t imply it’s specifically tailored for them; it’s more generic, less personal.
#### The outcome
When I launched publicly by posting to the groups and forums, the catalogue went from 70 pieces to 706 in 30 days. 97 artists signed up before payments went live.
- **9 days** from the first commit to the first alter uploaded by an artist
- **93 days** from the first commit to the public launch on alterist.co
- **4 days** from payments going live to the first real sale
- **1.8:1 → 1:2.7** signup mix, artists to collectors, at launch and over the last eight weeks, with zero ad spend
- **9x** signup rate at public launch, about 10 to 88 a month
- **2,335 pieces** catalogued by 160 artists, September 2026
*Built with React, Claude Code (Anthropic’s coding agent) as my primary dev partner, Gemini for upload understanding, and ML embeddings for search, related art, and the personalized feed, on Supabase (the database), Cloudinary (image hosting), and Vercel (hosting).*
#### What I learned
Done beats perfect, visually. But the experience, has to be immaculate. I get one chance for an artist to try uploading their work. If something is too rough, or an uncaught edge case happens, they drop off and never try me again. That is what I optimized for. The UX thinking and the user’s experience had to be polished; the code and pixels didn’t.
Read it at https://jordanbat.ch/work/alterist
### 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: 95 component sets and 295 standalone, 1,140 variants, 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
- **1,140** variants, 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: 1,140 variants, 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 Lucide 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
- **95 + 295** component sets, and standalone components
- **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
### Coin’s segmented typeface
Coin · 2012 to 2013 · Founding Product Designer
Over a year of work at Coin, and this is one small detail of it. The e-ink display, and the custom segmented typeface drawn for it.
The numerals 0 to 9 in Coin’s segmented typeface, large in two rows of five, lit periwinkle on black, and again below at the size they showed on the card. The 1 sits centered in its cell like every other digit.
The alphabet A to Z in the segmented typeface, six to a row on black, beside one letter, A, drawn very large so its segments read: the lit ones periwinkle, the unlit ones dark grey.
The typeface up close: two lit glyphs and the edge of a third in a dark display slot, each cell built from angled segments, the lit ones periwinkle and the unlit ones still faintly visible in dark grey.
#### A clock we knew we had
Coin was a connected card: one card, with a button and a small display, that could stand in for the cards you carried. I was its founding product designer, and the name on all of it was mine: I named the company Coin.
The word COIN in the segmented typeface, four glyphs lit periwinkle on black.
Coin was an early mover in the payments space in the USA, but international tap to pay was already out and gaining popularity and vendor support. This was at a time before every phone was just assumed to have tap to pay. People carried around five or more cards with them often. We had a clock and we knew it. The crowdfunding campaign drew millions of dollars in preorders, and Coin was later acquired by Fitbit.
#### Always on
E-ink was chosen for its low power and its ability to stay always on, displaying the active card selected. No lag or wake up time. Just pull your Coin card out and pay.
Segmented rather than a full screen of pixels, for low battery consumption.
#### The limits of the board
Working with our mechanical engineer, we had hard limitations: the number of segments the board could power, and the minimum width for the shapes, set by the minimum pad size for a connection to be possible to each segment.
One glyph enlarged to show its anatomy: the segments that make up every character, corner bars, top and bottom bars, two middle bars, the center halves and four diagonals, lit ones in periwinkle and unlit ones in dark grey. Beside it the numerals 0 to 9 at actual size.
One glyph very large on a periwinkle field, its lit segments black and its unlit ones a faint tint, with the word VOLT set small beside it.
#### A typeface, not a part
We decided to make the custom font so that our product and brand were recognizable, and not seen as generic pieces just assembled together. I believe in a general product gestalt, where every surface the user touches, from the iPhone app to the physical card, is unified and cohesive.
To bring more function into the display, I designed the typeface to display both alpha and numeric characters. Other segmented displays that were out lacked consistency in readability between characters. Weights of characters shifted, the spacing of characters got out of whack, especially with the number 1, and generally they were hard to read and lacked personality.
#### Personalized
Users could personalize and pick what to display in the slots: the first or last four of the card with the CVV in the bottom left, or a four-letter word with the card numbers in the bottom corner. As much flexibility as we could allow.
Twelve four-letter words in the segmented typeface, each in its own dark display slot: BANK, DEBT, EURO, GIFT, HYPE, JOLT, KEYS, MINT, OPEN, TAPS, VOLT, ZERO.
Two eight-letter words, SYNCLINK and NODEFLUX, in the segmented typeface on black, beside a single glyph showing only its four diagonals lit.
#### What I learned
Embrace limitations. With so many directions you could go, often it’s looking at where you can’t that guides you to a better outcome, quicker. With the screen, I quickly realized the total segment count was the core constraint to design around. The number of characters we wanted on screen guided how complete our segmented base character could be. We gave up letting some of the smaller digits on the screen show letters, just so we could squeeze more complexity into our main base character. This allowed our diagonals to be more readable, in letters such as N, Y, K, and Q.
Read it at https://jordanbat.ch/work/coin
### Live View, Mist’s real-time building analytics
Mist
Your building, live. Live View was one of Mist’s most-used features, and it was losing ground.
Live View, the redesigned floor map: a building’s floors stacked so a device can be followed from one floor to the next, with the live network shown on each floor plan.
One floor in Live View, tilted in isometric: the floor plan under an RF signal heatmap, strong green around each access point fading to amber at the edges, with the campus, wing and floor picker above.
Live View’s controls: a time range menu (Live, last 24 hours, 7 days, 30 days, custom), an overlay switcher (SLE, RRM, RF, none), a campus, wing and floor picker, the map tools, and a replay timeline of the last day marking Marvis actions and topology changes.
#### Opportunity
Live View is a live map of your building. Every access point and device, moving on the floorplan in real time, so admins can troubleshoot when something breaks, warehouses can track robots, and stores can see where customers go. It was quietly one of the most-used features in the whole product.
- **40%** of customers use Live View
- **8%** of all dashboard activity runs through it
- **5.6** interactions per visit
We put it on the business case as retention: we didn’t want to lose customers to competitors. Competitors were starting to ship better versions of theirs and we were falling behind. Our goal: consolidate the scattered tools for Live View into one place, add the features it was missing, and reach the future by redesigning the whole experience.
Live View before the redesign: a flat floor plan with client icons scattered over it, and a separate side panel of tabs (Clients, Assets, Devices, Beacons, Zones) listing devices by name and MAC address, with the selected client’s details below.
Live View before the redesign
#### The team
Justin, the main designer; Chris and Calvin, contributing designers; Anilash, our PM; Huan and Tara, our UI engineers; and myself as the UX lead.
There was no product requirement doc. We were just given an area of the product to improve, and a loose goal. I turned it into a phased rollout through a structured, repeatable process we lovingly called Workshop. It was inspired by past teams and enjoyable processes I had been a part of, and I brought this workshops model to the team. I defined the product requirements. I directed the visual and interaction direction.
#### The process
The Workshop is a framework I built and taught to each designer as they took the lead. I ran the first one myself to teach it, and now designers rotate as lead on my framework while I coach and set direction. It sharpens the work as a team and levels the designer up at the same time. Once a quarter the whole team goes deep on one problem for a month. It runs multi-day, music on, low pressure. It breaks the team out of the daily feature grind and levels them up while producing sharper work.
For each project I picked a designer on the team to be the lead and follow my framework. That way they would have a portfolio piece to show that they were a lead and were able to make solid senior decisions. I was setting my team up to succeed in both promotions and portfolio while helping out on direction.
Go wide, then narrow. First we open the problem all the way up. Creative thinking exercises like Teardowns, Crazy Eights, Lotus Blossoms, no idea too dumb. Then we cut ruthlessly, against real customers, down to one scoped list. Every step changed the design. None of it was process for its own sake.
- **8** workshops
- **5** user interviews
- **1** final direction
The process as a funnel that widens, then narrows: 01 Competitive analysis, the field, and game maps; 02 User interviews, sorting + synthesis; 03 Design studio, sketching, go wide, at its widest; 04 Lo-fi to hi-fi, refine the few; 05 Feature priority, converge to scope, ending at the scope.
The Workshop, five steps from wide open to one scoped list
##### Competitive analysis
We studied every competitor in the space, then went wider, pulling navigation and interaction patterns from video game maps. And the same broken pattern showed up everywhere: the map and the floorplans were separate screens you tabbed between, and half the time you couldn’t find your way back. That gap was our opening. This is also where 3D first showed up, as one rival’s idea we almost dismissed.
##### User interviews
Before we assumed anything, we watched. FullStory replays showed what users actually did and where they got stuck. Then we interviewed across customer sizes and roles, from installers mounting access points to admins troubleshooting the network. Two customers, unprompted, described the exact same workaround: two browser tabs open just to follow a device between floors. That became V1’s number one feature. One customer had it worse, flattening their two-story buildings onto one floor by hand just to cope.
Interview notes as sticky notes, one color per designer. Among them: customers switch back and forth between two floors to see how clients connect to access points on different floors; wants to scroll between floors without jumping in and out; would like to see more than one floor plan at a time to find coverage holes; wishes there were more entry points into Live View.
Organizing post-its and voting with stickers after each interview
##### Design studio
Around the middle of the workshop we start sketching concepts, iterating, and then narrowing down to one direction. It’s a constant of chiseling away and refining until we uncover a gem to attach to, like the two tabs problem. I set the vision: in competitive games, you know a character by silhouette alone, and Live View deserved its own identity, not just another screen in the dashboard. I drew a bullseye on where to consolidate and left the how to the designer. Set the target, let them find the path.
##### Iterate together
When the team would get stuck, we’d jam, doing critiques and solving problems together. Toward the end I worked with Huan and Tara, our UI engineers, directly, going back and forth on polish, finding rough spots together and coming up with solutions fluidly while bringing delight to the experience.
The finished details, playing: hovering a floor’s service level coverage, the SLE overlay settling onto the floor plan, and the replay timeline scrubbing through a day of Marvis actions and topology changes.
Various micro-interactions and animations
##### The list
I condensed every learning into one triaged list, the PRD I made to tell the team what we needed to build and in what order. It had three columns: what ships in V1, what comes right after, and one labeled not to consider. That last column is where the discipline lives.
The list, in three columns. V1 focus: ability to move between floors; creation of ‘floor’ concept; where does ‘live view’ live as a page in NAV; side info bar redesign; redesign the architecture of the live view page; redesign the utility tools; redesign search/filtering; floor plan zero state; setup/edit floor plan (including toolbar updating); AP drag/selection (during floor plan setup) redesign; redesign focus/selection state; map icon redesign / custom icons. Do right after: Location Diagnostics design into page; RF Environment design into page (including what data/use cases); RF Environment Replay design; validate/redesign beacon/zone creation; validate/redesign path creation; creation of ‘building’ concept; ability to move between buildings. Not to consider: future client play video experience (FullStory style); future 3D floor plan; future extruded walls floor plan (use RF data to create walls?); 2.5D floor list view visualization.
The hard part was cutting the team’s good ideas, like the true 3D building. It wasn’t just about dev timeline and the tech not being ready. We hadn’t proved out that our building stack concept was correct and liked by the larger user base. It’s easy to get distracted and pile on cool ideas, especially when you have a killer creative team. But you need to stay measured and make sure the core is correct before over building. It’s tough because your team is right, but you have to tell them: not yet.
#### Leadership pushback
That v1 was not liked by the head of product and we were told it was “missing the wow effect.” The PM we were partnered with took the brunt of it. My designers and PM were affected hearing such negative feedback, and it could have been avoided. That one was on me.
So I took it to the head of product directly. I explained how we wanted to deliver immediate value to the users and get early feedback while the devs took longer on the true 3D. Once we talked it through, it was clear we were on the same page: they wanted the wow, and the wow was already planned. It was Phase 2, and v1 was the stepping stone to it. Justin came back with a redesign shortly after, I pushed it up to leadership, and it was green-lit. Phase 2 became our updated 3D concept, one we could do without fully auto-generated walls.
> Live View initially received a ton of pushback from the head of product, and you supported me when I came back with a redesign shortly after by pushing the design to higher-ups, which was then green-lit, and eventually I evolved it to what we have today.
> — Justin, the designer who led Live View
#### Deadline problem
Mobility Field Day is Juniper’s showcase to a delegation of independent wireless experts, livestreamed and written up across the networking community. Phase 2 was what we planned to put in front of them, and now it had a hard, public date.
I realized early the devs wouldn’t have the new design built in time. So I convened a meeting with my director-level peers across QA, development and product, and offered a plan: demo Justin’s live coded prototype instead, so my dev peers weren’t crunched and customers would see the best version of the design. They agreed.
#### What shipped
Remember the two tabs? This is the fix. A floor stack shows a building as a stack of floors you move through in one motion, so you follow a device between floors without ever opening a second tab. It solved the number one pain head-on. And we named it deliberately: it wasn’t a true 3D building, no real walls or placement, so floor stack told the truth about what it was, and left building for when we earned it.
Two Live View analytics overlays on isometric floor plans. Left, SLE (service level expectations): a floor’s coverage at 100%, charted across the day, with access points listed by signal. Right, RF: a radio signal heatmap across the floor, with an access point’s details (MAC, status, channel, band, transmit power) and its nearest neighbor access points.
#### Results
- **11 → 1** clicks across 3 features to trace a device’s performance, now one view
- **50%+** of active sites have built a floor stack
Three wins:
1. We solved the pain the users defined.
2. We turned a scattered product into a core product pillar.
3. We kept the customers we were at risk of losing, with some wow.
> I used to keep two tabs open just to follow one device between floors.
> — A network admin
#### What I learned
> There’s a balance between letting your team fail and learn on their own, and knowing when to step in and guide. Same with a vision: tight enough for everyone to be confident in the direction and their role, but loose enough there is room for their own creativity to shine.
I now step back to consider who has eyes on a feature and why. Everyone calls it stakeholder alignment, but I think the lesson here is that even if it isn’t my stakeholder to align, I should still have them on my radar, to protect my team, ensure we are building the right thing, and set the right expectation.
The maximum version and the safe version are both easier calls. The earned middle is the hard call.
Read it at https://jordanbat.ch/work/live-view
## 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