Kambrica brought us significant value by helping us put ourselves in our customers’ shoes and incorporate UX logic into the transformation of how we deliver our services.

Value Proposition Manager

Multinational insurance and financial services company

* This project is presented in anonymized form under corporate confidentiality agreements.

When a project enters a meeting and exits as a budget-burning machine

When a corporate organization starts a digital initiative, the problem enters a meeting and exits transformed into a large structure of resources, platforms, and months of development. Not because it is necessary, but because industry incentives are aligned that way.

Software factories are rewarded for project growth: more teams, more hours, more complexity. Never less.

In this case, the organization entered discussions with a predefined conclusion: “we need an App”. Users were calling to check information about financial products and were not using the existing website, which was perceived as “outdated”.

Agency sales teams responded as expected: “Of course you need an App!” iPhone, Android, tablets. Modern backend, QA, DevOps, multiple squads, and several months of execution. Within minutes, an idea became a 12–14 person team.

We did something different: we reduced the problem before scaling the structure. Because executing quickly on the first interpretation of a problem is not agility: it is waste at high speed. Avoiding it took just one hour.

One meeting is enough to untangle the project

Using our XDM (Experience Decision Making) methodology, we separated three layers that are usually mixed from the start: facts, interpretations, and proposed solutions.

That analysis revealed a critical data point nobody had considered: user consultation frequency ranged between six months and two years. This alone invalidated the “App” hypothesis. The data showed that users would typically be prompted to delete unused apps long before they needed ours again.

The project therefore required an initial phase of strategic UX research to understand why users rejected the website and preferred calling. Without that, any initiative would have been guesswork.

The client believed the site was “old” and “ugly”. That may have been true. But the real answers were in front of the screens.

While the UI lives inside the screens, UX is what happens in front of them.

This focus led to a two-week research phase that uncovered the core issue: the website exposed less than half of the information users needed to make decisions. That is why they called.

The interface was not failing for technological or aesthetic reasons. It was failing because it did not answer the questions users actually had.

Something no agency had attempted to address, perpetuating the typical RFP trap. After 4–6 months, the client would have received exactly what was requested—but not what was actually needed.

Reducing complexity and uncertainty before execution starts

Our methodology is based on a simple fact: large projects do not fail due to technical limitations. They fail because complexity is only surfaced once the system is already in motion.

That is why we reduce UX, institutional, and technical complexity from the very beginning.

Because true agility is not executing quickly on the first plan that seems reasonable. It is having the flexibility to change direction when new evidence emerges.

1. UX complexity: the gap between business and people

We map real decision-making processes, identifying what information users need, how they interpret it, and what alternative channels they use to complete their goals.

This allows us to redefine information architecture, visualization rules, and product priorities before UI and development decisions harden.

2. Institutional complexity: politics and alignment

In corporate environments, most friction appears late in the process when branding, marketing, compliance, and stakeholder reviews start rejecting already-built solutions.

We address this from day one by mapping all affected stakeholders and involving them early in parallel tracks, removing risks such as internal inconsistencies before they impact delivery.

The result: no political rework cycles and no endless approval loops.

3. Technical complexity: feasibility

In Banking, Finance, and Insurance, legacy systems introduce a critical layer of constraints that must be addressed early. In this case, the volume of financial data created latency patterns incompatible with the required user experience.

We built an intelligent, backend-agnostic frontend layer capable of reusing previously fetched data, minimizing roundtrips, and enabling progressive loading without blocking navigation.

This allowed us to solve performance without degrading experience or adding unnecessary architectural complexity.

Results

While agencies proposed large and expensive structures to “fulfill the request”, Kambrica exceeded the objectives with a smaller team, strategic focus, and clear direction.

Because our incentives are not aligned with staffing or billable hours, but with solving the right problem.

In this case, the project did not require an App or a cutting-edge platform. It required understanding what was broken between the organization and its customers.

Without diagnosis and direction, speed only scales misunderstanding.

Most organizations do not need more velocity.
They need better diagnosis before scaling structure, budget, and complexity. That is what we do.

If you are responsible for the success of products or projects and suspect the problem is being misinterpreted, let’s talk.

We can help you see it before cost, complexity, and political risk continue to grow.

The entry Banking, Finance & Insurance was first published on Kambrica.

Everyone benefits when the project grows.
No one benefits from questioning whether the project makes sense.

This is why there are so many providers that take orders, never push back, and “move fast with efficiency”.

When the system finally isn’t used, nobody adopts it, or the business doesn’t improve, the sunk cost stays inside the organization. Everyone else already got paid. With misaligned incentives, not correcting your client when they’re wrong is simply good business.

Most software projects fail.
But not for technical reasons.

They fail because of poorly framed decisions, unvalidated assumptions, and the absence of professional judgment at critical moments.

Each failure is perceived as a one-off case.
But it isn’t bad luck. It’s a pattern.
And it’s entirely preventable.

In mature industries, technical authority implies responsibility for outcomes. That is the original meaning of professional consulting: expert advice to enable better decisions — not supplying hands to execute decisions that were already made.

Software factories sell formulas because formulas scale. Staffing agencies sell hours because hours scale. Platforms sell usage because usage scales. None of that guarantees results.

Strategic direction does.

It starts with a brief diagnostic session.

When an organization needs to reassess a project’s direction, validate assumptions, or reduce risk before investing further, this session helps analyze the situation and determine whether moving forward makes sense.

If you have authority over projects, tell us about your situation. If we believe we can truly help, we’ll schedule the meeting.

Share

If this pattern feels familiar, someone else in the organization should probably see it too.

The entry In software, the greatest threat isn’t technical. It’s the incentive structure. was first published on Kambrica.

Technology doesn’t happen on its own.
Technology has no purpose without users.

The only way for user experience to not exist is if there are no users.

And without users, without value, without purpose, there will be no technology — only technical curiosities.

So, for the actual AI technology — the one that involves users — who do you think is and will be in charge of modeling the AI personality and manners?

Regardless of the title they come up with for that… it will still be UX.

The entry AI, and specifically conversational interfaces, don’t and won’t “kill UX”. was first published on Kambrica.

During the UX Connect 24 event, he presented a course summary, emphasizing the frameworks and skills necessary to achieve better projects and relationships.

Course Syllabus

Module 1: Definitions and fundamentals

• What is Strategy and what is UX Strategy
• Lean Thinking: directing UX towards Value
• Agility in UX
• XDM: UX from decision theory
• Components of a UX Strategy
  • Direction, resources, and context
  • Vision
  • Objectives and metrics
  • Planning

Module 2: Strategic competencies

• Leadership
• Emotional intelligence
• Linguistic acts and agreement definition
• Rhetoric and persuasion
• Influence and negotiation
• Conflict management
• Effective delegation
• Rational decision making models
• Management and prioritization tools

Module 3: UX strategy in projects

• Project anatomy
• Objectives vs. Requirements vs. Desires
• XDM: Managing complexity and decision levels
• Iteration anatomy
• Integrating UX and Development processes
• Facilitating decisions with IT & Business
• How to present design
• UX Research informing strategic decisions

Module 4: UX Strategy in the Organization

• Cómo entiende a UX el Negocio
• El lenguaje del Negocio: terminología básica para UX
• Análisis, gestión y estrategia de Producto
• Madurez y valor del Diseño en la organización
• Formando equipos y escalando UX en la organización
• How the Business understands UX
• The language of Business: basic terminology for UX
• Product Analysis, Management, and Strategy
• Design maturity and value in the organization
• Forming teams and scaling UX in the organization

“Requirements” are not the starting point of design; they are its outcome.

Bustelo’s talk highlighted essential distinctions to avoid common pitfalls, starting with the myth of so-called “requirements.”

Projects often operate under the assumption that “the client knows what they want.” This is a fallacy. In reality, no one truly knows what they want: hence the need for analysts. Yet, this fantasy often crystallizes into “requirements,” condemning all subsequent definitions.

A requirement is a description of a visible functionality or attribute. What we can call “design requirements”, such as a style guide or a Design System, are not the product of what the client requests. They are the result of a design process, driven by design decisions. These decisions should be supported by business decisions – the true domain of the client.

The concept of “requirement” originates from development methodologies, starting with the “Waterfall method,” whose first formal description in 1970 pointed out its ineffectiveness.

What are often called “Development methodologies” focus on execution processes. They do not consider where the requirements come from, nor neither offer tools to evaluate their validity. This is the domain of UX Research.

The UX design process doesn’t start with so-called “requirements.” It begins with defining objectives and outcomes. The result of the design process is the specifications that the development team needs.

FrAgile methodologies

Las metodologías ágiles, nacidas para dejar atrás el dogmatismo, fueron adoptadas por el Negocio… de manera dogmática. Y confundiendo la “agilidad” con “velocidad”. O más precisamente, con “apuro”.

Agile methodologies, created to move beyond dogmatism, were adopted by business in a dogmatic way, confusing “agility” with “speed” or more precisely, “haste.”

Here are some distinctions to better focus discussions:

• “Agility” fundamentally refers to “responsiveness to change” versus “sticking to a plan.” We can call this ability “being adaptable.”
• “Agile” is, for example, the olympic skier who dodges obstacles and reaches the finish line.
• “Hurried” is the skier who ends up in the hospital.
• No one can deny that hurried people make mistakes.
• And I add: people who build software in a hurry, make mistakes that software multiplies.

Focusing the project on outcomes

It is essential the critical distinction made by Josh Seiden between output (deliverable) and outcome: a measurable change in behavior that drives business results.

While the visible part of our work may be pixels, screens, wireframes, mockups, etc., that is not our focus. As Robert Fabricant defined in 2008: “Our medium is behavior”.

Focusing our projects strategically (rather than merely executing tasks) requires answering these questions:

• Objectives: What problem, for whom, are we trying to solve
• Outcomes: What behaviors, from whom, need to change?
• Validation: How will we know if we’ve succeeded?

Influence

Given the amount of confusion that precedes our involvement in a project, often spread by sponsors or stakeholders – that is, the people with authority to give the project the political and financial support without which it cannot exist -, we can only help our clients achieve better projects that involve us, by developing competencies in influence and negotiation.

Influence is defined as the ability to enter the decision making process of others, without relying on authority. This can be summarized in three stages:

1. Entering the other’s acceptance space: active listening, empathy development, and initiating relationship-building.
2. Entering their decision making process: applying Experience Decision Making, a model that adapts decision theory to the UX process.
3. Building commitment: requiring responsibility and, above all, knowing how to say “no” in a responsible and professional manner to things we cannot or do not want to commit to.

Knowing how to say “no” is essential for maintaining our identity and integrity. Doing so professionally requires overcoming ineffective approaches:

• Accommodate: saying “yes” when we want to say “no,” out of guilt.
• Attack: saying “no” poorly, out of anger.
• Avoid: saying nothing at all, out of fear.

Negotiation expert William Ury proposes in “The Power of a Positive No” a three-step approach:

1. Reaffirming our principles and commitments.
2. Declaring that due to our principles and commitments, we cannot accept the proposal.
3. Affirming the relationship and building a new proposal for mutual benefit.

Some examples are, when faced with a request presented as an urgency resulting from ignorance and anxiety, clarifying that “What you are asking of me is the result of a process.”
Or, as Juan Carlos Lucas explains: “Having ideas is not the same as having offers. We value our ideas ourselves and they may seem great to us, but the offers are valued by others”. From this perspective, our professional identity is not in executing the client’s ideas: but in helping them have good offers for their customers.

Un proyecto es un tejido de conversaciones. La calidad de nuestros proyectos y relaciones, depende de la calidad de nuestras conversaciones. Por ello, los profesionales tenemos que ser impecables con nuestras palabras.

Si “el problema más grande del mundo se podría haber resuelto cuando era pequeño”, de cada proyecto malogrado podemos preguntarnos en dónde surgió la confusión que llevó al gran problema.

A project is a fabric of conversations. The quality of our projects and relationships depends on the quality of our conversations. Therefore, professionals must be impeccable with their words.

If “the world’s biggest problem could have been solved when it was small,” for every failed project we can ask ourselves where the confusion that led to the big problem arose.

And we can also adopt a coaching tool with our interlocutors: when we are bogged down in confusion, recognize that a conversation was missing.

The entry Santiago Bustelo presents UX Strategy at UX Connect 24 was first published on Kambrica.

It might be that the ones who redo it and get it right are not us… but our competitor, learning from our mistakes.
Therefore, it’s always better to do things right from the beginning.

Despite it being so simple and even obvious to invest in quality, the usual focus is on being quick and cheap.

As a result:

• Rushed people make mistakes.
• People who build technology in a rush make mistakes that technology multiplies.
• Mistakes can be learned from, but only if there’s the capacity to analyze them — which is impossible if we remain in a rush and, worse yet, under increasing pressure from accumulating errors. Any learning opportunity will be left for the competition.
• To make matters worse, our inability to recognize and correct our mistakes will crystallize as sunk cost and technical debt, hindering all future progress. The competition, however, will have a clear path.

In a competitive industry, if we are not the example, we are the warning.

Replacing purpose with urgency results in business suicide: enlightening the competitors, handing them the business on a silver platter, and multiplying all the investment in development and advertising by zero.

Some Exemplary Cases:

MySpace (2007): MySpace prioritized rapid growth without adequately investing in platform improvement. Usability issues, security problems, and a cluttered interface drove users away. Facebook and Twitter learned from MySpace’s mistakes, offering cleaner and safer user experiences. MySpace lost its user base and relevance, eventually being sold for a fraction of its previous value. As I write these lines, MySpace allows login with… Facebook or Twitter.

Windows Phone (2010): Microsoft rushed the launch of its mobile operating system to compete with iOS and Android. The operating system lacked many applications and features compared to its competitors. The lack of adoption by consumers and developers resulted in Microsoft’s eventual withdrawal from the mobile market, while Apple and Google consolidated their dominance in the mobile market.

BlackBerry PlayBook (2011): BlackBerry launched the PlayBook to compete with the iPad, in such a rush that it was released without a native email client. Poor sales and loss of market share hurt BlackBerry, which is no longer with us.

Google Glass (2013): Other companies learned from Google’s mistakes to develop their own augmented reality technologies. Google ended up discontinuing the product, losing the initial investment and market potential.

Samsung Galaxy Note 7 (2016): Samsung rushed its release to compete with the iPhone 7. The result was defective batteries causing fires and explosions. Massive recalls and loss of trust resulted in enormous financial and reputational costs for Samsung, which were capitalized on by Apple and other competitors.

And finally, the biggest catastrophe in the aerospace industry in the last 20 years, the Boeing 737 MAX (2018): Boeing rushed its development to a level of criminal recklessness. 346 deaths led to the global grounding of the fleet, causing financial losses, a negative impact on Boeing’s reputation, and an opportunity for Airbus. Boeing’s financial losses total more than $120 billion to date:

• In January 2020, the company estimated a loss of $18.4 billion for 2019.
• In March 2020, Boeing sought a $60 billion bailout, causing a sharp drop in its stock price. Eventually, Boeing received $17 billion in coronavirus stimulus funds.
• As of the FAA recertification in November 2020, Boeing’s net orders for the 737 MAX had decreased by more than 1,000 aircraft, with 448 orders canceled and 782 orders removed from the backlog because they were no longer reliable enough to trust.
• The total estimated direct costs of the MAX groundings were $20 billion, and indirect costs exceeded $60 billion.
• On January 7, 2021, Boeing agreed to pay more than $2.5 billion after being accused of fraud.
• After its intention to suspend production in December 2019, Boeing estimated an additional cost of $6.3 billion to deliver the 737 MAX program.

Only experience can build great Experiences.

To help our strategic consulting clients make better decisions, at Kambrica we developed Experience Decision Making: a consistent system applied in real projects that allows for the timely identification and correction of patterns leading to failure.

The formula for success may be elusive, but one condition is undeniable: not making mistakes that could have been anticipated with experience, nor mistakes so costly they could have been mitigated with rational decision-making processes.

The entry Our Rule #1 for strategic consulting: “Things are done right, or they are done again.” was first published on Kambrica.

Nine women cannot have a baby in a month.

For stakeholders obsessed with achieving “quick wins” while ignoring everything else, I created the reverse relationship:

In nine months, you can have a baby or nine little mice.

Let’s call it the Bustelo-Brooks Law.

Santiago Bustelo
Agosto 2024

The entry The Bustelo-Brooks Law was first published on Kambrica.

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, I can declare that this heuristic is mine. It’s Bustelo’s Heuristic.

Principle: Interfaces should free users from repetitive tasks by leveraging computers’ ability to automate processes. Failing to do so wastes the potential of the digital medium and hampers user efficiency.

Example: The interface shown below, which my bank imposes on all its customers, force us to click for every single receipt we need to download.

When it’s time to close the fiscal year, that’s 72 careful clicks to avoid missing anything: 2 cards x 12, 3 accounts x 12, and a year of investments. And that’s assuming you don’t have loans, not to mention the clicks required to switch between tabs.

All of this, while being careful with each click and scrolling slowly to avoid losing your place (since there’s no distinction between clicked and unclicked icons).

The process could take up to an hour, which could easily be avoided by providing a “download all” link or button. That is, by applying the Digital Nature usability heuristic: the principle that computers are designed to efficiently handle repetitive tasks. This heuristic emphasizes the importance of leveraging technology to automate and streamline processes, ensuring that systems and interfaces are optimized for repetitive actions, thus enhancing user efficiency and reducing the likelihood of error.

Santiago Bustelo
May 2024

The entry The Digital Nature usability heuristic was first published on Kambrica.

If biology teaches us anything, it is that everything happens at the same time.

Books show us biological processes as ordered sequences so that we can get an idea, but reality is something else.

We don’t have pipelines as if we were refineries. The biological field doesn’t work that way. Understanding metabolic pathway schemes takes time, concentration and effort. At the end of which, if we thought we understood the metabolic pathway, we would be fooling ourselves: we are just understanding the scheme.

The same goes for the design process.

“Textbook” processes are narrative simplifications.

To paraphrase Jared Spool, “textbook” processes are the author’s fiction of what he would like his next project to look like.

In my research, a process is a post-hoc rationalization of the idealized portions of work. When people describe their process, they are describing how they’d like to describe how a future project went down — Jared Spool

No design project ever followed an orderly process. Design Thinking, Double Diamond, etc, are didactic simplifications for clients or beginners.

Taking them as guarantees or prescriptions is a mistake that the model, with its false promises, encourages us to make.

For every complex problem, there’s a solution that is simple, neat, and wrong.

Beware of buying simplifications as if they were truths.

For example, look at all the things Christina Wodtke found that Design Thinking leaves out (and that clients and beginners ignore):

All models are wrong; some are useful.

The definition of processes is the most complex problem in Design. Because when you finish understanding and standardizing them… they become predictable, mechanizable, and the design process begins to emerge somewhere else.

Connecting with a community of practice and relying on experts, mentors and critics are essential to achieve a balanced view and mature as professionals.

The anti-agility behind commoditization

Behind the methodologies sold as magical solutions lies the narrative that design problems can be approached mechanically, that processes ensure results, and that they are more important than people.

It is a narrative as strong as the law of gravity. Every methodology tends to gravitate around it, no matter how much it pretends otherwise.

Take the Agile Manifesto itself, declaring since the beginning of the century “Individuals and interactions over processes and tools”. But instead of developing individuals and interactions, companies prefer to hire “agile consultants” who offer false guarantees and magic recipes.

It is our role as professionals involved in the process to resist and fight this trend.

The alternative is to be the executors of the “rituals” proposed by the “gurus”. That model, based on supposed authority and superficial decision-making processes dictated by ‘trends,’ is one of the many marketing mistakes we need to stop repeating

The entry Design Thinking is as useful as astrology, but gets better press was first published on Kambrica.

The topics covered summarize 20 years of professional experience and discussions on this issue with designers, employers, and clients from Latin America, North America, and Europe.

Professional Respect is what allows a professional to perform their tasks. If a doctor did not have the professional respect they deserve, it would take a long time to convince us to undress for an examination.

Designers worldwide often face situations where we do not have the necessary professional respect. How can we achieve it? What is the gap between university and professional practice? How can we bridge it effectively?

The Levels of Professional Respect

Together with José Allona, co-coordinator of IXDA BA, we developed what we call “the ladder of respect.” There are a series of steps we need to cover to reach “universal respect,” which is when “designer” becomes a title sufficient to establish productive conversations, much like how titles such as “doctor” or “engineer” achieve that status today. The first step on this ladder is moving from dealing with artifacts to engaging with people.

Central Concepts:

• Acceptance Criteria: Moving from technical criteria (where an authority approves or rejects the result) to professional criteria (the fulfillment of a committed obligation).
• Professional Communication: Distinguishing between ways to listen to information or emotions (understanding vs. empathizing), ways to express them (explaining vs. expressing), and the appropriate moments for each.
• Planning and Management: Understanding the triple constraint model (quality, time, cost) and the actions needed to keep the project properly framed, or reviewing the framework in time if necessary.
• Avoiding Attachment to Decisions and Results: The designer’s job is not to make “the” decision and achieve “the design.” It is to provide resolution alternatives so that the project leader can understand the pros and cons and guide each stage. This involves developing alternatives in an economically reasonable manner, presenting their pros and cons, and supporting an informed decision.

The entry Design Leadership: on earning professional respect was first published on Kambrica.

By breaking with the term “client,” we break with the notion that “the customer is always right.” A mistaken notion, as we’ll see later.

We don’t work for people who believe they are “right.”

We work for people who recognize and respect how our knowledge and experience can help them make better decisions and achieve better results.

Our role as UX consultants at Kambrica is not to validate those who hire us. Our role is to help them understand their customer.

And it’s that final customer who will make decisions about the product or service based on their own criteria… and not on what the business believes is correct. That’s the original meaning of the phrase “the customer is always right”: we need to understand how end customers decide if we intend to reach them.

The entry Actually, at Kambrica we don’t have “clients.” 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.

If we give direct instructions or commands to users from the software (e.g., “Enter card number without dashes or spaces”), then we are trying to program people, which usually doesn’t end well.

When this happens, it’s best to go back to programming computers with the goal of making them adapt to people.

For example, use a regular expression to only accept numeric characters.
In pseudocode: find( /[^\d]/ ).replace("").

This instruction for the computer requires fewer characters than the instruction for the user, never fails, and makes everyone happy.

Computers, we program. People, we understand.

Everything works much better when we apply the tools we master to the domains they are meant for. Computers, we program. People, we understand.

The entry A programmer’s job is to program computers. Not people. 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.

This presentation consolidates previously presented content:

• Application case of KLM-GOMS for operational improvements in management systems (first presented in 2008 at the Microsoft RAF event),
• Heuristics understood from principles of cognitive psychology (presented since 2015 in the UX Workshop).

In the User Centered Design process, it is crucial for all those involved in Design, Development, and Business decisions and execution to observe users operating with the product.

While user testing allows us to observe what needs improvement, it doesn’t provide concrete information on what we should modify in interfaces and interactions so that users can achieve their goals with greater effectiveness, efficiency, and satisfaction.

This presentation exposes Principles and Heuristics of perception, selection, and operation, as well as models for quantifying interaction costs (Hick’s Law, Fitts’s Law, KLM-GOMS) necessary to achieve better results.

In the User Centered Design process, it is crucial for all those involved in Design, Development, and Business decisions and execution to observe users operating with the product.

The application of these principles and tools allows for significant operational improvements in systems that are used recurrently. Reducing just 10 seconds of operation in a functionality used more than 100 times a day results in more than 15 minutes gained per day of operation, and more than 8 hours gained per month.

This increased operational efficiency leads to measurable improvements in productivity, quality of care, and user satisfaction with internal systems.

The entry Methodology and Tools for Designing High-Performance Systems was first published on Kambrica.

Presented at:

• Artmedia 2016: Universidad Maimónides / CCGSM, Thursday, November 10, 2016
• Interaction South America 2016: IxDA / Universidad Católica de Chile, Thursday, November 3, 2016
• XI Latin American Design Meeting: Universidad de Palermo, Tuesday, July 26, 2016

Software is eating the world: not only is it omnipresent today, but its practices and methodologies are also changing the very way we plan and do things. Experience Design (UX), which emerged within the context of software, is beginning to encompass and impact other design disciplines, shaping their future.

In this presentation, we’ll take a brief look at the milestones of the last 15 years in Experience Design, and project the direction all design disciplines will take in the next 15 years.

The entry The Future of Design and UX: The Next 15 Years was first published on Kambrica.

Summary: What can UX professionals learn from Marketing’s mistakes?

Between the 1950s and 1990s, Marketing worked hard to position itself as the missing link between companies and customers.
Today, far from that position, it tends to be one of the least respected disciplines in business, both by companies and customers.

• How did this happen?
• What marketing promises is UX now repeating, risking our credibility?
• Are we making the same mistakes? (hint: yes)
• How can we avoid falling into the same traps?

The promise: Marketing’s golden days

A brief summary of Marketing’s early successes, its promises, how it changed the way business was understood, and how it earned a seat at the table. Case study: Louis Cheskin and the application of the scientific method.

The disappointment: Marketing’s fall from grace

The sins that led Marketing to fail as a discipline: Arrogance, Complacency, and Superstition (Cargo Culting).

Reflecting on UX

A parallel between Marketing’s ups and downs and our current situation. How, by ignoring Marketing’s history, we are doomed to repeat it – and how we are already falling into the same traps.

Taking the wheel

It’s not too late. We can still envision the path forward, anticipate risks of derailment, make decisions, and take action as professionals and as a community.

• Identify mistakes that have already begun (that must be stopped) and anticipate new mistakes (that must be prevented).
• Recognize the good actions already in progress (that must be supported) and project the good actions not yet initiated (that we must start).
• Engage as professionals and as a community with the future of our practice.

About the author

Santiago Bustelo is the Director of User Experience at Kambrica, a UX consultancy based in Buenos Aires. He chairs the local chapter of the Interaction Design Association (IxDA BA) and was the first Regional Coordinator of IxDA for Latin America.

Santiago began his career as an interaction designer in 1996, designing business simulators for management training. At that time, Total Quality Management was in vogue. It didn’t live up to its promises. Today, we are repeating the same cycle with Lean and Agile.

The entry Professional UX practice: What can we learn from Marketing’s mistakes? was first published on Kambrica.

The panel took place on Tuesday, July 30, in the Auditorium of the University of Palermo. Other speakers included María Eugenia Marín, Martín Noe, Nora Palladino, and Damián Kirzner.

The focus of the talks was based on the premise: “In a field where change is constant, staying updated on new formats and digital platforms is a real challenge. What are the must-know novelties for creatives and communicators?”

What’s new in the digital universe?

As a designer, I have the habit of questioning the question to reach slightly deeper answers. In this case, I ask: What do we mean by “new”? It seems like things emerge with the label “new,” and there’s a specific moment when that label peels off… A moment after which, things are no longer “new.” Is that really the case?

Suppose we come home and find a dog. That’s new! But the dog itself isn’t new: it didn’t come out of nowhere, it was born some time ago. Why is it “new” to us? The appearance of the dog brings us questions and forces us to make a decision about what to do with it. And that, to me, is what makes something “new”: it generates questions we hadn’t asked before and presents possibilities and decisions we hadn’t considered until now.

What do we design?

So, what’s new in the digital world? Something inherent to digital since its inception is that it expands and encompasses more and more things. In this expansion, there’s always a part that is novel, which becomes commonplace. For example, today it’s rare to go job hunting with a newspaper under your arm like 20 years ago. The norm today is to prepare our resume on a computer, search for job offers online, and send emails. The digital advances into the everyday until it becomes diluted, until we no longer perceive it.

The new product of this advancement is that designers start designing the invisible. New professions like interaction design have emerged, focusing on defining ways to interact with a system. For example, the gesture of pinching two fingers on a screen to zoom out, which seems so natural, didn’t come from nature. It’s the result of a design process. Someone decided to use that gesture instead of another method and for the system to respond in a certain way to make it satisfying. The person who made those decisions is an interaction designer.

Another discipline that designs the invisible is user experience (UX) design, where we intervene in artifacts and services to ensure people have a specific experience. It’s not about designing the screen: it’s about designing what happens in front of the screen.

These are relatively new design professions that affect the already established design disciplines. And they lead us to ask: if designing is not just about working on the visible, what is designing?

How do we design?

Another aspect in which the digital has been influencing the design world, beyond these new disciplines, is the way we work. In software, agile methodologies have emerged and formalized. In themselves, they are not new: the Agile Manifesto was published in 2001. But they bring us questions that we are still working on.

Agile methodologies emerged to respond to the inherent uncertainty of a complex project. Applied to design, these methodologies are helping us gain greater control over the complexities inherent in the creative process, the relationship with the client, and with all other stakeholders.

So, the agile methodologies that appeared within the framework of software engineering are now also contributing to design. And as software design disciplines are feeding back into traditional design disciplines, they are also incorporating these new ways of working. One advance in this regard is Core Design, the initiative we promote from the Interaction Design Association (IxDA) for university education in Design.

Where is the world heading?

As the digital advances into the everyday, today we talk about digital transformation. The biggest challenge in this process is not technical or about generating more technology, but the cultural changes that are necessary.

Every human organization is built on declarations and agreements that we can call “political.” Software, on the other hand, is concrete and operates on the measurable and specific. Digital transformation therefore requires organizations to move from establishing networks of declarations to managing networks of well-defined commitments.

This will necessarily lead to social and cultural transformations: in what ways will we coordinate efforts to build the future?

What is our responsibility?

Every tool has two parts: one part that adapts to the problem (the technique) and one part that adapts to a person, which is the design space. Without technique, there’s no technology, just science fiction. And without a person, without design, there’s no technology: only technical curiosities.

In a world with more and more technology, which people depend on to perform social functions like getting a job, the designer’s social role is to understand and integrate all people into their work. This is known as accessibility: ensuring anyone can use an object, visit a place, or access a service, regardless of their technical, cognitive, or physical abilities.

Design today, then, is being redefined. It cannot be limited to satisfying a client, aesthetics, or even the visual. It’s compelled to face questions that rediscover its noble purpose: the ability to understand people and provide solutions to their real needs. That is the responsibility and social role of design in this digital world.

The entry Encuentro UP 2019: What’s new in the digital universe? was first published on Kambrica.

The hypermarket Jumbo, part of the Cencosud chain, needed to streamline its online shopping process to boost site conversions.

We designed a new online shopping process that allowed for the presentation of a greater number of products in a more attractive and recognizable manner, making it easier to purchase multiple items. This positively impacted the number of items per purchase and the average ticket size.

Before and After

Areas of Work:

• Using a user-centered design methodology, we conducted contextual interviews to observe users making purchases in their usual environment. This allowed us to identify various factors that caused friction during the shopping process.
• Based on our observations, we created a functional prototype, on which we conducted usability tests to validate that the new design satisfied the users needs.

The entry Jumbo a Casa was first published on Kambrica.

Increase is one of the startups that, under the Wayra accelerator program, participated in our consulting and mentoring program focused on UX techniques for the development of their product.

The Increase platform enables businesses to understand, manage, and administer all operations they carry out with credit and debit cards.

• Before our work with Increase, most of their clients interacted with the application through Excel.
• After improving the interface’s usability, users began to interact with the application more frequently than with Excel.

Areas of Work:

• As a starting point, we conducted a round of usability tests on the platform as it stood in October 2014. During this phase, we evaluated the value proposition and the system’s usability.
• We used these insights to organize a second research session. This time, we conducted contextual interviews with users of the tool to uncover the issues they encountered during regular use.
• The Increase team took all the information gathered from both phases and redesigned the site’s homepage, enhancing the communication of the value proposition, platform registration, and overall usage. They prioritized and structured the information displayed to allow for better management. The entire redesign process was carried out by the entrepreneurial team with weekly follow-up from Kambrica.
• We facilitated knowledge transfer regarding the Lean process so that the team could continue applying the methodology after the program ended. This provided the startup with the tools to keep refining and improving its product.
• Through the Lean UX program, we helped Increase identify key areas for product improvement, including features, usability, and interaction design.
• We also assisted in enhancing the value proposition through user interviews.
• We trained the team in UX practices.

They taught us to think and understand how to create a product based on what the customer needs, rather than what the founders want. How to design a product by listening, analyzing, and, above all, observing our users. Kambrica helped us build a solid product that still maintains the same structure today.

Matías Doublier, COO Increase

The entry Increase Card was first published on Kambrica.

In 2010, Santander Río bank needed to migrate the request for its products from the physical to the online channel. Up until that point, very few customers were willing to apply for credit cards online.

The reasons: low trust in the online channel and forms that required information users didn’t understand or weren’t willing to complete.

Areas of work:

We redesigned all the application forms, following best practices in usability and accessibility.

• Conducted UX Research to evaluate existing processes, user motivations and interests, opportunities, and areas for improvement.
• Redesigned the process for applying for credit cards and banking packages, following best practices in persuasion, usability, accessibility, and responsive design.
• Redesigned internal Knowledge Management systems.
• Conducted interviews with the Call Center to learn about best sales practices, which were then applied to upselling processes.

The entry Santander Río was first published on Kambrica.

The Office of Judicial Affairs at Stanford University selected us for our ability to provide design and development that met Section 508 standards: making it accessible to all individuals, regardless of their technical, cognitive, or physical abilities. This earned recognition from a panel of experts at the prestigious South by Southwest (SXSW) Festival in 2004.

The information architecture and content strategy recommendations were made considering the use cases where faculty and students must access the site: sensitive topics related to violations of the university’s honor code, such as plagiarism, substance abuse, or sexual harassment.

The HTML/CSS development not only resolved accessibility issues with the same code but also included special styles for different resolutions and printing, automatically selecting them when printing the page or generating PDFs.

Thanks to this responsive approach, the site became the single repository of official information for all formats, eliminating maintenance issues related to information across multiple formats and requiring the responsible staff to document and train on a single platform.

Areas of work:

• Consulting
• Accessibility
• Information Architecture
• Interface Design
• Front-end Development
• Validation with users with disabilities

The entry Stanford University was first published on Kambrica.

Since 2012, we have partnered with the Digital Product teams of the Telefónica Group, designing and improving the web and mobile user experiences with which millions of people interact.

We’ve improved the usability of fixed-line, mobile, and internet purchase processes to increase sales, reduce call center volume, and optimize processes.

Our work included the development of promotional landing pages, improving customer service processes, and enhancing product and offer communications to improve understanding and capture of the value proposition.

• We reduced support costs and decreased user frustration.
• We contributed to the maturity of the digital product teams in UX, impacting other areas of the company.

How We Helped

• We redesigned the homepage for fixed-line and mobile services.
• We improved the site navigation flows.
• We redesigned the purchase flow for mobile phone plans.
• We redesigned the purchase flow for internet plans.
• We redesigned the purchase flow for fiber and TV plans.
• We designed and enhanced the impact of promotional landings: portability, Hotsale, Multiply, Mother’s Day, Father’s Day, etc.
• We improved the discovery, acquisition, and upselling processes for phone lines, internet, and mobile lines.
• We improved the self-management processes for large clients.
• We enhanced the quality of information in the Customer Service section.
• We conducted usability analysis and communication needs assessment for the launch of the redesigned Movistar app.
• We conducted usability analysis and provided actionable improvement proposals for critical business processes.
• We performed qualitative and quantitative analysis of page performance and specific flows.
• We created the first usability manual for the company, aligning all departments.
• We developed tools to reduce costs and time in decision-making, design, and development processes.
• We facilitated workshops with stakeholders to define product vision and ease decision-making for product and design.
• We provided training on Lean UX methodology, user-centered design, and Design Thinking.

The entry Movistar 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.

Experience Decision Making (XDM)

On October 31, Santiago Bustelo presented Experience Decision Making: The Missing Link Between “Design Thinking” and “Doing Business.”

Designing, operating, and maintaining experiences involves new ways of undertaking projects and businesses. This challenge has been fertile ground for new working methodologies, all of which promise the success that eludes others. While useful, they all share the same limitation: a working methodology proposes a way to organize people and processes. It does not replace people or their decision making processes.

Experience Decision Making (XDM) was born from recognizing this missing piece. It is a system of models and methods to achieve better decision making processes in the experience industry, integrating elements from decision theory, behavioral psychology, negotiation, and management.

The entry New Frameworks for Better Decisions at ILA19 was first published on Kambrica.