Work
I work at the edge of design, learning, and systems thinking.
Teams that grew, programs that scaled, systems that held — each case shows what it looks like when design moves all the way through, from diagnosis to decision to durable outcome.
LMS Design System
myGA Design System
Building the Learning OS: One Token System, Multi-Course Tracks
How a token-based design system unified UX, Data, and Web Development learning on General Assembly's myGA platform, so a learner moving between tracks never felt like they'd changed products.
0 → 1
0 → 1
Course tracks (UX, Data, Web Dev) on one token system
0
0
Tokens behind every color, space, type and motion value
0
0
Color pairings possible from just 47 core ramp steps
CONTEXT
Two learners, two different products.
A learner taking the UX course and a learner taking the Data course weren't using two curricula. They were using two products. Navigation felt different. Feedback states felt different. Progress was communicated differently.
Every course team had made reasonable decisions in isolation, and none of them added up to a coherent experience. That was the real problem: not inconsistency, fragmentation.
LEARNING PRINCIPLES
A learning platform has one job: protect the learner's attention.
Every interface decision either spends attention or protects it. Before any component existed, we set five principles for what the platform owes a learner. Each one became something the system enforces, not something a team has to remember.
Know where you are
One hierarchy, one navigation model, and one progress language on every track.
Never relearn the interface
Four hues with one meaning each and two typefaces with fixed roles, so effort goes to the content.
Feel every action immediately
State changes register at 100ms and transitions follow at 200 to 400ms, so no one wonders whether something happened.
Know what's next
Resume, Continue, and Next appear wherever progress does, so momentum never depends on memory.
Include every learner
Contrast minimums, real buttons, and reduced-motion support, with static states as the fallback.
Make every state unmistakable
Complete, incorrect, due, and tip look and read the same everywhere, so no one guesses whether work was saved.
PLATFORM ARCHITECTURE
The curriculum is the spine. Everything else hangs from it.
Instructors already think in four levels. The system mirrors them, maps each level to a family of components, and draws every component from one token set. Adding a course adds content, not structure.
APPROACH
UX critiques, data labs, code reviews
We sat in the back of all three to observe the actual learned behavior of our leaners.
We watched when learners went quiet, and what was on the screen when they did.
We timed how long it took someone to find their next assignment after finishing the last one.
We saw a fast learner close their laptop to help the person beside them, and whether the interface supported that or interrupted it.
One screen, shaped around each learner
Select a learner to see the same screen answer them differently. A system built for only one of them would fail the other, so everything below was tested against both.
From classroom friction to shared tokens
DESIGN SYSTEM
If it isn't a token, it isn't a decision. It's an accident. Every value starts as a named primitive, gets meaning from a semantic layer, and only then reaches a component. Nothing is hardcoded. Change a token, change everything.
FOUNDATIONS
Four foundations, each with a reason
Color, type, motion, and space are the four decisions every component inherits. Each one is a small set of named values, not a menu of options, so every screen a learner sees feels like one product.
Four hues, one job each
Red carries the brand and the primary action, teal drives navigation and secondary actions, green marks success and the data track, yellow highlights and labels, and neutrals carry text.
Two typefaces, clear roles
Circular for display and titles, Nunito for body and UI. No mixing within a hierarchy level.
Specimens are scaled to fit the card. Circular is licensed, so display lines here use a stand-in.
Three durations, three curves
Only transform and opacity animate. Hover or focus each bar to feel the timing. Reduced motion turns it off.
A 4px base, seven steps
Radius stays restrained, from 2px badges to 8px containers. The system reads editorial, not rounded.
COMPONENTS
Consistency enforced is fragile. Consistency composed is resilient. A lesson card is a progress bar, a badge, and a button, and those pieces are made of tokens. Incorrect assembly is structurally harder than correct assembly, so the system doesn't need to police correctness. Every new screen starts from a consistent baseline instead of a blank canvas.
FRICTION MOMENT
The system only worked once teams let go.
Every course team had good reasons for its own navigation, feedback states, and progress patterns. Giving those up felt like losing ground. Adoption only took hold once the shared version was easier to use than the local one, and that shift mattered more than any component I built.
A well-documented system would be adopted on its merits, because the benefits were obvious to everyone.
Teams kept their own patterns. Each decision was reasonable, and each felt like it belonged to the team.
A system is adopted when it's the easier path, not the right one, so the ease has to be designed in.
DESIGN DECISIONS
Five decisions that shaped the most, and the reason behind each.
A small palette where each hue means one thing
Four hues, each a 9-stop ramp. Red marks the brand and the one primary action in a view, teal drives navigation, selection, and secondary actions, and green marks success and the data track. A learner always knows what matters most.
Feedback before transition
State changes register at 100ms and full transitions follow at 200 to 400ms. The learner never waits to know something happened.
Only transform and opacity animate
Width, height, and margin changes cause layout reflow, so motion uses clip-path or scale instead. Everything sits behind prefers-reduced-motion, and static states are always the fallback.
The component hierarchy mirrors the curriculum
Unit, Lesson, Module, Element came from how instructors think about content. The system matched that mental model exactly.
Restrained radius, editorial feel
Radius tokens run from 2px badges to 8px containers, with 999px reserved for pills and toggles. The system reads editorial, not rounded.
OUTCOMES
What the system made possible
It held three tracks together without making them identical.
One product across three tracks.
Whether a learner was in UX, Data, or Web Dev, the product felt like the same place. Navigation, feedback, and progress read the same on every track, so effort went to the content, not the interface.
Adding a course added content, not structure
The hierarchy matched how they already plan a course, so the platform followed their thinking.
New modalities, no new design
When a new type of learning arrived, the components were already there. The system absorbed it without accumulating design debt.
It survived team changes
New team members couldn't make accidental decisions. The system was opinionated enough to protect the experience without being rigid enough to break it.
One shared vocabulary
When a designer said teal.600 and an engineer built teal.600, there was no translation layer and no drift.
The learner shouldn't notice when they move from a UX lesson to a Data assessment. It should feel like reading a book, not switching applications.
The guiding principle for myGA
THE REFRESH
If I were readying this today:
making the system legible to an AI agent
The system was built so a designer and an engineer could say teal.600 and mean the same thing. An agent needs the same thing, with fewer assumptions. The goal of a refresh: an agent building a new learner screen reaches for the right token, component, and pattern without anyone explaining the rules to it.
The reference site is live. The machine-readable layer below is the next build, and nothing in it is claimed as shipped until it exists there.
What shippedNew
Principle
Every rule an agent needs should be a file it can read, not something a person has to remember.
REFRESH DECISIONS
01
Tokens as data, not just CSS
Publishes the three tiers as JSON in the design tokens format ($value, $type), so an agent reads color.ui and finds teal.600 instead of parsing a stylesheet. One source, many outputs: tokens.json and tokens.css.
02
Rules written as checkable statements
"Red is for the brand" needs its exceptions written down, such as the primary action and error states that also use red.600. The rules are now a list of 13 in AGENTS.md that a linter applies, so an agent can check instead of guess.
03
Components that say when not to use them
Each contract lists its variants and states, and also the uses it forbids. A primary action belongs on an assessment, not on every card in a dashboard.
04
Patterns as recipes, not screenshots
The lesson view, learning path overview, and dashboard each become an ordered assembly: which components, in what Unit, Lesson, Module, Element hierarchy. A screenshot shows the result. A recipe shows how to reach it.
05
One front door
A plain-text llms.txt at the root points to the tokens, components, patterns, and rules in the order an agent should read them. The same files feed the workflow below, where tools reach the system through MCP.
06
Code first, then the canvasNew
Build the real screen in Claude Code, import it into Figma as a code layer through MCP, and let designers review it running. Figma Console MCP checks token drift, and changes return as a pull request. Code layers are in beta, so treat it as a prototype path.
THE TEST
Proof beats a promise
Give an agent only the structure above and ask it to build a screen the system doesn't have yet, like a mentor-booking confirmation. Then compare what it built against what the system intended.
REFLECTION
That's the test I hold this work to, and it's why I rebuilt it as a live reference instead of a retrospective deck.
Program Development
Mentorship
DRI Model
Design Leadership
Mentoring the next generation of designers to lead through craft
How I scaled an experiment-driven model for product design education, putting instructors in the driver's seat of continuous curriculum improvement.
0+
0+
Instructors trained and onboarded to the DRI-driven curriculum model
0yrs
0yrs
Leading a distributed faculty team, each instructor owning program outcomes
0+
0+
Practice leads driving continuous curriculum updates across the design program
CONTEXT
Education moves slow. Industry keeps moving anyway.
The thing that keeps me up at night isn't whether the design is good. It's whether the people teaching it are still growing. That question is what this work is really about.
Design education has a fundamental velocity problem. Traditional curriculum governance, committees, approval cycles, annual reviews, operates on an academic timeline that industry stopped respecting years ago. By the time a program update ships, the skills students needed have already shifted.
GA's model gave us an advantage: a practitioner-led faculty and short cohort cycles. The question was whether we could build on that foundation to create something genuinely different, a program that learns in near real-time, not in retrospect.
Practice
Hands-on
FRICTION MOMENT
The model came together. The people took longer.
The hardest part wasn't building the model. It was convincing a team of experienced practitioners that the way they'd always done it wasn't the ceiling. Some instructors pushed back hard. A few never fully bought in. That resistance taught me more about change management than any framework I've read. What it produced was a team that owned the work in a way they never had before.
WHAT WE BUILT
A three-level product: program, practice, and curriculum
The work operates at three distinct levels, each one a layer of the product. Together they form a living system that evolves with the industry rather than chasing it. Each level informs the next, and no single layer works without the others holding it up.
Real-world
Transfer
WHAT WE DESIGNED
A single system with three layers of leverage
Design at General Assembly doesn't live in one place. It runs through program architecture, practice operations, and the curriculum itself — each layer shaping the one inside it, each one dependent on the others to hold.
OPERATING MODEL
A product delivery loop for learning experience design
Every curriculum change runs through the same product-style loop, keeping improvements small, visible, and evidence-backed. The model scales from micro-fixes to macro program overhauls. Nothing ships without signal behind it.
Live Experiments
OUTCOMES
What this model made possible
Every curriculum change runs through the same product-style loop — keeping improvements small, visible, and evidence-backed. The model scales from micro-fixes to macro program overhauls.
What I'm proudest of here isn't the 91%. It's that we built a team that now questions the curriculum before I have to ask them to.
The program that ships the most relevant skills earns its place. We built the operating model to stay ahead of that bar.
— Tyler Hartrich, Design Practice Lead
AI Curriculum
Learning Experience
Infusing AI-fluency into the DNA of emerging product designers
How I redesigned GA's product design curriculum from the ground up — moving AI from a topic students encounter to a native capability they graduate with.
0%
0%
Graduate employment within 180 days — sustained across cohorts
0yrs
0yrs
Running a continuous, product-style delivery model for curriculum
0k
0k
Curriculum improvements shipped and validated through the model
CONTEXT
AI is not a feature of design education. It's the new foundation.
I've watched a lot of design programs respond to AI by adding a module and calling it progress. I couldn't live with that answer.
For years, GA's product design program succeeded by doing one thing well: preparing career changers for the industry through applied, experiential learning. The hypothesis was simple, treat the student as the user, build the curriculum like a product, and iterate relentlessly. That model delivered a 91% outcomes rate and produced designers who could walk into industry-ready roles.
Then the ground shifted. AI moved from a tool designers might occasionally use to a capability the best ones think with natively. The curriculum had a choice: treat AI as a topic to introduce, or rebuild around it as a foundational lens. We chose the latter.
Immersion
Activation
ARCHITECTURE
AI isn't a module. It's the method.
Every unit in the redesigned curriculum has an AI-native counterpart — not as an optional add-on, but as the expected way of working. Research synthesis runs through AI-assisted pattern finding. Problem framing gets stress-tested with AI reframing.
Ideation uses AI as a thinking partner, not a shortcut. And delivery includes AI-native spec generation as a standard output. The result is a graduate who has practiced with AI across the full design arc, not just encountered it once.
STRATEGIC FRAMING
From AI-aware to AI-fluent: a different design identity
Most programs respond to AI by adding a module. We asked a harder question: what does it mean to graduate a designer who has AI-fluency in their DNA, not as a skill they learned, but as a way they think?
That reframe changed how we approached every unit, project brief, feedback method, and assessment. We weren't patching a curriculum. We were rebuilding the identity of what a GA graduate is.
Native Practice
Confidence
AI-fluency isn't a module. It's the mindset we build the entire program around.
— Tyler Hartrich, Design Practice Lead
Collaboration
Delivery
FRICTION MOMENT
Development goes both ways.
The faculty development piece was harder than the curriculum redesign. Asking experienced instructors to publicly practice something they hadn't mastered yet required a level of psychological safety we had to build before we could ask for it. Some weeks the energy in the room felt more like resistance than readiness. We kept going anyway.
DESIGN APPROACH
Six tenets of an AI-native learning experience
The redesign was grounded in the same operating principle we'd used for years — treat the student as the user, the curriculum as the product. These six tenets defined what an AI-native learning experience actually looks like in practice.
FRICTION MOMENT
Development goes both ways.
The faculty development piece was harder than the curriculum redesign. Asking experienced instructors to publicly practice something they hadn't mastered yet required a level of psychological safety we had to build before we could ask for it. Some weeks the energy in the room felt more like resistance than readiness. We kept going anyway.
01
Fluency over familiarity
Students learn to think with AI, not just use it, building judgment, not just technique.
02
The classroom as a laboratory
Every cohort is a live experiment. Instructors test new AI-integrated methods and report back.
OUTCOMES
What the redesign produced
The redesign will need to happen again in two years. That's not a failure — it's proof the model is working.
Foundation
Fluency
The designers who will lead the next decade are the ones who learned to think with AI from day one, not study it from a distance.
— Tyler Hartrich, Design Practice Lead
Living Systems
Ecological Teaming
Building ecologically inspired product design teams of the future
How I developed a framework and program for designing product teams that operate less like org charts and more like living systems, with distributed ownership, clear accountability, and the adaptive capacity to evolve.
0+
0+
Designers developed through Forthward cohort sessions across both career stages
0yrs
0yrs
Forthward running as an independent laboratory for ecological teaming practice
0
0
Distinct program tracks built and validated across cohort formats and archetypes
CONTEXT
The hierarchy has limits. The org chart was never designed for how the best teams actually function.
I've never been comfortable with the way most design teams are structured. Too hierarchical to move fast, too siloed to build trust, too focused on reporting lines to develop real ownership. I started building an alternative.
The dominant model for product design teams, hierarchical, role-siloed, top-down, was designed for a different era. It assumes predictability, clear chain of command, and work that flows in one direction. None of those assumptions hold in a fast-moving product environment where designers are expected to lead through influence, make calls without permission, and collaborate across functions that don't report to the same person.
The designers I've worked with through GA and Forthward have consistently surfaced the same friction: they have the craft, but lack the structural vocabulary to understand how healthy, flat, high-trust teams operate and how to find their footing and authority within them. That gap is exactly what this framework was built to close.
Distributed
Peer-2-Peer
STRATEGIC FRAMING
Nature already solved this. We borrowed the model.
Ecological systems don't have org charts. They have interdependence, distributed roles, clear contribution to the whole, and remarkable resilience under pressure. Mycelial networks share nutrients without a central node directing them. A forest canopy self-organizes around available light. These aren't metaphors. They're operating principles.
The ecological teaming framework draws directly from these systems to ask: what would a product design team look like if it was designed the way nature designs? The answer shapes everything from how ownership is distributed to how decisions get made to what it means to lead without a title.
The best teams aren't managed from the top. They're cultivated from within, like any living system worth sustaining.
— Tyler Hartrich, Design Practice Lead
THE DRI MODEL IN PRACTICE
Ownership without hierarchy
In a flat team, authority isn't granted by title. It's earned through accountability. The DRI framework gives designers a concrete practice for claiming and exercising that accountability. Every project, initiative, and decision has a named owner. That owner is empowered to move, and equally expected to.
Accountability
Interdependence
FRICTION MOMENT
Ownership is learned, not assigned.
The DRI model is elegant in theory and genuinely difficult in practice. In early Forthward sessions, designers would intellectually accept the idea of distributed ownership and then immediately defer to whoever felt most senior in the room. Building the muscle for real accountability took longer than I expected and required more direct coaching than the framework alone could provide.
DESIGN APPROACH
Five conditions for an ecologically healthy design team
Derived from Forthward session research, field interviews, and the Orb Growth Framework, these are the conditions that distinguish teams that thrive from teams that merely function.
OUTCOMES
What this framework produced
The ecological teaming framework isn't finished. I'm still running it, still refining it, and still learning from every room it enters. That feels right — a living system should keep growing.
Systems
Reflection
The designers who lead the next decade aren't the ones who learned about AI. They're the ones who learned to think with it from day one.
— Tyler Hartrich, Design Practice Lead
Design × Dev
Product Workflow
Forging designer-to-developer workflows in the age of AI
0+
0+
Designers and engineers paired through live cross-functional product sprints
0+
0+
Program iterations run and validated through structured retros + SME feedback
0+
0+
Sprints modeled on product team milestones from kickoff to stakeholder presentation
CONTEXT
The most asked interview question that design education consistently fails to answer
Every time a GA graduate walked into an interview and stumbled on the cross-functional question, I took it personally. I'd built the curriculum. That gap was mine to close.
Every associate-level design interview includes a version of the same question: "Tell me about a time you worked closely with an engineer." For most bootcamp graduates, that question lands like a trap. They've learned the craft. They've built the portfolio. But they've never shipped anything with a developer, and hiring managers can tell.
As Design Practice Lead and program advisor, I've spent years building the infrastructure to close that gap: a live, six-week cross-functional collaboration that puts UX design and software engineering students on the same product team, working against the same brief, navigating the same constraints a real team would face on day one.
Collaboration
Design Sprint
STRATEGIC FRAMING
A simulated product team — with the friction kept in
The instinct in design education is to smooth the rough edges. We deliberately didn't. The program was designed to surface the exact tensions that define real product team work: misaligned timelines, handoff ambiguity, competing priorities between design quality and technical feasibility, and the ongoing negotiation of what "done" actually means.
In my role as advisor and practice lead, I shaped the program's operating philosophy: don't simulate a frictionless product team. Simulate a real one, and give students the frameworks to navigate it. The friction is the curriculum.
The best collaboration experience is the one that prepares you to build alignment, navigate ambiguity, and find your footing when the path isn't perfectly clear.
— Tyler Hartrich, Design Practice Lead
FRICTION MOMENT
Smooth isn't the same as good.
The first version of the program was too clean. We smoothed out too many rough edges in the name of a good learning experience and ended up teaching students how to collaborate in ideal conditions that don't exist in real product teams. We had to deliberately reintroduce friction — and convince faculty that a harder experience was a better one.
PROGRAM STRUCTURE
Six weeks modeled on a real product team sprint cycle
Each phase of the program mirrors a milestone a junior designer and engineer would hit in their first 90 days on the job, with structured learning objectives, cross-functional working sessions, and a continuous feedback loop informing what the next iteration looks like.
Momentum
Sprint
The best collaboration experience isn't the one where everything goes smoothly. It's the one that prepares you for when it doesn't.
— Tyler Hartrich, Design Practice Lead
OUTCOMES
What the program consistently produces
Twenty-five iterations in, this program still surprises me. Every new cohort finds a different edge to test, a constraint we hadn't considered, a tension we thought we'd resolved. That's how I know it's working.
Execution
The designers who will lead the next decade aren't the ones who learned about AI. They're the ones who learned to think with it from day one.
— Tyler Hartrich, Design Practice Lead
