Eight Teams, One Day, and a Lot of Learning with Codex
It seems like there is a new AI tool coming out every five minutes. The pace is hard enough to keep up with individually, let alone when you're trying to help an entire design organization learn new tools and new ways of working.
But you have to start somewhere. You have to keep the learning and momentum going, while also keeping morale up and making room for people to connect, experiment, and inspire each other along the way.
One of the things I try to do as a design leader is carve out dedicated learning days for my team. Everyone learns differently and at their own pace, and sometimes people just need permission to put the day-to-day work aside and play with something new.
Our latest learning day was focused on Codex and AI design methods. We split into eight teams, gave everyone the day to build something, and mostly just had fun experimenting together.
Teams built everything from travel and restaurant apps to wildlife conservation tools, museum experiences, and a Jimothy Tracker that kept everyone laughing. People shared what was working, helped each other when things weren't, and passed tips and tricks around throughout the day.
Codex is just one tool among many, and I'm sure the tools will continue to change quickly.
The point wasn't to master Codex in a day or to redefine the entire UX discipline and AI-powered design process. It was much simpler than that.
Give people some hands-on time with AI, let them experiment without the pressure of a real project, and create space for everyone to learn from each other.
The products themselves were wildly different, but what surprised me most was how similar the teams' workflows became in just a few hours.
By the end of the day, the biggest lessons were really about how people learned to work with AI.
For me, it was also more evidence that AI isn't replacing design. It's another tool that allows us to move through the design process in new ways. We can explore faster, build sooner, and iterate on working experiences in ways that weren't practical before. But the fundamentals of design remain the same.
What problem are you trying to solve, for whom, and in what context?
What is the best solution to that problem that meets the need, is feasible to build, and drives the intended outcome?
The tools are changing quickly. The responsibility of design isn't.
Here are eight insights from the day:
1. Use the annotation tool.
Without question, the most common reaction I heard throughout the day was, "Wait...you can do that?"
Many people didn't realize Codex has an annotation tool that lets you click directly on part of an interface and request a targeted change. Instead of trying to describe where a problem was or asking it to regenerate a larger portion of the experience, they could point directly at an element and ask for a change.
Once people discovered it, iteration became much easier. A button could be adjusted without touching the rest of the page. Navigation could be refined without starting over. Small visual details could be addressed directly.
Sometimes learning a new AI tool isn't about mastering prompting. It's simply about discovering the features that make it easier to work the way you already think.
2. Give it a good brief.
One thing became clear pretty quickly. Better context usually produced better results.
Before building, several teams spent time defining their product idea, target users, value proposition, features, design principles, and visual direction. Some looked at competitors. Others created mood boards or gathered examples of experiences they liked.
Instead of asking Codex to "build an app," they were able to give it a much richer picture of what they were trying to accomplish.
It's the same lesson we've learned working with people. Context matters.
3. Use different tools for different jobs.
Several teams naturally started moving between ChatGPT and Codex rather than trying to do everything in one place.
ChatGPT was useful for researching competitors, working through ideas, defining features, and creating a clearer product brief. Codex became the place where those ideas turned into something people could actually interact with.
That division wasn't prescribed. People figured it out as they worked.
It's also a good reminder that there probably isn't going to be one AI tool that does everything. Part of becoming fluent with AI is learning which tool is useful for which part of the job.
4. Show what you mean.
Designers communicate visually, so it shouldn't be surprising that visual references helped.
Teams uploaded screenshots, mood boards, style guides, and examples of products they admired. Those references often communicated more than another paragraph of prompting could.
Rather than spending ten minutes describing a visual direction, you can often just show it.
That sounds obvious, but for people learning to work with AI for the first time, it was an important realization.
5. Make small changes.
The teams quickly learned not to regenerate everything whenever something wasn't right.
They adjusted one part of onboarding. Changed a navigation pattern. Reworked some copy. Refined a component. Then they looked at what happened and made another change.
This made working with Codex feel much more manageable. It also reduced the frustration of getting something you liked, asking for one change, and accidentally losing everything that was already working.
Small iterations still matter, even when the tool can generate a lot very quickly.
6. Think before you generate.
A few people discovered that taking another minute to finish their thought before hitting generate saved quite a bit of time later.
Instead of sending fragments one after another, they gave Codex the product context, audience, desired behavior, visual references, and constraints together.
The results were generally stronger because the tool had more context to work with.
AI makes it incredibly easy to move quickly. Sometimes the best thing you can do is slow down for sixty seconds first.
7. Turn what you learn into a skill.
One of the more interesting things that came out of the day was seeing how quickly individual discoveries could become shared knowledge. Someone would figure out a useful approach, share it with another team, and suddenly that idea had value beyond the person who discovered it.
I think this becomes much more important as we work with AI. The goal isn't to become better at writing prompts. It's to identify the knowledge and expertise that can be codified into reusable skills and capabilities.
Those skills can be shared across the organization, but they can also become part of the AI itself. Instead of keeping valuable knowledge in someone's head or buried in a project, we can capture it, refine it, and embed it directly into the systems and AI workflows that teams are using.
Over time, those individual skills can become part of a larger knowledge system for the organization. The more we learn, the more that knowledge can be reused, improved, and built into how we work.
That's a very different kind of design asset. It's not a file that gets handed off. It's knowledge that can move through the organization and become part of the intelligence behind the tools we use.
8. Give yourself permission to play.
Maybe the most important lesson was also the simplest.
People had permission to experiment.
They could try something ridiculous. Change direction halfway through. Generate three versions just to see what happened. Break something and rebuild it. Nobody was worried about whether the work was ready for production.
That freedom mattered. People were learning because they were playing.
And sometimes that's exactly what learning a new technology should feel like.
My biggest takeaway:
My biggest takeaway wasn't really about Codex. It was about making space to learn.
AI is moving quickly, and we can't expect everyone to keep up between meetings, deadlines, and project work. As leaders, we need to give people time to experiment, learn from each other, and get comfortable being beginners again.
Codex happened to be the tool we used that day. There will be many more.
The tools will keep changing. We just have to keep learning.