Adam Fard

The through-line

Across everything Adam Fard says, one idea holds: AI raises the floor for everyone doing design work, and that is a good thing, because the ceiling still belongs to people who understand principles. "We are raising the baseline. So everyone can start from a better place but also professionals will always have the edge" [1]. The corollary he keeps returning to is that AI should sit inside the existing process rather than pretend to replace it. "UX Pilot doesn't do the job for you it's not there to replace you or kind of create the final artifact it's more of a layer that you add into your process" [2].

What has shifted over time is where he thinks the leverage sits. Earlier the emphasis was on discovery, workshops, document analysis and turning insight into diagrams, with an explicit ambition to move "from being that kind of product company to a data company" built on small, UX-specific models [2]. Later the emphasis moves to visualisation and handoff, and to a much sharper claim about tooling: that vector-based design is on its way out and code is becoming the real deliverable [1].

On raising the baseline without flattening the craft

Fard is untroubled by non-designers producing designs. Product managers, product leaders and founders using UX Pilot to visualise an idea means "you don't need to write PRDs, you don't need to write requirements, you can just explore things and then share those thoughts with the design team" [1]. He frames this as a fix for an old and genuine problem: stakeholders who could not articulate a vision, forcing designers "through a multiple kind of exercises, workshops and so on to be able to understand like what's their vision" [1]. Visualising early does not oblige anyone to build what was visualised, but it improves communication.

The edge professionals retain is judgement and vocabulary. Someone with a design background "can see what's good, you can spot those interesting ideas" and "guide AI better even use the right keywords when you're prompting" [1]. Looking five years out, he expects the market to bifurcate: still "a place for true experts" in visual design, animation and storytelling, but "less need of people doing simpler work", with the centre of gravity moving to "how you would combine things together, how you would connect different parts of the product, how you would automate or guide even different systems without having this craft or manual work involved" [1]. In research the same split applies: transcription, summarising, connecting concepts and quick sketching will go, while "the research and the thinking behind research and how to conduct the research" stays [2].

On why vectors are the problem and code is the handoff

His most pointed prediction concerns Figma. He notes that design teams which were "heavily focused on Figma" a year or two ago are now "open to additional tools" and no longer "so much locked into this Figma ecosystem" [1]. The structural flaw he identifies is the two-world problem: designers hold components and requirements on one side, developers hold their own version on the other, "and it leads to all kind of issues where things are not implemented properly, where you can't communicate things" [1]. AI tools remove the intermediate artefact. "The good thing with AI tools is that you don't need to deal with vectors anymore. So I think that's one of the things that could make Figma obsolete. The fact that they rely heavily on this vector-based interface" [1]. In UX Pilot the user does not edit code directly, but editing a design is "very much like interacting with the code", so the output is "the final handoff which is code which is a direct translation of your vision to developers" [1].

On the UX of AI itself

He accepts the premise that prompting is a poor interface with a steep learning curve, and sees two routes out. The first is context replacing verbosity: he points to how Midjourney once demanded "so many keywords and so many filters" and now yields better results from simpler prompts [1], and argues the same should come from feeding a tool product context, components, design assets and branding "so you're not relying so heavily on prompting and trying to explain everything into detail" [1]. The second is control granularity. Full-AI prompt-in, output-out is not enough; users need "to control where AI is applied" and eventually to adjust things manually. He describes this as "this scale or fluid way of interacting with AI tools", moving "between manual co-creation and full AI process", with some of it shipped and some in development [1].

The same instinct governs how he handles bias and hallucination. Rather than claiming accuracy, he makes the AI output optional and inspectable: it is a layer, "and you can always adjust that layer or take that layer or even disregard it or ignore it", so the user stays in control of the process [2].

On why the UX process resists prompt-to-screens tools

His critique of competing AI design products is that they are built by people outside the field. Most "are focusing on the UI side of things and maybe because they're not built by UX professionals uh they see the whole UX process as a linear process where you have your prompt and then suddenly you have a flow and you a bunch of screens and you're done" [2]. That model, he argues, works "if you're building a weather app or a yoga app" and fails almost everywhere else, because real work involves "a lot of room for exploration, there's a lot of back and forth, you have to integrate new insights and the whole process is quite messy" [2]. Hence his stated design principle for the product itself: "we are not trying to reinvent the UX process we are trying to integrate UX Pilot into your process" [2], and likewise no intention to "reinvent Figma, Miro or other tools", but rather to push the data and AI layer into them [2].

On bringing knowledge engineering into research

The discovery side of the tool grew out of a specific pain: knowing which workshop to run, when, and how. Practitioners typically need the exact name of a workshop, a template, and the facilitation know-how, "otherwise you kind of lost" [2]. So the first feature generated targeted frameworks from a stated goal, time frame and participant count, with a facilitator manual, dynamically adjusted activities, an invitation email for participants, and export to a FigJam board [2]. Workshop output then feeds visual tools that turn sticky notes into flow diagrams fast enough to be checked with participants during the session [2].

For analysing bodies of text he deliberately imports techniques he used inside the agency that are uncommon in research practice. Tagging and coding are familiar, "but not necessarily using graphs or building relationships between concepts" [2]. He describes knowledge graphs that surface concepts and their relationships from a document, and semantic clustering of sentences where lowering the cluster count exposes outliers and raising it reveals finer categories [2]. He is explicit that the right technique depends on the material: clustering suits interview data, while a knowledge graph may not be insightful there and sentiment analysis might serve better, and analyses can run on a single text or across a whole corpus to find patterns [2].

On small models and becoming a data company

He sees the next phase as building "much smaller AI models but focused on very specific UX challenges", which requires assembling specific data sets and training [2]. The reasoning is efficiency and fit: "you don't need the large language model to do the clustering, you can use a much more smaller and specific model" [2]. Beyond clustering he names predicting user behaviour from a layout, and generating attention or meaning maps from a UI [2]. This is framed as both the next step and the next challenge for the company [2]. Adjacent to this, he has discussed how AI acts as a force multiplier in redefining SaaS product design, alongside product-market fit and team building [3].

On what new designers should actually learn

His advice to people entering the field is to ignore tool fluency. "A decade ago it was Photoshop. I used to use Photoshop for web design. Then it was Figma. Now it's UX Pilot. Probably tomorrow some other tools will come out" [1]. What persists is "understanding principles", named concretely as layout, hierarchy, colour, how users actually use a product, and product strategy, all of which he ranks far above "trying to learn tricks inside Figma or any other tools" [1].

On career direction he resists a single answer. Designers can now move into prototyping and even coding "without really having that deep knowledge into how to write code or what's the right syntax" [1], but he warns that the design engineer path should not be the only one. Product and research are equally open: in his own company they spend heavy time "talking to our users, understanding how they use a tool, going through our metrics, finding patterns" [1], with AI used to avoid hours of transcription and to run data analysis for people without that background. The instruction is to "see which areas you're interested in and kind of explore that part a little bit further instead of trying to fit yourself into a very rigid and specified curriculum" [1].

On building the product out of your own practice

UX Pilot began as a side project inside a UX agency working with startups and large brands including HubSpot, T-Mobile and Samsung, started as an internal exploration of "how we can apply AI to the product design to what we were doing internally" [1]. The agency's B2B focus and its educational content, courses and training exposed the problems practitioners were facing, and the product was a way to address them [2]. The workshop formats shipped in the tool are the agency's own: "things that we always conducted within the agency, based on our own practices we define these formats" [2]. He later moved to the product full time [2]. Today the focus is squarely on product teams, serving both designers who want to "explore multiple concepts at the same time very quickly" and produce high quality handoffs, and non-designers who simply need to make an idea visible [1].

Takeaways

• AI raises the baseline for everyone, but experienced designers keep the advantage because they can spot good ideas and prompt with the right vocabulary [1].
• Position AI as an adjustable layer in the existing workflow, not a replacement: users must be able to adjust, take, or ignore the output, which is also the practical answer to bias and hallucination worries [2].
• Vector-based design is the bottleneck; when the artefact becomes code, handoff becomes "a direct translation of your vision to developers" and Figma's core advantage erodes [1].
• Prompting is a transitional interface. Reduce dependence on it by feeding tools product context, components and branding, and offer a fluid scale between manual co-creation and full AI [1].
• Most AI design tools assume a linear prompt-to-screens process, which only works for trivial apps; real UX work is exploratory, iterative and messy [2].
• Small, task-specific models beat large ones for jobs like clustering, and open up predicting behaviour from a layout or generating attention maps from a UI [2].
• Learn principles rather than tools: layout, hierarchy, colour, user behaviour and product strategy outlast Photoshop, Figma and whatever replaces them [1].
• Techniques from knowledge engineering, such as knowledge graphs and semantic clustering, are underused in research compared with tagging and coding [2].