how do i find a good agency for ux and ui design?
a good ux/ui agency makes complex tasks easy to understand and designs a consistent user experience. ux refers to the user experience; ui refers to the actual user interface. when choosing an agency, it’s important to consider whether it integrates both aspects and bases its decisions on user tasks rather than solely on visual preferences.
scope of services and delimitation
ux design examines and shapes the user experience; ui design brings the user interface to life. these two tasks are intertwined. a good agency can explain how research findings are transformed into workflows and, ultimately, into visible components. that’s why a portfolio consisting solely of screen shots isn’t enough to make a decision. ask about the problem behind the design and how it was validated.
the scope of the project may involve a single critical workflow or an entire application. different roles, end devices, and environments are also important. accessibility must be taken into account and addressed through appropriate functional and technical testing. a visual redesign alone does not guarantee full accessibility.
comprehensible processes require clear statuses
an interface must show what is currently happening and what action can be taken next. the main screens alone are not enough for this. error messages, loading states, and navigation paths are all part of the task. therefore, have them explain the entire workflow. this will help you determine whether the agency is developing coherent interactions or primarily producing attractive individual screens.
four criteria for choosing a partner
- understand user tasks: ask about research and how insights are translated into concrete processes.
- testing prototypes: a partner should explain what level of realism is necessary for the current question.
- include accessibility: user interfaces and information must take into account relevant differences in abilities. accessibility also encompasses technical implementation.
- planning the handoff: components, states, and behaviors should be documented in such a way that the development team can implement them consistently.
compare performance and work results
| task | possible outcome of the work | that’s how it’s assessed |
|---|---|---|
| ux analysis | prioritized usage issues and processes | observations rather than mere judgments of taste |
| ui system | component states and application rules | application with real-world content |
| implementation | fine-tuned details and tested interactions | comparison with the actual surface area developed |
project process and decisions
start with the most important tasks and existing problems. test the information architecture and workflows using simple prototypes. next, develop the visual system using reusable components. during implementation, the design team should test the actual application. a final comparison between the design and the implementation will show whether key interactions have been preserved.
example of a form with unclear errors
suppose people fill out a form and only receive a confusing error message at the end. a cleaner layout can improve the user experience, but it doesn’t automatically solve the problem. what matters is when specific information is needed and how users can still make corrections.
a design comparison examines prompts, error messages, and the path back to the relevant input field. tests show whether users can continue the task without additional explanation. this hypothetical example illustrates the interplay between ux and ui: structure, behavior, and visual hierarchy all contribute to the solution.
common mistakes in selection and contracting
be wary of concepts that only show ideal scenarios. errors, lengthy content, and missing data are also part of the user experience. another weakness is evaluation based solely on the personal preferences of internal decision-makers. ask for appropriate use cases and relevant test subjects. when a design system is delivered, it should include actual rules for its application. a library of beautiful components is of little help if it remains unclear when and how they should be used.
compare costs and schedules effectively
costs and duration depend on the number of processes and states, user research, and the depth of the design system. list research, development, prototypes, and external expert services separately. also, specify which revision cycles are included and who approves feedback. a schedule is only meaningful once these decisions and dependencies are known.
the briefing for an initial meeting
specify key tasks, user groups, and existing pain points. supplement existing brand and component guidelines as well as technical constraints. provide real-world example content and relevant scenarios. list available developer and user contacts. specify whether the scope includes research, prototype testing, visual detailing, and implementation review. this distinction makes proposals more meaningful than simply listing the number of planned screens.
frequently asked questions about ux and ui design
why should authentic content be introduced early on?
long labels, missing images, or large amounts of data can affect a layout differently than placeholders. real-world examples reveal these limitations early on. therefore, test typical and challenging content before finalizing components and spacing.
what is included in a design system?
depending on the product: components, states, design rules, and usage guidelines. the value comes from the fact that the team and the development process can actually use these rules.
can a user test fully confirm accessibility?
no. user involvement and technical requirements testing complement each other. a single assessment does not cover every ability and assistive technology.
how much does a ux/ui project cost?
key drivers include the scope of work, user research, and the state and depth of the design system. the number of screens alone does not fully reflect this complexity. therefore, compare research, prototyping, testing, detailing, and implementation support separately, as well as the underlying assumptions for each.
can you improve ux without redesigning everything?
yes. a targeted review can identify the most significant obstacles and lay the groundwork for limited improvements. start by examining these within the affected process. a complete redesign only makes sense if the problems or product goals justify a correspondingly larger-scale intervention.
what should be included in the handoff to developers?
in addition to views, this includes states, interaction rules, components, and real-world example content. any unclear details should be clarified together before implementation. a subsequent review helps identify discrepancies; however, responsibility for the technical implementation must still be explicitly assigned.
the perspective of f/p design
user journeys, wireframes, and early prototypes are part of our ux/ui process. we first discuss the relevant tasks and use that to determine which workflows should be reviewed and which components should be developed.
are you planning a project in this area? talk to f/p design about your project, its current status, and your desired outcome. together, we’ll determine the right design approach and the next steps.
related reading: the norman door and understandable actions, audible feedback and system status, gestalt psychology and perception
