SLATE • CHAPTER 2
Building the Foundation
After the redesign unlocked a product direction, the work shifted to building the system, the practice, and the culture that would let Slate scale.
⎯ MY ROLE
Design decision lead on a growing product
When Slate moved to SaaS, my role expanded. I was the design decision lead — responsible for flows, the design language, UI components, visual direction, user research, and full-stack implementation.
⎯ DESIGN SYSTEM
A system built in the margins
I wanted to build a proper design system. The workload didn't allow for it. What I built instead was something more incremental — a set of principles and technical decisions that held the product together as it grew.
ARCHITECTURE
Design language changes propagate without touching every component individually.
SASS Variables
HAND OFF
A living component reference. Developers preview components before they build.
Codepen Showcase
STRUCTURE
Applied to every new component — atoms building into molecules building into larger patterns.
Atomic Design
PRINCIPLE
Every new request evaluated for future scale — not just "does this work?" but "does this still work at 4x?"
Replicability first
Codepen library preview
The visual language was minimal — one accent color, teal, carried from GreyB's brand. A dense analytical tool doesn't need competing visual elements.
When new products came after Slate, other developers picked up the model with minimal guidance and extended it across five more products.
⎯ HOW I WORKED
Research, advocacy, and the parts nobody asked for
Alongside design direction and full-stack development, I was doing work that didn't have a formal name in the org — research, design governance, and education.
⎯ OBSERVATIONAL RESEARCH
Watching people use the product
I shadowed analysts during live sessions. That's how I caught Supreet switching between mouse and keyboard every few seconds — not by preference, but because the navigation had scrolled out of her visible range. We added a fixed header. The problem went away.
The things users never complain about — but silently work around — are the ones that quietly damage a product. You find them by watching, not by asking.
⎯ DESIGN ADVOCACY
Holding the line on scalability
When a feature from an external API was approved and implemented without my design review, I pushed back. The feature itself was fine — the UI pattern it introduced wasn't. If four more insights followed, we'd be adding a new element each time with no coherent system.
I escalated. Leadership listened. The decision went back to the board and came back with a more considered approach.
⎯ DESIGNING THE FULL EXPERIENCE
The parts people weren't supposed to see
The 404 error page showed a real strange patent pulled randomly from history — with a function I built to serve a different one each time. The Tomograph empty state used an illustrated character to explain a complex concept. Neither was requested. Analysts doing repetitive, domain-heavy work deserve a product that occasionally surprises them.
⎯ DESIGN EDUCATION
Building design thinking into the team
I ran internal workshops and wrote weekly design letters to the team — teaching developers to observe interfaces, question decisions, and reason about UI choices rather than voting on them. By the time I left, design decisions on the team were backed by reasoning, not preference.
I hired one designer before leaving. More practically, I built design capability into a team of developers who didn't have it before. The 15+ people who went through those workshops made better product decisions as a result.
⎯ ADOPTION
Getting analysts to switch
The analysts we were designing for had existing workflows — makeshift tools they knew and trusted. Slate was new, still being built, and had bugs. Asking them to switch meant asking them to absorb friction they hadn't signed up for.
I set up Drift as a direct support channel and handled it myself — answering questions, logging requests, troubleshooting in real time. It kept me close to users during the most uncertain phase of the product's life.
I supplemented this with focus groups and surveys. The Drift conversations were more useful — immediate, unfiltered, and honest in a way that scheduled sessions rarely are.
I brought that signal back to the team — synthesizing issues into cases for developers and PMs, and making the argument for why certain friction points should take priority over planned features. The team started making prioritization decisions with user behavior as an input.
⎯ OUTCOME
The product grew steadily
Slate shipped continuously across three years. What started as a patent reading and annotation tool expanded into a full research platform — taxonomy classification, collaborative commenting, a Knowledge Base, a Minimap for document navigation, Business Opportunity detection, Prosecution Health status, analytics dashboards, a data revision bot, milestone-based user emails, and a public workspace directory covering domains from 5G to CRISPR to autonomous vehicles.
The anniversary email to one user captured what the platform had become in practice: 6 workspaces, 57 patents, 496 annotations from a single analyst. Multiply that across a growing user base and the scale of what was being managed becomes clear.
UX moved to the beginning of the process
When I joined, design was reviewed at the end — after decisions had already been made and code had already been written. By the time I left, I was in early product discussions. Features were sketched and prototyped before they touched the codebase.
That shift happened because the team saw, repeatedly, that catching problems at the sketch stage was cheaper than catching them in production. The FIT API incident — where a shipped feature had to go back to the board because the UI pattern wouldn't scale — made that concrete. After that, design review became a step in the process, not a final check.
The workshops and weekly design letters reinforced it. Developers started asking design questions earlier — about hierarchy, about replicability, about what happens when a pattern has to scale. The vocabulary changed. The timing changed.
The numbers in context
40%
Increase in customer engagement
Driven by the combination of product update emails, data triggers, onboarding sequences, and milestone touchpoints — a sustained engagement system built alongside the product.
5+
Products built on the same design foundation
Other developers picked up the SASS variables, the component patterns, and the design language with minimal guidance. The system worked because it was designed to be extended, not explained.
15+
Developers who went through design workshops
Not to make them designers — to make them better at asking design questions before writing code. By the end, that was visible in how the team discussed features.
100%
Of GreyB's research projects delivered through Slate
The tool that had been holding a client relationship back became the infrastructure the entire business ran on.