One short passage in the Vetrya profile explains a great deal about how the group wants its products to feel. At Vetrya, user experience comes before visual appearance. In the shorthand of design teams, UX comes before UI. Apps and digital products are built following Lean, Agile and design thinking methodologies, always keeping the people who will use them at the heart of the work. This article unpacks that passage and shows how a client can use the same priorities when briefing a design and development team.
The distinction between UX and UI is easy to state and hard to practice. UX is how a product works for a person from the first moment to the last: whether they understand it, whether they can finish what they came to do, and how they feel afterward. UI is how the product looks on the screen. Good UI supports good UX, and a handsome screen cannot rescue a confusing journey.
Why experience comes first
Teams that start with visual design often discover the problems late. A beautiful checkout page may hide a step that customers do not understand. A polished home screen may bury the one function people use every day. By then the design is approved, the budget is committed, and changes feel expensive.
Starting with experience reverses this. The first questions are about people and tasks. Who is the user? What are they trying to achieve? What do they already know? What gets in their way? Only when those answers are clear does the team decide how the product should look. The profile’s statement that UX comes before UI is a commitment to this order.
There is a business reason as well as a human one. A product that is easy to use gets used. It needs less support, produces fewer abandoned sessions and earns better reviews. The profile speaks of value that can be measured over time, and ease of use is one of the most direct ways to produce that kind of measurable value.
Three methods, one attitude
The profile names three methodologies: Lean, Agile and design thinking. They come from different traditions, but they share an attitude. Learn early, test with real people, and adjust.
Design thinking is a way of understanding people before solving their problems. It uses interviews, observation and simple prototypes to define the problem clearly. Teams move between understanding, imagining and testing, and they are comfortable discarding ideas that do not hold up. The method protects against building a solution for a problem that nobody has.
Lean thinking asks what is the smallest version of a product that can teach the team something real. Instead of building every feature, the team releases a focused version, observes how people use it, and decides what to build next from evidence. This reduces waste, because effort goes to features that matter. It also supports the group’s emphasis on speed and cost, since early learning is cheaper than late correction.
Agile delivery organizes the work in short cycles. At the end of each cycle there is something that works and can be reviewed. The client sees progress regularly, can change priorities and can catch misunderstandings while they are still small. Agile teams treat requirements as a conversation instead of a fixed document, which suits digital products where the best answer often appears only after people try a first version.
Together, the three methods form a loop. Understand the user, build a small version, release it, learn from use, and repeat. Each turn of the loop improves the product and the team’s knowledge of the people it serves.
Listening as the first deliverable
The profile says that every project starts by listening to the specific needs of the Client. The same attitude applies one level down, to the people who will use the finished product. Listening is not a preliminary courtesy. It is the first deliverable of a design project, and it produces material the rest of the work depends on.
In practice, listening can take several forms.
- Conversations with the client about goals, constraints and the measures that will show success.
- Interviews with end users about how they do the task today and where it frustrates them.
- Observation of real use, which often reveals habits that people forget to mention.
- Review of existing data, such as support questions and usage patterns, to find where the current experience breaks.
The output is a shared description of the users, the main journeys and the problems worth solving. When the team and the client agree on that description, later decisions about screens, features and priorities become easier to defend.
From research to screens and code
The services listed on the group’s site include UI/UX Design and App and Web App development. Seeing them side by side is useful, because it shows that design and engineering are meant to work as one flow rather than as separate stages.
A typical path looks like this. Research produces a set of journeys. Designers sketch the journeys as simple flows and test them with prototypes. Once a flow works, visual design gives it a clear and consistent look. Developers build it in short cycles, with design and engineering reviewing the result together. The product is released to a small group, measured, and improved.
This path avoids a common handoff problem, where designers deliver a finished set of screens that engineers then find hard to build. When both groups share the work from the beginning, they find constraints early. A feature that is costly to build can be simplified before the design is polished, and an engineering shortcut that would harm the experience can be questioned before it is coded.
Designing for the whole network of devices
The profile describes applying expertise to every device connected to the network. For design teams this means that the experience does not stop at one screen. A person may start a task on a phone, continue on a laptop and finish through a television or another connected device. They expect continuity and consistency.
Designing for this reality has a few practical consequences.
- Content and functions need a clear structure that can adapt to small and large screens.
- Interactions should work for touch, keyboard and remote controls where relevant.
- Performance matters as much as appearance, because a slow page feels like a broken page.
- Accessibility needs attention from the start, so that people with different abilities can use the product.
These points are less visible than a striking visual style, which is exactly why a UX-first approach pays attention to them. They determine whether the product works for everyone who needs it.
Measuring whether the experience works
A design that feels right to the team still needs proof. The profile’s idea of value that can be measured over time suggests a simple discipline. Decide before launch which measures show a good experience, and review them after launch.
Useful measures include the share of users who complete the main task, the time it takes, the number of support requests about it, and the satisfaction reported by users. Numbers should be read together with comments, because the numbers show where a problem is and the comments explain why it exists. When a measure moves in the wrong direction, the loop starts again with a new question and a new small change.
Questions to ask a design partner
A client choosing a partner can use the profile’s stated priorities as a list of questions.
- How will you learn about our users before designing screens?
- Which version of the product can we release first to learn from real use?
- How often will we see working results during the project?
- How will accessibility and performance be handled?
- Which measures will show whether the experience is improving?
Clear, specific answers show that the team practices the principle of putting people before appearance. Vague answers suggest that the phrase is only a slogan.
Common mistakes a UX-first approach avoids
Teams that put appearance first tend to repeat a small set of mistakes. Knowing them makes it easier to see why the profile treats the order of priorities as important.
- Designing for the team instead of the user. Screens that make sense to the people who built them can confuse everyone else. Research with real users replaces assumptions with evidence.
- Adding features instead of removing friction. A long list of functions can hide the one action people came to perform. A UX-first team asks which steps can be removed.
- Testing too late. When the first user test happens just before launch, every finding is expensive. Early prototypes move the same findings to a point where fixing them is cheap.
- Ignoring the slow connection. A design checked only on a fast office network may disappoint people on a mobile link. Performance belongs in the design from the start.
- Treating launch as the end. Real use always teaches something new. Without a plan to measure and improve, a product slowly drifts away from what people need.
Each of these mistakes is a failure to listen. The group’s habit of beginning every project with the specific needs of the client and the user is therefore a practical safeguard, and not only a statement of attitude. A team that listens first, tests early and keeps improving after launch avoids most of these problems before they appear.
