Inventors tend to build their expectations on a fairly simple model:

INVENTION → ??? → PROFIT!

The question marks in the middle, where the magic is supposed to happen, represent the business model. In most cases, no one examines it clearly before making decisions that later become irreversible.

There are two versions of this problem.

The first is the pure inventor who believes the value of what they created will assert itself on its own, that the world will recognize the brilliance of their invention, and that some form of reward will follow naturally. The reality is that the idea may be brilliant, but that does not necessarily mean it can sustain a business. Because having a good idea is not the same as having a good offering.

The second is the entrepreneur who develops an innovative product but, instead of understanding what they actually have, moves forward “as they see fit,” “by the book,” or copies the model of some successful case without seeing that it does not apply to them. I call these autoimmune ventures: they attack themselves without knowing it.

In the strategic direction of an innovation, we need to answer concrete questions. What aspects of our project will become inevitably exposed as soon as we demonstrate that the product works? What elements can we keep open, or even benefit from keeping open, without risking future monetization? Is our innovation a sustainable business on its own, or is it actually a complement to another commercial model?

The Inventor’s Strategic Matrix is the model I developed to bring clarity to strategic decisions in innovation projects and to answer these questions with confidence. It is the product of three decades of professional practice, crossed with lessons learned back in 2004 from my mentor Roberto Cunningham (Director General of IAPG), and the vision of figures like Jorge Sábato, Joel Spolsky, Frederick Lanchester and Simon Wardley.

The Matrix does not prescribe what to do: it describes the board. Once you understand the board, you can consciously choose which game you want to play. Before that, you are playing without knowing the rules.

The Model: The Inventor’s Strategic Matrix

The Matrix has three dimensions:

1. The nature of the asset: how exposed it is by its own nature, regardless of what the inventor decides
2. Technical protection: what technical mechanisms the inventor can apply to control access
3. Legal protection: what legal instruments the inventor can apply to control use

These three dimensions are organized in a table where the rows are the levels of asset nature, and the columns are two independent groups: technical protection and legal protection.

Dimension 1: The Nature of the Asset

Intellectual assets are not all the same. They have a nature that ranges from more exposed to more opaque, and this nature does not depend on decisions made by the inventor, but is an inherent characteristic of the type of asset.

Level -1: Preexisting Knowledge

This is what existed before the invention. Science, culture, the collective knowledge accumulated by humanity. It cannot be appropriated by anyone. You cannot patent a law of physics, a known chemical reaction, or a collective cultural tradition. The corporate attempt to patent varieties of Andean quinoa or medicinal uses of turmeric illustrates this violation: it is biopiracy of knowledge that intrinsically belongs to Level -1.

Level 0: The Inevitable

This is the idea that is revealed simply by showing the product. It is not a decision to open up. It is an irreversible consequence of existing publicly.

The moment you show that your product works, you reveal that the idea is possible. This cannot be protected in any way, regardless of what the contract, patent, or confidentiality agreement says. Intellectual property laws do not protect an idea, but rather specific implementations.

If an initiative has a part that is exposed there, “opening” it is not an error or a surrender of intellectual property. It is formalizing what is already happening in practice. Any explanation you need to give for people to become interested or adopt the initiative falls into this territory. If you need to explain things for your project to be credible and trustworthy, what you have to reveal is necessarily Level 0. You have no way to protect it, and the best you can do is have your strategy incorporate it clearly.

Collaborating at Level 0 does not generate rights or obligations regarding what comes after. Being free as air, this level cannot sustain any business model, because you cannot generate income on something that circulates freely and does not require a transaction to obtain it. Whether the first person to present the idea or the last to learn of it, anyone can take it and develop something on their own in upper layers that can be protected and monetized. That future commercial structure may owe moral recognition to the original Level 0 work, but in practice (and by legal advice) the commercial model operates autonomously.

The upper layers can have a commercial model. An open Level 0 does not close that possibility: it enables it, generating the credibility and conversations needed to finance protectable intellectual property in upper levels.

The question that defines what is at Level 0 is simple: can someone seeing my product work for the first time infer the idea behind the product, and that my product proves that idea is possible? If the answer is yes, it is at Level 0.

Friendster was the historical example: it demonstrated in 2002 that a social network with real identity worked. The concept was revealed at Level 0 to the entire market including Mark Zuckerberg, who was a Friendster user when he launched Facebook.

Level 1: Observable with Effort

This is what requires analysis, reverse engineering, or specialized access to see. It is not revealed on its own, but it is not protected by architecture either. With time, resources, and sufficient technical knowledge, it is accessible.

Level 1 is where many inventors believe they are protected when they actually are not. The illusion of technical complexity is not protection.

The chemical formula of Chanel No. 5 resides here: although the brand is legendary, any modern laboratory can apply reverse engineering and identify its components. Chanel’s real protection is not in the formula but in the control of the supply chain of its specific ingredients, which is Level 2.

Level 2: Controllable

This is what the inventor can maintain in an environment under their direct control. It can be code that runs exclusively on their own server, a calibration database, or the parameters of an industrial process that never leave the plant. Here lies the real strategic decision: exposure is not inherent but depends on the architecture and technical discipline of the inventor.

Coca-Cola operates at this level. By keeping its formula as a trade secret under strict physical control, it exercises protection that has been in effect for over 140 years: much longer than the 20 years a patent would have lasted.

Level 3: The Intangible

The community, reputation, authority, positioning. This level is not patented or stored on a server. It is the only truly permanent asset, and it is built as a consequence of decisions made at lower levels. Unlike the other levels, it does not admit technical or legal protection barriers: it is only cultivated and sustained, and it can be destroyed from within by the poor decisions of those who manage it.

The network of users, journalists, and politicians on Twitter/X is the paradigmatic example. Microblogging is Level 0 and the code could be replicated in weeks, but the concentration of social capital on that platform is irreplicable overnight. Even after the most controversial decisions of its new management, the platform retains its gravitational weight over all the clones that emerged to replace it.

Dimensions 2 and 3: Protection Decisions

The horizontal axis of the model details the barriers the inventor can put in place. These are two independent groups of decisions.

Technical Protection

The architectural or physical barrier. It is divided into three mechanisms in increasing order of robustness:

Obfuscation. Hiding the source code, formula, or process. This is the weakest mechanism: it collapses with a single discovery event. A former employee, a leak, or advances in analysis tools can destroy it. Stac Electronics’ code depended on this and collapsed in a meeting room.

Access friction. Making access costly without controlling it absolutely. This is more robust than obfuscation but still temporary: it collapses when technological change reduces access cost to zero. The music CD required purchasing a physical object; Napster reduced that friction to zero in 1999 and the recording industry’s business model was never the same.

Control of the indispensable resource. The most robust mechanism. It does not hide information; it controls the physical infrastructure, hardware, or supply chain without which the asset cannot function, regardless of who knows the concept. Apple Silicon eliminated the informal “Hackintosh” market that existed in the Intel era. Not because any law changed, but because the resource (the processor) became inaccessible to third parties again.

Legal Protection

It operates independently of technical protection. Its main instruments are:

Patent. Protects the specific implementation. It requires revealing how it works in exchange for a temporary monopoly of approximately 20 years. It has jurisdictional scope: a patent in Argentina does not protect in Norway.

Copyright. Protects the specific expression, not the idea. It exists automatically in most jurisdictions and has a much longer duration than a patent.

Registered trademark. Protects the name and identity. Unlike a patent, it does not expire as long as it remains active. Aspirin is a registered trademark of Bayer in Argentina and Germany, but is a generic public domain term in the United States, a loss that occurred as war reparations in 1918.

Open license. Defines what others can do with the asset. A GPL license, for example, allows free use but requires that all derivatives maintain the same open conditions. It does not protect the idea but regulates its use.

The Cross-Cutting Principle: Protecting Means Delaying

No technical or legal protection on an asset is forever. Patents expire. Architectures are breached. Resources change. Protecting is simply buying time.

Once you assume that premise, the strategic decision reduces to choosing what you build with the time you buy. There are three models:

Exploitation and exit. You exploit the product to the maximum while protection lasts, without intending to extend the business beyond that limit. You collect the rent and when the barrier falls, you withdraw with the capital. It is a one-shot bet, conscious and legitimate.

The ladder. You use the time and capital your current protection gives you to develop the next product. You know your current patent will expire, but you plan that by the time it does, you will already have the next generation protected. This is the game of mature corporations.

The intangible moat. You use the advantage time to build a community, reputation, or market standard at Level 3. By the time competitors manage to replicate your technology, it no longer matters: your business value has moved to an asset that is immune to reverse engineering.

The Possible Games

Once positioned in the Matrix, the inventor can choose their strategy:

The patent game (Edison). Methodical registration, active licensing, and litigation when necessary. Requires legal backing and accepts that in 20 years the invention will be public. The goal is to extract maximum value during the exclusivity window.

The trade secret game (Coca-Cola). Strict opacity and permanent internal control. Unlimited protection over time, but total vulnerability if the secret leaks: there is no legal recourse to recover disclosed information.

The indispensable resource game (Apple). Control the physical or logistical bottleneck that enables access to the asset. It does not depend on secrets or anyone figuring anything out: it depends on a structural position that is difficult to replicate.

The community game (Linux). Deliberately releasing Level 0 and Level 1 so that adoption builds a Level 3 ecosystem that no competitor can copy. The business is not in the code but in the authority and services surrounding the community.

The hybrid game (Android/Google). Google open-sourced Android to generate mass adoption: any manufacturer can use the operating system freely. But Google Play Services (the app store, maps, Google login, behavioral data from billions of users) are completely proprietary. Manufacturers who want Android with the full experience must accept Google’s terms. The openness of the visible layer generated an invisible lock-in in the services layer.

In-Depth Cases

Stac Electronics vs. Microsoft: The Cost of Showing What You Shouldn’t

In 1993, Stac Electronics had created Stacker, the first real-time disk compression software for DOS. The concept was Level 0: anyone who saw it working could understand it was possible. But the specific algorithm was patented and the source code was protected by obfuscation: the distributed binaries did not come with source.

Microsoft wanted to include compression in MS-DOS 6.0 and began negotiations with Stac to license Stacker. During the process, Stac engineers showed source code in the meeting room, believing the context protected them.

The negotiation failed. Microsoft released DoubleSpace. The code was functionally identical to Stacker’s.

Stac before the meeting:

Stac after showing the code:

The legal protection did not change. The technical protection collapsed in an instant due to a human decision in a meeting room. Stac won the lawsuit and received $120 million, but Microsoft’s countersuit (based on a trade secret Stac had seen during the same meetings) left them in a position that forced a settlement and condemned them as an independent company.

The lesson is not not to negotiate. It is to know exactly what level you are exposing before entering the room.

Friendster: Validating the Market for Someone Else to Take It

Friendster demonstrated in 2002 that social networks with real identity worked. The moment the product worked publicly, that idea moved to Level 0 for the entire market. Friendster had a time advantage but did not build any indispensable resource at Level 2 nor manage to consolidate a community of ideological identification at Level 3.

The result: they validated the market, educated users on social network behavior, and paved the way for Facebook, which executed better on exactly the same Level 0 base. Friendster ended up selling its patents to Facebook for $40 million in 2010 and closed in 2015.

Twitter/X: When Level 3 Is the Only Real Asset

Technically, Twitter/X does not keep any secrets. Microblogging is Level 0 and the code could be replicated in weeks. Mastodon, Bluesky, and Threads did it. None managed to displace it.

Twitter’s real asset was never the technology. It was the irreplicable concentration of journalists, politicians, scientists, and public figures that turned the platform into the digital public square. Elon Musk paid $44 billion in 2022: not for the code, but for that network. And subsequent management showed that Level 3 can be destroyed from within: the most controversial decisions generated migrations that would not have been possible if the intangible had remained intact.

Conclusion

The Inventor’s Strategic Matrix does not solve the inventor’s problem. It makes it visible.

The question mark in the “invention, ???, profit” model does not disappear with the Matrix. But the Matrix allows you, for the first time, to ask the right questions about what is in that space.

The real problem is not protecting what you have. It is understanding what you have, what level it is at, and what you can realistically do with it. Edison knew what game he was playing. Coca-Cola knew what game it was playing. Linux knew what game it was playing. Apple under Jobs knew what game it was playing.

Stac did not know what game it was playing when it entered negotiations with Microsoft. Friendster did not know what game it was playing when it validated the market for others to take advantage of.

If it seems obvious to you that you need this kind of clarity to untangle your project’s decision-making processes, let’s get in touch.

Appendix: 30 Cases for the Three Strategic Models

The purpose of this appendix is not exhaustiveness but calibration: to show that the three strategic models are patterns that repeat across completely different industries, eras, and scales.

Model 1: Exploitation and Exit

This model works when the inventor honestly recognizes that their advantage is temporary and scales their ambitions accordingly. It is not a strategic failure, but a conscious and legitimate strategy.

1. The Million Dollar Homepage (2005). Alex Tew sold one million pixels at one dollar each to pay for university. The concept was irrepeatable by definition (there is only one “first site to do this”) and he knew it. He collected, closed, and did not try to build an advertising business.
2. Flappy Bird (2013). Dong Nguyen created the game in two days, saw it reach 50 million downloads, and voluntarily withdrew it when public attention became unbearable. He deliberately left money on the table.
3. Wordle (2021). Josh Wardle created the game for his partner. It went viral. He sold it to the New York Times for seven figures without intending to become a video game studio. He identified the moment of maximum value and exited.
4. Hoverboards (2015). The holders of the first patents aggressively licensed during the demand peak and withdrew before the flood of Chinese clones collapsed margins. They played the time window with precision.
5. Pet Rock (1975). Gary Dahl sold rocks with instruction manuals and became a millionaire in six months. He never pretended it was anything else. It is the purest case of the model: he invented a fad, exploited it, and exited.
6. Fidget Spinners (2017). The demand peak lasted less than a year. Manufacturers who understood this exploited the window and exited. Those who believed it was a lasting category were left with inventory.
7. Snuggie (2008). A blanket with sleeves sold via infomercial. The brand was squeezed until natural interest exhaustion without attempting diversification.
8. Billy Bob Teeth (1994). Tom Shepard designed novelty dentures. Generated millions in the Halloween and novelty market without seeking expansion.
9. The Rubik’s Cube (1980s). Erno Rubik massively licensed during the cultural peak of the 1980s. The cube faded, resurfaced decades later, and the licensing model sustained the business in both waves.
10. Aereo (2012-2014). A company that retransmitted TV signals via miniaturized individual antennas, exploiting a legal loophole. Operated until the U.S. Supreme Court closed the loophole. It was a model built explicitly on a temporary legal window.

Model 2: The Ladder

This model requires long-term vision and the discipline to invest in the next step before the current one collapses. It is the game of organizations that survive decades.

1. Gillette. From the double-edge razor to Mach 3, to Fusion, to ProGlide. Each product generation is launched when the previous patent is about to expire, maintaining exclusivity continuously since 1901.
2. Intel. The “Tick-Tock” model: one year they optimized the manufacturing process (Tick), the next they renewed the architecture (Tock). They released a new generation just as the previous one was becoming commoditized.
3. Pfizer. Viagra → Lipitor → COVID vaccines. Each megablockbuster funds research for the next. When one patent expires, the next product already has years of accumulated development.
4. Qualcomm. Built iterative patent portfolios on each generation of mobile telephony: CDMA, 3G, 4G, 5G. Each new standard incorporates its essential patents before anyone else can compete in that space.
5. Dyson. From the bagless cyclonic vacuum to the bladeless fan to the supersonic hair dryer. Each product carries the same logic of radical redesign of an everyday object into a new category.
6. 3M. Patent portfolio in adhesives and abrasives that is constantly renewed. Post-it was an accident that became a product; that ability to capitalize on lateral findings is part of the model.
7. Corning. Pyrex in the 1910s, fiber optics in the 70s, Gorilla Glass in 2007, Ceramic Shield in 2020. Each specialized glass technology is born from the previous one.
8. ARM. Each new version of its processor architecture is designed to be the standard for the next generation of devices. Their business is licensing architectures, not manufacturing chips, which allows them to be everywhere without manufacturing anything.
9. DJI. Aggressive iteration of drones and camera stabilizers. When a competitor manages to replicate the current model, DJI already has the next one on the market.
10. DuPont. Nylon in the 30s, Kevlar in the 60s, Teflon in the 70s, Lycra, Tyvek. A century of advanced materials ladder where each invention funds research for the next.

Model 3: The Intangible Moat

This model requires patience and the conviction that the community built is more valuable than any technical or legal protection. It is the most difficult to execute and the most difficult to destroy once achieved.

1. Linux / Red Hat. The Linux kernel is free and open. Red Hat built a business of services, support, and certifications on that base. IBM bought Red Hat in 2019 for $34 billion. Not for the code, but for the community, reputation, and service contracts.
2. Wikipedia. The technology of a wiki can be replicated in hours. The community of editors maintaining over 60 million articles with verification and neutrality standards is not. That is the real asset.
3. Stack Overflow. A technical Q&A forum. The technology is trivial. The asset is the accumulated base of community-verified solutions and the professional reputation programmers built there over years.
4. Airbnb. Accommodation booking technology is trivial. The real asset is the trust network between hosts and guests built over millions of verified transactions. Replicating that trust from scratch requires time that money cannot buy.
5. GitHub. Git is an open version control protocol anyone can use. GitHub is the social network where programmers built their professional reputation and where the world’s most important open source projects live. Microsoft paid $7.5 billion for that intangible.
6. Craigslist. 1990s technology, design unchanged for two decades, yet it remains the dominant local classifieds in the U.S. Its asset is local liquidity: the number of buyers and sellers in each city that makes the platform work. No competitor with better technology could replicate that critical mass.
7. Waze. GPS routing is Level 0. Any map app can calculate a route. Waze’s asset is the real-time reporting from millions of drivers on accidents, police, and traffic closures, data that only exists if there is an active community generating it. Google bought Waze in 2013 for $1.1 billion for that data and community.
8. WordPress. The content management software is completely commoditized. The moat is the community of tens of thousands of plugin and theme developers who chose WordPress as the platform for their businesses. Migrating that ecosystem is practically impossible.
9. Roblox. The graphics engine is secondary to what Unity or Unreal offers. The real asset is the network of millions of creators who built games on Roblox and the millions of users who play those games. The platform is worth what it is because of the community that inhabits it.
10. Strava. Recording a GPS activity is a function any sports watch or fitness app has. Strava’s asset is the social network of athletes: the segments with rankings, KOMs, clubs, reputation accumulated over years of activity. That does not migrate with a button.

Santiago Bustelo
July 2026

The entry The Inventor’s Strategic Matrix was first published on Kambrica.

The problem is that Figma and others are already ceasing to be design tools and becoming production tools. And designing and producing are completely different, and fundamentally incompatible, processes.

By fusing the two, the tool imposes its own design decisions. The result is not greater efficiency, but clone-like products of a stochastic average. Products that accelerate the commoditization of your product and your brand.

And when everything looks alike, the market begins to choose exclusively by price. It is not a failure of your design team; it is the direct consequence of making strategic decisions based on operational haste.

The result is that 80% of launched projects are indistinguishable.
Because they respond to the rules of AI, not those of your customers.

This cannot be fixed by designers who can code. Every development methodology since 1970 recognizes that design and implementation are separate. Fusing them always sounded tempting. But operationally, it never worked.

The pressure to produce always chokes the capacity to create.

The rush to “not miss the train” is making us end up under the tracks instead of in the car.

At Kambrica, we have been working with AI since 2009, long before it was a corporate fad. Keepcon, one of the technology companies we worked with in its initial phases, was recently sold. In the words of its founder: when they had no customers or technology, our prototype allowed investors to land an abstract idea, understand the business model, and close their first round of investment.

I started my career in UX 30 years ago, designing and developing business simulators for management training. Today, I help leaders and managers make better decisions at the intersection of business, design, and technology.

If you are looking for AI adoption with real results, haste is the worst counselor.
We offer you experience.

Let’s get in touch.

–

Santiago Bustelo
Junio, 2026

The entry How are you approaching AI adoption in your design team? was first published on Kambrica.

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.