Workera • Principal Product Designer • 3 months
Some background
Workera is a company that helps other organizations figure out what skills their employees actually have, and where the gaps are. Think of it like a fitness test, but for job skills instead of physical ones. To do that, Workera needs good assessments that accurately measures someone’s ability in a given area, whether that’s coding, data analysis, or something else entirely.
Compose is the tool Workera built to let people create those assessments. Cortex is the AI engine that powers Compose behind the scenes. This case study is about designing around that new engine.
The problem
A good assessment only works if it’s actually good, meaning it asks the right questions in the right way to measure the right thing. Building one used to require a specialist. It took a long time, and it asked whoever was building it to hand over a lot of detail upfront, more than most people had ready to go. That process couldn’t scale to meet the number of new customers the business was bringing on. The goal became simple: let people who aren’t specialists build good assessments on their own, quickly and easily. That meant changing how assessments got built, not just adding a nicer screen on top of the old process.
Discovery, and working with engineering
Before any design work started, I spent a lot of time with engineering figuring out what was actually possible. The AI needed to remember things reliably across sessions, and it couldn’t run on its own the whole time. It needed real moments to pause and ask a person for more context before continuing, and figuring out where those moments belonged, along with the rules for how it communicated and nudged people toward a good result, took real back-and-forth to get right. I’d bring a rough idea, engineering would flag where it would break, and I’d rework it. That back-and-forth also meant simplifying complexity that earlier UX passes had introduced, so we weren’t tearing up designs later because we’d built something the technology couldn’t support.
The approach
The design goal was for the agent to feel intuitive, almost anticipatory. Once someone started a back-and-forth with it, it needed to pick up on where the conversation was heading and ask for the right thing at the right moment, rather than making the person figure out what to say next. Getting there was iterative. I’d design a version of that dialogue, watch how people actually used it, and adjust where it felt slow or where the agent asked for something it didn’t really need yet.
Underneath that dialogue, the concept was to make Cortex genuinely headless: the engine that holds the content and logic built separately from whatever screen shows it, so it could work the same way no matter where it showed up. I paired that with what I thought of as a bento box approach: a single flexible framework with defined slots that could hold whatever content Cortex generated, a plan, a set of questions, a recommendation, without needing a new screen built for each one. That let the design stay consistent even as what the agent produced kept expanding.
The old version of Compose asked a lot of someone before they could even start: separate steps for context, uploads, and clarifying questions, each one its own hurdle. I collapsed that into the conversation itself, so people could hand over context, upload documentation, and answer clarifying questions right from the gate, in one flow instead of several restrictive ones. I also kept a two-way door between that chat experience and a manual edit mode, so anyone who wanted to fine-tune something by hand could step out of the conversation, make the change, and step back in without starting over.
The outcome
In the first month after launch, 51 people across 18 companies used Cortex to work on assessments directly, no specialist involved. That’s real usage, not a handful of power users running up the count: the largest group were people doing quick, one-shot sessions, alongside a solid core of people building things out in more depth. What used to take close to a couple hours in the old version of Compose can now be done in as little as 15. This headless, flexible approach turned a slow, specialist-only task into something anyone could do on their own, quickly and with results they could trust and double-check later. It also worked across two different product environments without falling apart or needing two separate designs. Cortex became something other teams started building on, not just a one-time feature: work already underway to bring the same engine into other parts of the product beyond assessments.
Reflection
The real decision here wasn’t about a screen. It was deciding that the actual experience lived inside the engine and the flexible templates around it, not in any one interface. That kind of decision only comes from system design and design strategy, not interaction design alone. Without those two things, we would have ended up rebuilding the same clunky tool with a nicer coat of paint. It also meant designing for workflows that didn’t exist yet, and working close enough with engineering to know what the technology could actually deliver, rather than designing in a vacuum and hoping it would hold up.
