Our two-person studio has decided to experiment with something I haven’t really seen many people share their process for before. Can two freelance designers design and own the entire front end, from ideation to execution, on a real client project?
Having never owned a process in this much depth before, it’s been interesting to see how we balance our process and time between design and engineering.
How could we leverage our agents to truly speed up our process, while also owning a part of product development that designers have traditionally said was out of scope? Of course, freelancing is different in the sense that being a jack of all trades has always been favorable to smaller clients.
“Yes, of course I want one person to do it all.”
While skeptical, I thought maybe it’s finally time for this to be true? Can agents enable designers own more of product development.
Designing for an unclear problem
Solutions are thrown out, and everyone on the team can come up with a “prototype” generated from three prompts.
The expectation has quickly become, “If I can generate something this quickly, then why can’t design do the same, but even better?” Why can’t the designer prompt their way to quality?
I’m finding that whether it’s changing a layout by dragging on a canvas or saying a vague sentence to a robot, neither is enough to reach quality design. More and faster iterations are a means to get to a quality solution, but they only work if the designer and their team are aligned on what the core problem is and who they’re making it for.
The trojan horse
It’s easy to create something now that appears as if a lot of thought went into it, but in reality, your agent filled in the gaps, made assumptions, and made 1,000 tiny micro-decisions that the designer would have originally made and iterated on.
The designer’s mental model gets skewed and is likely to become incorrect if you let it. It’s easy for me to fall down this rabbit hole if I don’t catch myself.
I’m finding that, as designers, we can do the building and, like a furniture designer, benefit from working in the material. But what’s new to us is learning when to stay at the level of abstraction that Figma or a canvas provides. The ability to quickly change a detail without waiting for “someone else” to do it. Being able to make a duplicate and try a different version. Avoiding the gamble and indeterministic results when designers were often trained to work deterministically.
Having worked through both kinds of design processes, deterministic and indeterministic, I know that we always did and needed a little bit of both. There’s value in the ability to go down a rabbit hole because you handed off a significant change and now have some time left to iterate on 50 versions of an icon set on the canvas.
Ideating vs Building
When do designers engage in ideation, and when do they become involved in execution? I’ve seen many people conclude that design has always been more about thinking, with tools like Figma, blueprints, or pen and paper serving merely as mediums for bringing our ideas into the world.
I think the answer lies somewhere between what you want and the project’s goals and constraints. I found that, with limited resources and engineers whose responsibilities didn’t traditionally include design, it was, of course, difficult to wrestle with the minute details of interaction design and visual/UX quality. Their quality and focus lie more often in the code.
As designer-engineers on this project, we volunteered to own not only the decisions but also the execution. However, taking ownership quickly turned into fixing bugs and optimizing a front end we had never touched before.
For context, like many freelancers, I can roughly read and write code and have learned the basic coding concepts. But in practice, a good engineer’s job has never been just to output code. What mattered was their judgment and experience with architecture, performance, and much more. (Obviously, I’m not an engineer.)
This year, I’ve been emphasizing that working in code has many of the benefits of working within constraints. But when these expectations of “good engineering” were placed on us, I felt overwhelmed. We quickly fell into a full-stack approach, from building the codebase and writing PRs to debugging, animation, and performance optimization.
Instead of gaining back time, we spent a lot of it learning best practices and second-guessing our code hygiene. We lacked the judgment to evaluate the code output. I’ll be the first to say that our time is likely better spent using our judgment to ideate and polish the customer experience.
Everyone can execute
So while it’s great to understand a codebase, its intricacies, and have a much more accurate mental model, I found myself too much in the weeds, spending less and less time on design thinking and more and more time thinking about execution.
Is that even bad? I don’t think it inherently is, but it does go against what I love about design and what I believe designers should be spending the majority of their time on. Charlie Deets, a designer for Dia, proclaimed that:
“If I keep staying on this end of the equation, where I’m thinking [as a designer], I’m more novel over there than I am in the execution realm, because everyone can kind of execute right now.”
That struck me pretty hard, as it clearly means that I, and nearly every other product designer, am building that intuition for when execution is our “secret sauce.”
Notes
- “Linear doesn't have a secret. That's the lesson” by designer James Baduor inspired me to write this and share my experience
- “Canvas” refers to tools like Figma, Paper, or sometimes even pen and paper. I find these most useful when diving deep into details or simply creating something visually novel and organic.
- AI is great for visual design tools that create patterns and systems. Our robots thrive on rigid rules and parameters.
- Dive club interview with Charlie reminded me that, for many designers and their contexts (the product, the culture, their team’s makeup), execution isn’t always the best use of their time.
- Another similar piece of writing about this idea of how AI’s volume can deviate from simplicity
- The thumbnail was inspired by Jakub Krehel’s personal brand logo and by Paul Macgregor stunning blog thumbnails.