Adapting UX Practice Across Careers, Cultures, and AI with Aneta Kmiecik | Episode #92

Aneta Kmiecik moved into UX design after working as an architect in Poland and Japan. She enjoyed architecture's creative craft, including learning about wooden architecture at Kengo Kuma's Tokyo office, but the day-to-day role gave her limited contact with clients and other stakeholders. Much of her time went into technical drawings and construction details. UX offered a faster environment, more varied tasks, and more opportunities to work directly with people.

The transition required more than learning new software. Kmiecik had to strengthen her UI skills, understand digital design patterns, and become comfortable presenting ideas as a persuasive story. Her experience shows how designers can carry useful habits from another field while deliberately rebuilding the skills that do not transfer.

What you'll learn

• Which architecture skills transfer to UX design and which require retraining

• How relationships and business language improve executive conversations

• How local colleagues can strengthen cross-cultural B2B research

• Where AI can support research without replacing human interpretation

Transfer systems thinking, not just design tools

Architecture taught Kmiecik to manage competing constraints. A building must respond to regulations, construction rules, budgets, timelines, client needs, and its physical surroundings. UX teams face a different medium but a similar coordination problem: users, business goals, technical limits, stakeholders, and delivery schedules all shape the result.

She also sees a parallel between navigating a city or building and navigating a digital product. Architects consider flows, wayfinding, signs, plans, and the relationship between a structure and its context. UX designers create paths through information architecture and help users understand where to go next. The practical lesson is to look beyond an isolated screen. Map the larger system, identify the constraints acting on it, and examine how each choice changes the user's route.

Tool experience helped, too. After learning demanding architecture and 3D applications such as Revit, AutoCAD, Rhino, and 3D Studio Max, Kmiecik found Figma comparatively approachable. Yet software fluency did not solve her biggest gap. Architectural presentations in her experience focused on drawings, plans, and visualizations. UX required storytelling that could explain a concept and win stakeholder support. Designers changing fields should therefore audit communication, visual design, technical understanding, and domain patterns separately rather than treating prior design experience as a complete substitute for UX practice.

Build executive support before the presentation

When pitching executives, Kmiecik starts with relationships. The right approach depends on who the decision-makers are, what they already understand, and what their organizational roles require them to achieve. Involving them early can make a later presentation more useful because the designer already knows which concerns need to be addressed.

Numbers matter, but reliable ROI calculations can be difficult when teams cannot access data held by other stakeholders. Kmiecik has encountered situations where teams had to work from estimates because research or complete business information was unavailable. Her advice is not to disguise uncertainty as precision. Instead, understand how the work could affect the business, learn the language executives use, and connect user needs to commercial constraints such as time, budget, and revenue.

For listeners, this creates a concrete preparation checklist. Before proposing a UX change, identify the executive's priorities, involve that person before the final pitch, separate known figures from assumptions, and explain the route from design decision to user and business impact.

Research with local context and measured AI support

Cross-cultural research begins with learning how people in a market communicate. Kmiecik recommends involving local colleagues who can translate, explain cultural details, describe competitors, and help researchers interpret behavior. Before a fintech launch in Finland, her team met Finnish colleagues in short question sessions, tested concepts with local people, and spent time in the market. That immersion influenced later product communication, translation, and marketing decisions.

Her own early research in Norway reinforced the value of asking for help. While recruiting B2B participants by phone, limited Norwegian skills and unfamiliar dialects made one conversation difficult to interpret. She confirmed the arrangement by email, then invited Norwegian colleagues to assist with later interviews so participants could communicate more comfortably. The operational takeaway is simple: use local expertise before ambiguity affects recruitment or analysis, and confirm uncertain verbal agreements in writing.

Kmiecik sees immediate value in AI note-taking because it lets a researcher focus on the conversation without assigning a colleague to capture every detail. She is more cautious about automated synthesis and interpretation. Interviews also require observation, respect, security awareness, and judgment about human reactions. Her preferred direction is better integration among note-taking, research repositories, synthesis, and presentation tools, while keeping people responsible for interpreting evidence.

To spread findings, she has used dedicated Slack channels, presentations, informal conversations, and an internal newsletter that invited contributions and promoted research practices. A team can apply the same model by choosing one dependable home for insights, then using recurring communication to bring those insights to people who will not visit the repository on their own.

Listen to the full conversation: Episode #92 audio.

Kmiecik's central message is practical: adapt before a changing toolset forces the issue, stay humble about what you do not yet understand, and preserve human judgment where context changes the meaning of the data.