Stephen Sherwood
Home About Smash MoodiBoard
About · Stephen Sherwood

Four years. One startup. A lot of design systems.

Founding designer at an edtech startup. Research TA at the UW iSchool. Currently building MoodiBoard. Selectively open.

Currently Building MoodiBoard: generative artwork from your personal data, on your screen.

Toolkit

  • Product designEnd-to-end flows, prototyping in Framer, spec writing, shipping with engineers.
  • Design systemsComponent libraries, token architecture, documentation developers actually read.
  • ResearchInterviews, usability testing, synthesis, journey mapping.
  • ToolsFigma · Framer · Principle · Webflow · Linear · Notion.
  • AI & emergingBuilding AI-integrated design workflows. Regular at Seattle AI & product design events.

Timeline

2025 →
Building MoodiBoard
Independent · Seattle
2025
Sabbatical / deliberate pause
Reading, building, deciding what's next.
2023
Founding Designer · Smash.technology
LMS · 2,000+ learners · 3 eng teams
'22 — '23
Design Methods TA · UW iSchool
Methods · usability · synthesis
Building now

MoodiBoard: a living art platform where real-time signals drive generative visuals on your screen.

Sleep, weather, your schedule rendered as generative artwork on your TV. Glanceable, calm, opinionated about not interrupting you. Live since January 2026.

Offline

Reading. Baking. Learning things for no reason. Wandering Seattle. The phone stays in the other room.

About: a longer version.

Section02 / About
FiledMay 2026
BasedSeattle · Remote
StatusSelectively open
01

Background

Four years designing products where the hardest part wasn't polish; it was figuring out what to build. As founding designer at Smash.technology, I inherited a blank Figma file and three engineers who'd been designing in code. I built the system first, then the product.

Before that I spent a year TA-ing Design Methods at the UW iSchool across 5 quarters, including two simultaneous sections as the first undergraduate to do so. About 30% teaching the methods, 70% helping undergrads recognize when their hypothesis was wrong and what to do next. When the startup didn't find the market, I took 2025 to be deliberate about what came next rather than jumping at the first thing available.

02

How I work

Systems before surfaces. Specific before general. I'd rather write down one honest decision with its trade-offs than list ten capabilities without evidence. Before the iSchool I learned to explain my reasoning out loud, and it's still how I work through a problem.

AI is increasingly part of that practice. I attend every AI and product-design event I can find in Seattle, and I'm actively building design workflows around it, not as a productivity gimmick, but because the surface area of what design is is genuinely shifting.

03

Tools & methods

  • Product designEnd-to-end flows, prototyping in Framer, spec writing, shipping with engineers.
  • Design systemsComponent libraries, token architecture, documentation that developers actually read.
  • ResearchInterviews, usability testing, synthesis, journey mapping.
  • ToolsFigma · Framer · Principle · Webflow · Linear · Notion.
  • AI & emergingActively developing AI-integrated design workflows. Regular at Seattle AI and product-design events.
04

Currently

Since January 2026, building MoodiBoard: a living art platform where real-time signals drive generative visuals. Sleep, weather, your schedule. Art that shifts with your day rather than demanding your attention. Selectively open. Looking for teams working at the edge of AI and product design.

[ § 02 / About ]

Four years. One startup. A lot of unfinished thinking.

Founding designer at an edtech startup from blank Figma to "we didn't find the market." Research TA at the iSchool. 30% teaching the methods, 70% helping undergrads accept their hypothesis was wrong. 2025: deliberately not working while deciding what came next. 2026: building.

Background

I think too much about why design systems fall apart six months after the person who built them leaves. Most of the answer is that they were built for the wrong audience: designers, instead of the engineers who actually have to use them at 4pm on a Friday.

Before the iSchool I learned to explain my reasoning out loud. Before product design I thought design was about polish. The iSchool fixed that. A year of helping students realize their hypothesis was wrong taught me more about product than any course I took.

How I work

Systems before surfaces. Specific before general. I'd rather write down one honest decision with its trade-offs than list ten capabilities. AI is increasingly part of the practice; I go to every AI and design event in Seattle not to network, but to actually learn what's changing.

Offline: Reading. Baking. Learning things for no reason. Wandering. The phone stays in the other room.
Specimens
On tools

Figma for flows. Framer when something needs to feel alive. Principle when a flat click-through won't cut it.

On systems

Atomic design is a great idea most teams implement in a way that makes everyone miserable. The trick is knowing when to stop abstracting.

On research

The methodology matters less than how honest you are about what you found.

On AI

Not a threat to good design thinking. A threat to designers coasting on deliverables.

On polish

Polish is the last 10%, but it can't fix a wrong direction. Most "polish problems" are actually framing problems.

Currently

Building MoodiBoard. Selectively open. Right team, right problem.