This same mentality is reflected in some managers who try to hire cheap agencies to execute design and development decisions they’ve already made, refusing to incorporate processes that could improve the quality of those decisions and avoid the most common outcome in software: failure.

Right now, somewhere in the world, there’s a purchasing manager pressuring an agency to design and develop “the App” almost at cost. Ignoring that, out of the more than 3 million apps published, the average user only has about 80 installed.

“The App” will join the 80% of apps that don’t reach 10,000 downloads and will be deleted by users the next time their phone storage is full: in other words, by the end of the month at the latest.

That’s not saving: it’s “investing” time, effort, and money to, in return, get a negative return.

The Value of a Good Investment in UX & IT Direction

Companies that seek cheap and quick solutions to execute ideas without expert direction or validation end up losing more than they gain.

Hiring agencies that can do UX and development at the lowest cost, selected by purchasing departments that negotiate aggressively, results in poorly conceived projects and products that don’t meet the real needs of users and will ultimately be ignored or, at best, resisted.

This “savings” strategy is actually a form of waste. Instead of building solutions that truly work, add value, and can aspire to market adoption, time and money are wasted on creating pretty and cheap screens that decision-makers like, but whose inevitable fate will be, sooner or later, to be discarded in favor of another project. Because in a competitive market, things are done right or they are done again.

Vision vs. Illusions

Many managers consider their ideas as a “vision” and designers and developers as mere laborers who need to be told what to do. But if that product vision expecting success is not informed by evidence, it will be nothing more than an illusion.

The problem is that having ideas (that we validate ourselves) is not the same as having offers (that customers validate). For a successful product, a “good” idea is not enough. It must be matured into a good offer. That is the function of Design as a strategic discipline: architecture instead of decoration.

An expert consultancy that applies mature processes of creativity and evidence-based decision-making is an excellent way to achieve that maturation. But often, decision-makers consider these services “expensive,” without knowing the risks they avoid or understanding the value they bring.

Because their opinions and decisions are based on the culturally ingrained idea that “saving” is buying cheap, rather than investing rationally.

Lean Philosophy and Goal-Oriented Design

There are various “schools” of design thinking.

Another, which understands Design as a project-based and strategic discipline following the definitions of Don Norman, ISO 9241 standards, and the Lean philosophy that helped rebuild the Japanese industry, is the one that truly delivers results — because that is precisely its focus.

This is our school of design thinking that drives UX Direction as a discipline to achieve functioning software, accepted and adopted by real users, and meeting business objectives.

For UX Direction, the question “How critical is good UX design for increasing usage and conversions?” is answered by definition: if UX design does not increase usage and conversions, it is not good.

The UX Direction school considers not only aesthetic factors but also recognizes critical success factors such as functionality, efficiency, and end-user satisfaction. It is a solid investment that, although it may seem more costly initially, results in successful, robust products that stand the test of time: investments that lead to true savings rather than sunk costs and technical debt.

Conclusion

Buying cheap things that are neither necessary nor will be used is not saving: it is wasting. The same applies to companies that hire cheap UX teams to execute projects that will not result in products accepted by end-users.

To truly save and achieve results, it is essential to invest in well-led and skilled UX teams and provide them with the resources and authority needed to do their job.

Only then can products be created that meet market needs and generate a positive return on investment.

The entry Buying cheap things you don’t need isn’t saving. Are you doing the same with your UX & IT procurement? was first published on Kambrica.

So… what is the difference between them? And why is it important to understand this difference?

Interface Design, or UI

Focuses on the artifact, or in other words, what is on the screen. When designing interfaces, the problem being solved is within the design: selecting and arranging interface elements (e.g., text and form fields), design consistency (with the platform, with other screens), etc.

It’s important to clarify that Interface Design is not the same as Graphic Design: interface design may or may not include graphic design. For example, when creating a wireframe, one is designing an interface but not applying graphic design, whereas applying style rules to an interface involves graphic design but not interface design.

UI focuses on the artifact. UX focuses on the user. IxD focuses on the interaction between the user and the artifact.

User Experience, or UX

Focuses on the user and the experience to be achieved. UX refers to what the user experiences before, during, and after interacting with the artifact.

Without incorporating the user, UX cannot be done. Therefore, it is essential in experience design to first understand the users and their true motivations and needs, consider what interface, content, and interactions will achieve the desired result from that perspective, and finally, validate with users the results produced by the proposed interface.

Validation can be done directly (user testing, qualitative interviews, mental model surveys) or indirectly (heat maps, A/B testing, click maps).

The difference between direct and indirect validation is not only methodological. Direct validation is usually qualitative, meaning it helps us understand why users do what they do, while indirect validation shows what they do but doesn’t explain why. Therefore, it is good to first validate the experience qualitatively as a “rough adjustment,” and then quantitatively for “fine-tuning.”

Interaction Design, or IxD

Involves defining how the interface operates (e.g., whether information input or selection occurs via keyboard, mouse, touch, or a combination of these), operational flows, and system responses. Ultimately, it focuses on the interaction between the user and the artifact.

Why is it important to understand the difference between UI, UX, and IxD?

Returning to the initial question, there are two answers:

• On one hand, to communicate clearly what we are doing and the scope we are addressing.
• On the other hand, to generate a common language with those making requests. If everyone understands that Interface Design (UI) does not necessarily imply User Experience (UX), we might be fortunate enough to avoid requests to “add UX to the screen”; and if we are not so fortunate, we will at least know how to ask the necessary questions to understand exactly what is being asked and help to reformulate the request based on the actual need.

The entry UI, UX, IxD: What’s the Difference? was first published on Kambrica.

The lack of standards in defining seniority is almost as widespread in our industry as the confusion between UX and UI. This affects everyone involved in professional discussions:

• Designers and researchers who need to prepare their resumes,
• Professionals who need to understand what skills they need to develop to advance their careers,
• Sales teams who need to present the team responsibly,
• Clients who need to evaluate and compare the different proposals they receive.

One of the first voices I encountered offering useful definitions within the software industry was Diego Salama. In a very clear article he published back in 2008, he detailed what he considers to be the main differences between a Junior, Mid-Level, and Senior programmer.

His definitions have not only stood the test of time but have also had… what you might call replicas. The axes Diego proposed, which are perfectly applicable to UX and to which I add the Consultant level (along with other additions of mine, in italics), are:

Work Experience

Years of work experience in the field, excluding practical work or work in other activities.

• Junior: Less than 2 years of experience.
• Mid-Level: At least 2 to 6 years of experience.
• Senior: At least 6 years of experience.
• Consultant: At least 10 years of experience.

The number of years in the field is, of course, just one dimension. Therefore, I use “at least” in all cases.

Malcolm Gladwell’s simplification that investing 10,000 hours in a field is the differentiating factor has been widely criticized, even by the original author of the metric, as a simplification. The value of Diego Salama’s criteria lies in the additional dimensions, which reveal that a person may have Senior characteristics in one aspect and Junior characteristics in another:

Technical Knowledge

Tools, paradigms, etc., required to perform their tasks.

• Junior: Often requires guidance.
• Mid-Level: Technically self-sufficient.
• Senior: Technical reference within the team.
• Consultant: Technical reference for their professional community.

Functional Knowledge

Methodologies, standards, processes required to perform their tasks.

• Junior: Does not know all processes or standards.
• Mid-Level: Manages processes sufficiently to perform well. Adheres to standards and methodologies.
• Senior: Helps define processes, methodologies, standards, and procedures. Of course, adheres to existing ones.
• Consultant: Technical and strategic referent, capable of creating new methodologies and always seeking to improve existing ones.

Proactivity

Indicates whether the person waits for tasks to be assigned or takes a more initiative-driven approach.

• Junior: Frequently needs task definitions. Waits for the next request. When free, doesn’t know what to do next. Depends on others to advance with their tasks.
• Mid-Level: Concerned with using their time well. Requests new assignments when available and is self-sufficient to handle a significant part of their tasks.
• Senior: Not only receives requests but also seeks and generates them. Often creates new assignments for their superior.
• Consultant: Creates goals and requirements not only for their team but also for their client.

Required Supervision

Attention needed from their immediate superior.

• Junior: Requires detailed daily supervision.
• Mid-Level: Requires weekly and general supervision.
• Senior: Proactively reports the status and progress of their tasks.
• Consultant: Provides vision for the team and outlines the direction for supervision.

Productivity Indicators

Various indicators related to the work performed.

• Junior: Quality: Low/Medium; Productivity: Low/Medium; Innovation: Little or None.
• Mid-Level: Quality: Medium; Productivity: Medium; Innovation: Limited.
• Senior: Quality: High; Productivity: High; Innovation: Medium/High. (Here Diego jumps from “little” for Mid-Level to “high” for Senior. Having an additional level allows for better differentiation.).
• Consultant: Higher seniority translates not only into high or very high quality, productivity, and innovation but also into advancing the team to new areas. A Consultant’s focus is no longer on correct execution but on the strategic question of what is being done. A Consultant is distinguished not by working faster than a Senior but by achieving greater value in their questions and decisions.

Meeting Deadlines

Adherence to scheduled delivery dates.

It’s important to clarify that a professional cannot take another person’s estimates, whether from a team member or the client. It is the professional’s responsibility to make estimates and commit to them.

• Junior: Most of the time, does not meet estimates.
• Mid-Level: Sometimes meets, sometimes does not.
• Senior: When deviations arise (inevitably), reports them adequately and in advance.
• Consultant: Responsible for prioritizing and meeting deadlines for the entire team; when an inevitable deviation arises, helps others overcome it and meet deadlines.

Response Under Pressure

Refers to extreme situations… not the weekly rush.

• Junior: Becomes blocked, anxious, confused, stressed under pressure… The outcome of their work under pressure is not good.
• Mid-Level: Gets angry, defensive, distant, resigned under pressure… The outcome of their work under pressure, despite everything, is good.
• Senior: Gets enthusiastic, committed, takes charge, inspires and inspires others under pressure… The outcome of their work under pressure can be outstanding.
• Consultant: Has the ability to anticipate risks and pressure factors, maintain calm, and help find the way, turning such situations into experiences that strengthen the team.

Interpersonal Skills

The ability to communicate with their environment (mentioned by Javier Scavino).

• Junior: May have difficulty clearly communicating their ideas. Struggles to reach actionable conclusions. Does not always know how to interact collaboratively and professionally with others.
• Mid-Level: Can be understood but does not earn the sympathy or inspire the commitment of collaborators to support their suggestions. Listens to other points of view but continues to push for their own ideas (good and bad) to prevail.
• Senior: Good at communicating, but mainly at listening. Can participate in high-level decisions and contribute to more operational activities if necessary, prioritizing the outcome and the quality of relationships over their authorship of ideas.
• Consultant: Uses mentoring and coaching tools to develop the team and stakeholders, facilitates projects as a co-creation process, focuses on continuous improvement in relationships and results.

UX Dimensions

Regarding the dimensions proposed by Diego, I consider the following for our discipline:

Observation Hours

A fundamental characteristic that distinguishes UX practice from interface design (UI) is the observation of users in context by all project participants, a dimension documented by Jared Spool in 2011 and Jakob Nielsen in 2014.

• By definition, a Junior professional at the start of their career, will have zero direct observation hours accumulated.
• A Mid-Level will be within the minimum proposed by Jared Spool: 2 hours every no more than 6 weeks (approximately 16 hours a year).
• A Senior will be working towards the goals proposed by Jakob Nielsen for their role: between 50 hours annually (for UI design) and 200 (UX researcher).
• A Consultant meets or exceeds the goals proposed for their role.

Perhaps this variable is the clearest way to differentiate those who focus on informing and making design decisions based on what users experience (UX) from those who (often with great artistry and the best intentions) are on a different path: executing design decisions already made by clients.

What happens when it is revealed that a professional who considers themselves a Senior UX Designer (with a capital letter) has accumulated many fewer hours than would be typical for their level (or none)? Clearly, this is a symptom that their work experience is not occurring within the field. If this is your case, you might be interested in joining our team – or any other where your work is not only rewarded but also an investment in your career.

Business Knowledge

In his model, Diego includes business knowledge under Functional Knowledge. At least for UX, I find it more appropriate to distinguish Business Knowledge as its own dimension, following Andrés Rodríguez’s OpenUP/MMU-ISO model, which separates the domain leader role.

• Junior: Focus and daily challenges are more on the formal aspects of execution than on the validity of the solution for the Business.
• Mid-Level: Understands much of the business processes.
• Senior: Relies on business knowledge to inform and achieve good design decisions.
• Consultant: Their domain knowledge allows them to help clients make better business decisions.

Utilitas, Firmitas, Venustas

To address aspects specific to design disciplines, I find very interesting the classic triad sprouted twenty centuries ago from Vitruvius’s architectural treatise.

These criteria apply even more when discussing UX, where establishing metrics in design, usability, and business dimensions is central:

• Utilitas (Utility): Has the professional’s work fulfilled its intended function?
  A Junior’s work will struggle to meet this criterion. A Mid-Level should achieve a solution adequate to the project’s definition.
  A Senior’s work should also be adaptable to new needs without demolishing what was built.
  A Consultant can be identified by their ability to foresee situations not initially considered… but whose satisfaction years later becomes a pattern for the industry.
• Firmitas (Robustness): In UX, this translates to the formal consistency of deliverables.
  A Junior designer will produce pieces where definitions that should be identical (measurements, colors) differ in minor ways when compared. A Junior researcher will generate metrics difficult or impossible to compare throughout the project.
  A Mid-Level professional shows high consistency in their deliverables. A Senior’s work is noted for its impeccable quality. A Consultant’s work is a reference beyond the project.
• Venustas (Beauty): To what extent have formal aspects withstood the test of time?
  A Junior will show quirks and hesitations typical of their current learning stage, potentially struggling to achieve a satisfactory level even at the moment the work is completed.
  A Mid-Level can handle contemporary language. A Senior creates work that endures over time. A Consultant anticipates future trends.

These three classic dimensions can only be evaluated over time. Just like a professional career.

It’s not a coincidence :)

Santiago Bustelo

The entry Understanding UX Seniority Levels was first published on Kambrica.

When we consider integrating User Experience (UX) and Agile Methodologies, our framing conditions us to think that once we identify the intersection point, we’ll have all the answers we need.

This would be correct and sufficient, if we had not had disagreements before the advent of agile methodologies. It would apply if we had been working smoothly until the Agile Manifesto was published in 2001; however, the reality is more complex.

Agile methodologies are often proposed or imposed by engineering, and here we see that the “agile methodologies” universe consists of two dimensions: Engineering and Management. The relationship between Design and Engineering has been problematic not just since 2001, but for ages: architects and engineers have been criticizing each other for centuries.

The first step towards healthy collaboration is resolving the relationship between Design and Engineering. For that, I really like this definition that I knew from Bret Victor: “Technology satisfies human needs by amplifying human capabilities”.

This definition is revealing in several ways. First: Without people, there is no technology. Second, it clarifies that Engineering focuses on functional aspects that address the problem… while Design ensures that the solution fits the user by understanding their needs and capabilities. Technology is not limited to the mechanical; it’s not something engineers invent and designers merely color. Without Design, there is no technology—only technical curiosities.

To incorporate Design into the process, I find three critical questions useful: What problem are we solving? For whom(s)? And how will we know we’ve succeeded? These questions allow us to integrate the three areas of the problem in a single conversation: Engineering, Design, and Management

When discussing Management, it’s essential to understand what a Methodology is: a framework for organizing a process that involves people. The key takeaway from this definition is that it reveals what a Methodology does not encompass.

A methodology does not replace people (involved in the process), conversations (tool to share vision of the future and coordinate actions), nor to decision making. Choosing a methodology is, in itself, a decision.

A methodology cannot prescribe decisions, just as traffic rules (e.g., “drive on the right”) cannot dictate where to go; they can only provide the organization needed to reach the destination while minimizing the risk of accidents.

Decision-making is a fundamental part of Design and the most significant value it brings to the process. It’s common for those who hire us to view Design solely in terms of execution, making “pretty” the design decisions previously made by Engineering and Business (often without understanding what a design decision entails).

As designers, it’s our responsibility to make the right distinctions, ensuring that we help Engineering and Business make better decisions.

As designers, we must make the right distinctions, proposing and delivering on the promise of helping Engineering and Business make better decisions, to the point where design decisions inform the business decisions they should be based on.

When Design is viewed merely as execution, a project may seem more or less complex based on the “number of screens” to be produced—or any other quantifiable deliverable.

At Kambrica, we’ve found that the complexity of Design can be more appropriately understood as a product of the complexity of the execution due to the complexity of the decisions. This model allows us to clearly demonstrate the necessary role of UX in facilitating stakeholders’ decision-making processes and providing information to make them evidence-based.

Another important distinction is the common misuse of the term Agile. Particularly in Business, there is interest in adopting agile methodologies due to the idea of speed.

The reality is that speed is not part of the agile manifesto’s principles: what they propose is responsiveness to change rather than clinging to a plan. In other words, agile is the skier who dodges obstacles and reaches the finish line; rushed is the one who ends up in the hospital.

The rushed skier throws themselves toward the goal in an act of faith, driven by anxiety. The agile skier considers the terrain’s evidence in a constant decision-making process: a cycle of observation, orientation, decision, and action.

In a project, UX research provides the evidence-based information necessary for decision making. However, it’s often dismissed with the excuse that “it’s slow,” which is another way of saying, “there’s no time.” But time isn’t something that can be stored in a drawer.

Time is something to be allocated. What does “no time” really mean? Suppose someone goes to a ski resort, asks for skis, and when the attendant asks their size, the customer says, “I don’t have time to put on boots; I just want the skis.” What he means is that he does not understand boots as a necessary condition for using skis.

UX professionals need to learn to hear “no time” not as an inflexible rejection, but as an invitation to point out the necessary condition between our proposal and what our client needs.

In our client’s decision making process, there is a balance with two trays: one with what they don’t want, present or future problems, their fears; and the other with what they want, the future they want to be part of, their desire.

Addressing concerns is critical to getting attention: anything we propose before satisfying that point will be ignored or misunderstood, to the point that instead of being seen as part of the solution, it may be viewed as additional problems weighing down the fear tray.

This approach helps address the common request for quantitative techniques, even when we find they contribute little or nothing to understanding and solving the problem. The reason for this request is that the clients who make it, need something to present to their superiors: they are being measured. These interlocutors’ main concern is not aligned with design quality; it’s focused on their survival within the organization.

In these cases, quantitative research should be presented as a necessary condition for achieving a quantification that our clients will find positive. This means recognizing metrics that can show increasing measures throughout the project. I distinguish three levels in quantitative research:

• Validation (checking what “we know we know”) is the simplest qualitative process, the least risky, and the one most feasible to establish quantitative metrics for.
• Investigation (searching for what “we know we don’t know”) involves greater uncertainty and is only viable once our client has understood the value of UX in reducing risks, typically after validating assumptions that were initially presented as truths.
• Exploration (searching for what we don’t know we don’t know) is the qualitative process furthest from the client’s concern for their organizational survival; it’s only viable when our client has resources, political capital, experience, and commitment.

Only with solid tools for conversations and decision-making can we focus on designing a methodology.

The most important goal of any methodology is to achieve a healthy client-provider relationship on the project scale. Without any methodology, as more people join from both sides, cross-conversations, confusion, and problems arise, leading to the formation of two camps: “those jerks” and “that bunch of useless people”.

That’s why every methodology proposes a single interlocutor on each side, with authority, technical competence, business understanding and management skills.

A critical foundation for agile methodologies is the Lean philosophy’s Value vs. Waste distinction. Value is what the Client values; waste is everything else… even things we consider necessary conditions for achieving Value.

Identifying waste forces us to question all the activities we undertake. In the case of building a house, the walls –providing protection from the elements and preserving privacy– are clearly a Value. However, scaffolding, though considered necessary for building those walls, are actually construction waste: the inhabitants won’t live with the scaffolding once the building is inaugurated. If the scaffolding were made of gold, the budget would increase by several million dollars, without the end clients finding any Value in it. That’s why scaffolding are modular, reusable, and in many cases, rented.

Other types of waste can be more straightforward to identify. If materials are unloaded 10 blocks away from where they are needed instead of at the right spot, additional time and effort will be required to move them where they should have been unloaded initially.

Identifying waste in software is much more difficult. Lean Software Development is a valuable tool for identifying, reducing, and eliminating waste in our projects:

Product Waste:
These are the most obvious… but also the latest to be identified. They become evident once the project is in production… and therefore, when there are no longer resources to resolve them. UX research aims to identify these wastes economically, in a controlled environment, when there is still time and resources to mitigate them:

• Defects: bugs, things that don’t work according to the end user’s expectations, usability issues.
• Unused Functionality: typically, the result of a lack of understanding of users’ real needs and capabilities.

Process Waste:
These can be identified and addressed during the process itself. Addressing them reduces the likelihood of product waste manifestation. They require management skills, team responsibility, and Client expectation management:

• Hand-offs: When a task is passed from one person to another, there is either a necessary conversation between those people, or information is lost in the process.
• Multitasking: Humans can consciously perform only one task at a time; “multitasking” is actually interleaving fragments of two or more tasks. Switching from task A to task B requires an effort greater than zero to understand the context of the second task; this penalty applies again when returning to task A.
• Relearning: Returning to a task or practice after a long time requires effort to regain context and operational capability, which can be avoided by maintaining continuity.
• Waiting: This occurs when someone cannot proceed with their assigned tasks due to a lack of decisions or inputs they depend on. One way to avoid these situations is by managing a “sprint” schedule that imposes cadence on the project and must involve the Client.
• Incomplete work: All unfinished decisions and executions increase technical debt to the point where the cost of settling it in the future may become unfeasible. It is often the result of project haste and pressure, lack of planning, and vision.
• Unused talent: One common scenario is when the Client considers Design to be mere execution, overlooking the team’s ability to help the Business make better decisions. It requires management, authority, expectation management, and commitments. This impacts the project in ways that cannot be quantified (no one can measure against what “could have been”) and affects the team in terms of motivation breaks.

At Kambrica, we developed, iterated, and proposed a model that first recognizes the value of Facilitation and Research processes in reducing the complexity of decision making. It reveals that design execution, far from “solving” (as is often the client’s perception), actually always opens up new questions that require appropriate processes for their resolution.

Our minimum sprint model considers weekly cycles, with a Management track running one week ahead of the execution track. During the Planning phase, the two tracks overlap, also including a mid-week follow-up instance with the Business to reduce risks and deviations.

By applying this model, we successfully coordinate all projects, regardless of their complexity.

In summary, integrating User Experience and agile methodologies requires working across several dimensions, from general to specific: from the understanding of Design, Engineering, and Management, to the design and application of a particular methodology to guide projects by identifying and reducing waste, and establishing and fulfilling commitments responsibly.

The Measure of Design 2018: Slow Methods in agile times – IxDA Viña del Mar

The event featured Mauricio Azócar (Agile Coach at Tinet), Estefanía Cotrini (Project Manager at Ilógica), and Santiago Bustelo (Founder and UX Director at Kambrica).

The digital service design industry increasingly relies on agile methodologies, which have brought new ways of working, with different rhythms and goals that have proven to contribute to efficiency and transparency in design and development processes. However, many agile methodologies like Scrum, Agile, or Lean were created from development, and therefore do not initially consider the relevance of the role of design in the experience, its teams, or its methods.

In this context, IxDA Viña del Mar raised the following questions: What is the role of “slow methods” inherent to UCD and research in the agile times we are in? How does each type of methodology address the user experience? What external, human, or other factors favor or hinder the development of processes under each methodology?

Many thanks to Nicolás Espinoza, Katherine Exss, and the entire team and volunteers at IxDA Viña del Mar for the invitation, the excellent reception, and the effort to make everything possible!

Presentation Credits

• Framing hammer – Luigi Zanasi (CC BY-SA 2.0 ca)
• Iceberg in the Arctic with its underside exposed – AWeith (CC BY-SA 4.0)

All other images and videos under CC0 License (Free for any use without attribution required), public domain, or self-produced.

The entry Agile Methodologies as a Design Challenge was first published on Kambrica.