What happens when AI helps design and development speak the same language?

Designers had never worked in code, and there was no playbook. This is how I piloted the process myself, brought the team along, and built a new way of working.

Nobody on the team had worked this way before, including me. So I went first. I worked out where it was safe to start and what would trip people up, then used my mistakes to create learning materials for the rest of the team.

It started with small deployments to the design system, then to our main Semble app. We found ways to prototype with the design system in code, which led to our own prototyping tool with realistic data and a way to deploy links for collaboration and user testing.

Every team has early adopters, and making the most of mine was essential. I encouraged them by highlighting their work, and consistent progress led to promotions. Their efforts did a job I couldn't do alone, because it proved the process worked on the ground.

I used my champions to bring up the designers at the back of the adoption curve. Peer support is more convincing than a manager's instruction. It got the more hesitant designers over the main hump, and the whole team was able to deliver on both initiatives.

The hump is the first deployment. Fear, jargon and unfamiliar tooling all gather around it, so the first task had to be simple. I created one that was limited in scope. Our design system runs much lighter locally than the main app, which can result in dependency hell, so it was the natural place to start.

The task was straightforward, but it built reps in the full development flow, from idea to merged code. It meant setting up locally and getting into the coding tools with a defined task rather than a blank page. There were plenty of hiccups along the way, which we problem-solved together. Within 2 months, all designers had deployed something to production, including our newest, who was still onboarding.

The main fear in the team was pressing the button without knowing what it would do. They felt a gap in understanding and were afraid of making mistakes. The beauty of the task was that it was foolproof, and our engineering process already has safeguards built in.

So I encouraged them to try and fail, because that's 100 times better than not trying at all.

Everyone had completed it within two months. Some took it further, pairing with developers and building out the front end for projects on our roadmap. In one key project, this contributed to halving delivery time.

Designers naturally started pairing with each other, and I set up sharing sessions where we could come together, demo learnings, and challenge each other on new approaches for building as designers, making the most of our direct access to the monorepo!

The next initiative was looser and played to a skill they were already confident in: prototyping. I started by finding an area of the codebase with a lightweight Vite app, full access to the design system and no back-end dependencies. One of our developers followed this by building us an internal prototyping tool, working alongside the team to build out dummy data and site furniture.

By the end of the month, everyone was prototyping with our design system, sharing links with users for testing that truly looked and felt like the app, and handing front-end code to development. We're tracking the impact on time and quality, but early signals show improvements in both areas.

It has also let us ship improvements that might otherwise have been missed, such as better mobile layouts and replacing legacy components.

• Go first and start small
• Find your champions, and let them do the convincing
• Create an environment where it’s safe to make mistakes and break things