Sofía Nardone — Senior Product Designer

Contact

Dribbble

Behance

Berlin, DE

10:43

CET

Dribbble

Behance

Dribbble

Behance

Berlin, DE

10:43

CET

Re-designing Toaster,
the Keyword Optimization tool at Phiture.

/specs

COMPANY

Doinstruct

Adobe

ROLE

Product and design lead

Adobe

OWNED

Definition → Design → Code

Adobe

PROJECT TEAM

6 engineers + 1 designer

Adobe

STAKEHOLDERS

CEO, Head of Engineering

Adobe

TIMELINE

June 2026 / ongoing

Adobe

/problem

Doinstruct trains frontline workers, people in warehouses, food production lines, and logistics hubs. A single site often runs in ten or more languages, and video is the format that actually reaches these workers.

Inside the product, video creation lived in three disconnected features: a video upload, a slide-to-video generator, and AI voiceover generation. But none knew about the other, creating problems in: quality of content, unfair credit cost and most importantly, quality of translation.

31%

of all product requests were about translation. Every one was support load on our side, every inconsistent language version audit risk on the customer's side.

/my-role

In this project I owned the product side of things as well as the transition from design to code. Definition, design, prioritisation, stakeholder alignment, and decision log were under my responsibilities.

This meant being fully embedded into the engineering team, the repo, the daily reality of the codebase, the new AI workflows we are constantly testing and adopting, deep enough to care for UI accuracy in code myself instead of judging it from Figma.

HOW WE NORMALLY WORK

Design and engineering run one-week cycles. Solution fast, ship, iterate. We don't spend weeks researching before touching code, real usage is a big part of our research.

WHY THIS WAS NO DIFFERENT

Even though technically a feature, the Video Studio is a new product. We were allocated two months to reach alpha, where we kept the agile pace of building the product while iterating on features, design and capabilities.

WATERFALL

One big release after a long buildup

AGILE

Continuous, incremental wins

/project-roadmap

We didn't run discovery first and build second.

From day one, two tracks ran in parallel to buy speed: engineers built a technical prototype to learn what the AI models could actually do, while I ran the product definition, feedback inventories, CX tickets, conversations with users, and sessions with our internal content-creation team.

Every team always begins with the same problem: team chaos. "Where should we start? Who is doing what? What are we even building?"

I facilitated a Product Canvas exercise as a method of gathering team alignment. This allows the team to form a shared basis of understanding, and part of the job was training engineers to think in product, to keep our iteration agility while still building the right thing, and to see that the effort actually paid off.

When the two tracks converged, model reality on one side, user reality on the other, we built the feature list together: brainstormed how far each feature could go, mapped what competitors offer, and drew the four core flows, create, edit a scene (the money flow), translate, publish.

Every open question went on one board and got sorted by two axes: is it hard to reverse, and does it block the first real work.

Questions landed with an owner's name on them, the data model, the multi-language algorithm, the component-library reuse. The reversible ones were decided by their owner and moved on. Only the hard-to-reverse, blocking ones earned a seat in the leadership alignment.

Then the cut, surface by surface, MoSCoW scoped to the alpha.

/definition

TOPIC

DECISION

What do we build?

Compliance/operational content generator.

Who for?

Non-tech frontline managers.

Where?

Standalone product, but connected to main.

How?*

As experimental as non-tech UX allows.

*yes, how. Not why or when since we already had these defined.

Screenshot of the C level alignment meeting.

/design-to-code

We can now easily build the interface I design. The work ships through pull requests like everyone else's, and design QA happens in the PR.

The AI workflow behind that runs on three tools sharing one source of truth. Claude Design for fast exploration, Figma as the system of record, Claude Code working in the repo, and our design system is what connects them: tokens and components mapped between Figma and code, so what an AI reads on one side resolves to what exists on the other. That mapping is why thirteen production-fidelity screens came out of one session, and why prototype designs became a clickable product early instead of waiting in a handoff file.

How that system was built is its own story → the design-system case study

Final screenshots of the main 3 flows for Alpha

OUTCOMES

A locked direction that hasn't moved since July, four decisions, written down, still standing.

A working product iterated on daily in code, not a prototype waiting for engineering.

An alpha scope everyone can refer to: every feature prioritised, cuts written down with reasons.

Beta will get iterated on based on Alpha performance and feedback.

/design-iterations