SyncIEP was built for special needs educators, providers, and teachers. My co-founder taught special education for twelve years, and most of what we build comes out of arguments about how the work actually goes.
The first screen I designed for it came from the perspective of workign in legal tech for 2 years, and that was wrong in a way that took a while to see.
I built the initial mockup to look like enterprise software. I mean, the reasoning seemed fine at the time. This is a tool that handles dense and potentially sensitive documents (plus compliance deadlines), so it should look like it takes that seriously. Restrained and neutral.
First thing my co-founder said to me was it looked "bleak". It should've been playful, colorful, something you'd want to actually do a bulk of your work in.
The problem is that the market is already full of software that looks exactly like that (no shade intended), and teachers associate it with the paperwork which is their least favorite thing to do (surprise!). When your product opens the same way, you have told the user what to expect before they click anything. Ours is meant to be the thing that saves them hours per week, not only the thing that reminds them a triennial is due or what to say in a meeting based off the kids latest progress reports we generate.
Not only did it basically resemble the muted office from Severance, there was a mismatch in setting too. Special education teachers work in classrooms. The visual language of that world is not muted gray.
So we redid it, and the tone is closer to something a teacher would not mind having open all day.
I left the original on Figma Community if you want to look at it:
https://www.figma.com/community/file/1665540375772072468/synciep
If we're looking for some super-deep philosophical insight here, it's that I designed for what the software does rather than for who has it open.
Top comments (2)
Creating a connection between the digital product and the physical world builds familiarity for the user, making it way more likely they'll use it. Otherwise, it feels off and like it's not for them. You did great changing the design direction!
The interesting part of this story is that nothing in the file was wrong. The enterprise mockup was internally consistent, well-executed, defensible line by line — a coherent answer to the wrong question. That's why it took a while to see: design review checks whether the screens match the intent, and they did. The intent was where the error lived.
Which means the thing that caught it wasn't taste, it was information — twelve years of your co-founder knowing what a teacher's day feels like. No amount of polishing the mockup would have surfaced that, because the missing input wasn't in the file.
"Designed for what the software does rather than for who has it open" is a genuinely good one-line test. The tone question gets answered before the first screen exists, and it's answered by the audience, not the document type.