solvistas GmbH

Digital Agency

Show all Videos

Mateo Adzaga, UX Designer bei solvistas

Mateo Adzaga von solvistas redet im Interview über seine Tätigkeit als UX Designer, wie er damit begonnen hat und was er selbst gerne als Anfänger gewusst hätte.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Mateo Adzaga, UX Designer bei solvistas," Speaker Mateo Adzaga charts his path from HTL Leonding and a solvistas internship—accelerated by a chance encounter during a side job—to studying Computer Science at JKU while working part-time, then moving from developer to sole UX designer after a UX training. For the past 4–5 years he has supported projects end to end: gathering requirements, translating them into designs, presenting in refinement meetings, iterating on client feedback, and aligning design decisions with product owners, developers, and ideally end users. His takeaways: UX has multiple entry routes (programming, project management, psychology); success hinges on social skills, proactively seeking feedback, and balancing customer expectations with developer efficiency, aided by a technical background and available UX courses at HTLs, JKU and universities of applied sciences.

From Developer to UX Helm: Lessons from “Mateo Adzaga, UX Designer bei solvistas”

A DevJobs.at editorial on feedback, alignment, and the craft of end‑to‑end UX

In “Mateo Adzaga, UX Designer bei solvistas,” speaker Mateo Adzaga shares how he moved from HTL student to the sole UX designer at his company, now steering projects from first requirements to delivery. What stands out is not a dramatic pivot, but a grounded progression: a mandatory internship, a part-time job at a spa, a chance encounter with a managing director, part-time work during HTL, a computer science degree—and then, almost incidentally, a shift into UX after securing a seat in a training he wasn’t initially slated for.

Adzaga’s story highlights a simple formula with outsized impact: curiosity plus social skill plus technical grounding. He shows how actively seeking feedback, explaining decisions, and balancing stakeholder perspectives make UX more than a set of wireframes—it’s the art of turning constraints and expectations into usable, shared outcomes.

Early moves: HTL Leonding, internship at solvistas, and a decisive encounter

Adzaga began at HTL Leonding. In the fourth year, he completed his mandatory internship at solvistas. Alongside that, he worked in a spa as a beverage staff member. A casual meeting with one of the managing directors at the spa set the next steps in motion:

“…one of the managing directors was shopping at the spa and met me and asked, what are you doing here, don’t you work for us?”

From a brief conversation emerged a concrete offer: to work part-time at solvistas while still in HTL. It’s a simple moment with a strong lesson—opportunity isn’t just in classrooms; it appears in everyday visibility and in being open about where you are and what you aim to do.

Study and continuity: Computer science at JKU, part-time at solvistas

After graduating from school (Matura), Adzaga knew he wanted to study. He enrolled in the computer science bachelor’s program at JKU and continued part-time work at solvistas.

“…after the Matura it was clear to me that I wanted to study. I enrolled in the computer science bachelor at JKU and worked part-time at solvistas.”

Two patterns stand out here: continuity and compounded learning. He spent two to three years as a developer, deepening technical foundations and seeing firsthand how code decisions influence products, teams, and customers.

The inflection point: a UX training and an “I snuck in” moment

After two to three years in development, a UX training opportunity arose. Adzaga wasn’t supposed to attend. He still found a way:

“…I wasn’t intended for it, but I kind of snuck my way in…”

That step flipped the script. After the training, he took the “UX design helm” within the company. Today, he is the only UX designer and accompanies projects end to end. It’s more than a nice anecdote—it’s a reminder that proactive curiosity plus ownership can create roles, even when they aren’t neatly defined beforehand.

Solo but not alone: the only UX designer, involved from start to finish

“Man begleitet eigentlich die Projekte von Anfang bis Schluss,” he says—you accompany projects from start to finish. Concretely, that means:

Listening to customer requirements during planning
Translating those needs into design concepts and drafts
Presenting, discussing, and iterating on those drafts with regular feedback

“…you are involved in most projects, from planning, listening to customer requirements, translating them into the design world…”

Feedback is not a side activity but the operating system. In “technical refinement meetings,” he presents drafts, solicits input, and carries those insights back into the next iteration. Show, listen, refine—this loop is his default.

Alignment is everything: customers, Product Owner, developers—and ideally end users

A second throughline is alignment. UX work isn’t done in isolation; decisions are explained and argued clearly so they can be shared. Adzaga names the essential groups outright: customers, Product Owner, developers—and ideally end users.

“…you make sure that everyone is practically in the same boat, in this UX design boat: the Product Owner, the developers, the customers, and hopefully the end users.”

This is the essence of professional UX: not just producing deliverables, but shaping the conversations that reconcile business, implementation, and real user needs.

Real compromises, not easy outs: between efficiency and “the best possible design”

Adzaga is candid about the tension in daily work: developers want to work efficiently and invest minimal resources; customers want the best possible design. UX lives in the middle—as translator and prioritizer.

“…developers want to work efficiently… customers want the best possible design, and you need to balance between them.”

The implications are practical:

Designs must be explainable, grounded in context, and implementable
Engineering effort is not a hurdle to be ignored, but a quality signal
Customer expectations matter, yet not every “more” improves the outcome

Teams build trust when both sides feel seen—product excellence and engineering feasibility sharing the same plan.

Feedback as a must-have routine: ask actively, handle criticism calmly

Adzaga’s stance on feedback is crisp. Just because you personally like a design doesn’t mean others will.

“…just because you personally like the design doesn’t mean everyone else will…”

This leads to a dependable routine:

Proactively ask for input—not only when it’s offered
Normalize critique and interpret it with care
Iterate visibly and regularly, reducing ambiguity over time

In this view, UX equals facilitation plus learning—turning opinions into decisions that reflect shared understanding.

Many paths into UX: programming, project management, psychology

Adzaga underscores that UX welcomes multiple backgrounds. His route is via programming. Others arrive from project management or psychology. What ties these paths together are social skills: handling critique, asking for input, and negotiating compromises.

“…various backgrounds are practical… people can come from project management or psychology…”

If you’ve already worked with stakeholders, refined requirements, or studied user behavior, you’ve got leverage that maps neatly to UX practice.

Technical grounding as an advantage: feasibility and effort in view

A standout point: a technical background is “definitely useful” in UX. This mirrors what cross-functional teams observe everywhere. If you can think like an engineer, you argue more realistically, spot risks earlier, and design interfaces that won’t get stranded at implementation time.

“What is definitely practical in UX design is having a technical background…”

For teams, the takeaway is straightforward: UX and engineering benefit when they’re tightly coupled—through hybrid profiles or strong communication rituals.

Where to learn: HTL, university, universities of applied sciences

Adzaga notes that the learning paths are already in place: HTLs now offer a dedicated UX subject; universities (e.g., JKU) and universities of applied sciences offer courses as well. If you want to step into UX, you can build fundamentals in structured settings—and test them immediately in projects.

“…in HTL there is already a subject for UX design… alternatively at university such as JKU or at various universities of applied sciences…”

The core of the role: translate, prioritize, explain

What lingers after this devstory? UX is a continuous dialogue—with requirements, with users, and with the teams who ship the product. The differentiators are clear:

Translate: turn domain and business language into clear, usable structures
Prioritize: align limited resources with the most valuable steps
Explain: make decisions transparent to customers, the Product Owner, developers, and end users

These aren’t add-ons to design; they are the design.

A practical playbook from the story

Translating Adzaga’s account into everyday moves yields concrete guidance for UX and adjacent roles:

Show early and often: bring drafts into refinement meetings; visibility reduces rework
Invite feedback actively: ask pointed questions to get actionable responses
Involve engineers early: explain decisions, probe feasibility, and scope effort
Balance expectations: weigh customer aspirations against implementation realities
Lean on social skills: handle critique, remain constructive, and negotiate cleanly
Strengthen technical fluency: code awareness leads to better choices
Use formal learning paths: HTL subjects and university courses can accelerate your ramp-up

For developers eyeing UX: why the move makes sense

Adzaga’s route shows that moving from development into UX is not only viable but often advantageous. Three insights stand out:

Technical experience is an asset. It makes you a credible partner for engineering and helps you design for the system you actually have.
Seize training opportunities—even if you need to “sneak in.” Exposure changes trajectories.
Ownership shapes the role. As the only UX designer, the job is end-to-end by definition—from requirement to shipped feature.

Quotes and ideas that stick

“You accompany projects from start to finish.”

“In technical refinement meetings you present drafts…”

“Design decisions need to be explained and argued.”

“Get everyone in the same boat: Product Owner, developers, customers, and, ideally, end users.”

“Just because you like a design doesn’t mean others will.”

“You have to be willing to compromise.”

“A technical background is practical.”

Together, these lines form a compass: UX is shared work, guided by openness, rationale, and balance.

Our takeaway from “Mateo Adzaga, UX Designer bei solvistas”

Mateo Adzaga’s devstory is a study in posture and practice. It shows how an individual can generate leverage inside a company: by seeking feedback consistently, looping in engineering and product early, moderating expectations with respect, and stepping into responsibility when opportunity appears.

That he moved from HTL to internship to part-time work to a UX helm is encouraging: entry points are diverse; what matters is how you use them. Bridging “the best possible design” and efficient implementation isn’t a side quest—it is the job.

If you’re pursuing a similar path, this session suggests a straightforward operating model: ask rather than wait, explain rather than enforce, and “sneak in” where learning is possible. The outcome is a UX process that respects people—customers, developers, and end users alike.

And that’s the enduring strength of this story: it shows how UX becomes lived collaboration. From the first requirement to the last iteration—and back again.

Session and company note

This recap refers to the session “Mateo Adzaga, UX Designer bei solvistas” with speaker Mateo Adzaga (Company: solvistas GmbH). All insights are based on the experiences and statements he shared in the session.

More Dev Stories