Curriculum Design · UX · Engineering · 2018—2021
Kenzie Academy UX Engineering Program
Kenzie Academy's UX Engineering program — a bootcamp that taught design and front-end together, built from launch to twelve cohorts by treating the curriculum itself as a product.
- Role
- UX Facilitator → Associate Instructor → Director of Instruction, UX
- Team
- At peak, a team of 4 instructors, 6 facilitators and 5 coaches
12 → 300+
Students
Across the program’s run
1 → 12
Cohorts
Staffing grew 2.5 → 12 alongside
Best UX/UI
Design Bootcamp
Course Report, 2020
A year before Kenzie Academy launched its UX Engineering program, I was sitting on the other side of it — finishing a front-end certificate at The Iron Yard. In June 2018 I joined the launch of Kenzie’s, teaching UI/UX alongside HTML, CSS, JavaScript and React. Over the next three years it went from one cohort of twelve to more than three hundred students.
This is a short account of how it was built.

The brief
“UX Engineering” was the whole proposition. Most bootcamps pick a side — design or development — and graduates arrive at their first job fluent in half the conversation. This program taught both: research, wireframing and interface design and the front-end stack to build it.
That doubles the surface area to teach in the same number of weeks, which is the central constraint everything else had to answer to. Here is what a year had to hold:
Four case studies by graduation
UX Design28 wks
- Design thinking — Google design sprint2 wks
- Foundation project — research, synthesis, ideation, prototyping, testing (Whimsical)3 mo
- UI design & advanced prototyping — Material Design, Figma2 mo
- Capstone project1 mo
UI Engineering25 wks
- Hello world1 wk
- Semantic HTML & CSS1 wk
- Git & GitHub (GUI)1 wk
- Forms, advanced CSS & interactive elements1 wk
- JavaScript fundamentals2 wks
- Interactive JavaScript2 wks
- APIs & CRUD2 wks
- Social media app2 wks
- Mobile-first, responsive & CSS libraries1 mo
- React.js1 mo
- Team capstone1 mo
Laid out end to end, the two tracks almost exactly fill the year — which is another way of saying there was no slack in it. Every week the material didn’t earn had to come out of another one.
The four marked points are deliberate. Students wrote a case study after the foundation project, after each capstone, and after one of the smaller coding projects — so everyone graduated with four case studies, not just a transcript. The portfolio wasn’t a post-program scramble; it was a by-product of work they’d already done. That’s what makes the post-graduation support realistic: portfolio feedback and interview prep run until placement, and they start from four finished pieces rather than a blank page.
How we built it
A day with a fixed shape
The program was flipped. Students met the material before they met us, so contact time wasn’t spent transmitting content — it was spent applying it. Every day ran the same way, Monday to Friday, 9 to 5:
| Time | ||
|---|---|---|
| 9:00 | Discussion | Work through what they’d already read |
| 10:00 | Practice | Apply it with instructors in the room |
| 1:00 | Assignment | Build it alone |
| 3:00 | Office hours | Get unstuck — or book a mentor |
Concept, then supervised practice, then independent work, then help. The same sequence every day, so nobody spent attention working out what today would be like — it all went on the material.
Office hours weren’t only instructor time. Students could schedule 1:1 sessions with working designers from Microsoft, Google, Facebook and LinkedIn, and with senior designers from the local community. That access is the part of the industry a career changer can’t reach on their own — the part that usually depends on already knowing someone. Putting it on the calendar every afternoon turned it from a networking problem into a booking one.
The flipped model is also what made the content pipeline matter so much. If students hit the material on their own before class, the material has to be right on its own. There’s no instructor in the room to paper over a confusing page.
Curriculum as a product
The part I’d point at first. Rather than writing a curriculum and delivering it, we ran it as a closed loop — and automated enough of it that the loop turned in days rather than between cohorts.
The clever part was the middle. We built a custom Canvas LTI that rendered the current Dropbox Paper version directly inside the Canvas item — so there was no publish step at all. Fixing a confusing paragraph meant editing the Paper doc; the students’ next page load had the fix. Version control came free with Paper, so we could see what changed and roll back.
On the other side, grades and student feedback published straight into Airtable, where all our reporting lived. Nobody exported a CSV or reconciled anything by hand.
What that bought was speed. The gap between “this lesson isn’t landing” and “this lesson is fixed” collapsed from a cohort to about a day. Content that consistently landed badly showed up as a pattern rather than a hunch. And because none of the loop needed hand-holding, the team’s time went into teaching and building the program rather than administering it — which, on a team that started at 2.5 people, was the difference between scaling and drowning.
It also made async cohorts viable. Once the material and the feedback capture both lived in the system, delivery didn’t depend on everyone being in the same room at the same time.
Scaling the team, not just the roster
Staffing went from 2.5 people to 12. Growth was in the shape of the team as much as the size: instructors, facilitators and coaches as distinct roles rather than one overloaded “teacher” job. At peak I led 4 instructors, 6 facilitators and 5 coaches, and reported weekly on qualitative and quantitative performance — the same loop, pointed at the program itself.
Where it landed
| At launch | At peak | |
|---|---|---|
| Cohorts | 1 | 12 |
| Students | 12 | 300+ |
| Staffing | 2.5 | 12 |
In 2020, Course Report named it Best UX/UI Design Bootcamp — outside validation of the program as a whole rather than of any one part of it.