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.