Night mode addresses something else: what happens in front of the screen in environments where we never expected a screen to be… yet the user pulls it out of their pocket or purse.

1. Biological timing: adapting to darkness

In low-light conditions, our eyes adjust and begin recognizing details they couldn’t perceive before. The purpose of a night mode is to preserve that state.

The following IPAX simulator presents a scene we have all experienced: sitting inside a car cabin at night facing blinding lights. In this scene, we can switch between three common roadside sources. The most aggressive ones are, not coincidentally, the ones chosen by people who love inflicting high beams on everyone else.

Clicking the active light turns it off, triggering automatic adaptation to low-light conditions. Over time (accelerated in the viewer to just a few seconds), the road becomes visible. In a second stage, we transition into night vision, where we stop perceiving color and can even make out faint stars in the sky.

When we turn a bright light back on, the effect of it appearing to dim down is also part of visual adaptation: the eye moves from initial glare, caused by having vision adapted to darkness, to tolerating brightness in order to recover the cabin interior.

2. The phone as a head-on flashlight

In the next scene, we see a phone turned on in light mode inside the cabin. A secondary effect of the light it emits is preventing dark adaptation. Night vision only becomes possible once we turn it off.

In practice, the phone becomes our very own head-on truck.

The car’s built-in display is designed to prevent that blindness: in night mode, it doesn’t cause glare or wipe out vision of the surroundings. If we click that display and switch it to day mode, we see how this incorrect setting creates glare, casts a reflection on the windshield, and lights up the cabin… but without triggering bright-light adaptation the way the phone does.

If you have ever ridden as a passenger and turned on your phone (in light mode!) to check directions, the driver almost certainly asked you to turn down the brightness or shut it off completely. Because it is preferable to drive without seeing the map than without seeing the road.

Night mode is a Design System decision to ensure an application can be used under any real operational condition.

3. Halation and astigmatism: why a “night mode” is better

It is common practice to design dark mode as a negative of the light palette, replacing the white background with pure black (#000000) and black text with pure white (#ffffff).

An unexpected consequence of that design decision is strained reading for the 40% of the adult population with some degree of astigmatism.

This condition amplifies the effects of mydriasis: when the eye faces an absolute black background, it interprets that it is in darkness and dilates the pupil to the maximum. Placing pure white text over that black background causes the excess photons emitted by the glyphs to spill into dark areas, a phenomenon known as irradiation or halation.

The following simulator allows you to compare how typography behaves through the optics of an eye with moderate astigmatism, showing how 100% white on pure black creates a destructive halo.

As the IPAX simulator shows, lowering text luminance and elevating the background value mitigates extreme pupil dilation and reins in the effect. This is one of those cases where prevailing accessibility dogma (“the more contrast, the better”) proves to be a simplistic reduction, a topic Santiago Bustelo presented on at Rosenverse this past July.

Since the term “dark mode” has become popularized for any interface where text is lighter than the background, at Kambrica we propose calling “night mode” the subset that factors ergonomics into its design decisions.

To help achieve this, we developed IPAX, a model and toolset for making better design decisions grounded in the physics of light and perception. And with IPAX Foundation Layer, we help Design Systems handle this combinatorial complexity by making them scalable, accessible, and ergonomic without having to rebuild everything from scratch.

Designing for what happens in front of the screen

UI is what appears on the screen. UX is what happens in front of it: what users actually experience. Designing UX means anticipating what interfaces will provoke in people before deciding what elements to display.

The real context of applications has long ceased to be the monitors they are designed on, or the conference room projectors where they are approved. Today, moreover, digital transformation has placed screens everywhere: on vehicle dashboards, industrial consoles… and in pockets and bags, ready to enter any environment that didn’t have one yet.

If you want your App or design system to respond better to what happens in front of the screen, let’s talk.

The entry Dark Mode vs. Night Mode: different approaches to different problems was first published on Kambrica.

1. What “brand color” did the board actually buy?

When a board approves an “institutional color” in a brand guidelines presentation, they rarely approve a simple PNG with only this as its content:

Nowadays, it is customary to approve a mockup with different samples, convincingly simulating how the brand would work in the real world: with volume, lights, and shadows.

Like what is shown below (one of over 1,000 presentation templates offered by GoldenPixelStudio). In the IPAX simulator, the crosshairs indicate the actual value of each pixel. Moving them across the brand book, we can see that no two areas that appear to be the “same color” measure the exact same value.

If the approved brand book wasn’t a flat square, the approved brand was never an exact color.

And that is not “wrong.” It is the reality of a brand living in the real world. “Exact” values are a convention for print, not an expression of identity.

2. The natural variation of print

The historical purpose of color specifications is to define an ink specification to prevent two brochures from having different logo colors (e.g., one blue, another purple). But that specification does not mean the color will always look identical.

The following simulator, developed as part of the IPAX system, allows you to select the paper type and active lights to see their effect on the ink (a CMYK C20 M0 Y80 K10). For natural light, you can choose between sunrise, noon, overcast, etc.

That variation in perceived readings—not only in its code but also in the color name (according to the ISCC–NBS standard)—is completely normal and expected for any brand operating in the real world.

3. Test how color in your Design System works

The following simulator allows you to edit the “brand ink” (click on the first sample, or edit the #value), and see how it appears across different paper types and screens with varying qualities and brightness levels.

Artificial lights can be moved around, and they also affect screen rendering.

What does this mean for your brand?

The issue isn’t that color varies, but rather when brand guidelines and interfaces ignore that variation instead of governing it. A single code cannot handle the complexity of all use cases of color in design systems.

Just as brand colors adapt naturally in every scene, a Design System must resolve variations to ensure legibility and accessibility across different contexts (light mode, dark mode, continuous reading, high contrast).

To solve these challenges, at Kambrica we developed IPAX Foundation Layer: a system that allows Design Systems to evolve to meet modern demands, ensuring WCAG/APCA accessibility and scalability.

The IPAX system, which we presented at Rosenfeld Media, derives all Design System alternatives from a manageable set of concrete decisions, with an architecture of color and typography that is WCAG 2 / APCA accessible by construction.

If you want to learn how IPAX can help your Design System, let’s talk.

The entry A brand color is much more than a #01C0DE for a Design System was first published on Kambrica.

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 this kind of clarity can help you 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.

Adoption does not “happen.” It is designed. Before the code.

Navigating blind

If we are at the North Pole, the compass finds no direction: there is no “angle” where north is. And everywhere, there is south.

The same happens in the software industry with a principle that has accompanied us since the beginning: the idea that technology added value by itself.

Wherever there was no technology, we incorporated it. And automatically, we created value. That naturally led to its adoption and better results.

This principle helped us establish direction for decades: first in computerization processes, and later in digital transformation.

The compass that stopped working

Today what happens is that we are already at the North of these processes: there is already a computer on every desk, one in every pocket (mobile), one in every living room and bedroom (smart TV), several in every car… 

So, this principle that was our compass now gives us erroneous readings.

The Copilot case

That is how Microsoft –not coincidentally, the company whose mission was “a computer on every desk and in every home”–, with a top-tier engineering team, a marketing budget comparable to the GDP of a small country, and a privileged distribution channel (system updates), has achieved… a meme:

Copilot is not an exception. It is the warning that the principle that “technology ensures adoption” no longer applies.

It is the tip of the iceberg of thousands of projects we will see this year, whose postmortem will be: “we didn’t do it because it was easy, useful, or profitable: we did it because the enthusiasm for AI made us believe it would be“.

Development and adoption no longer go together.

Today the equation is no longer “more technology = more adoption = better results”.
Today the equation is: “Technology x Adoption = Results”.
If adoption is zero, all effort applied to Technology is waste.

The right question

The question is no longer: What technology should we add?
But rather: What problem are we trying to solve, and what is the simplest, fastest, and cheapest way to validate whether that is a good business?

Adoption does not “happen”: it is designed.
And it is designed before writing a single line of code.
Because every project that starts without validating adoption is a sunk cost.

If your next project still starts with technology, it has already started wrong. Let’s talk first.

The entry Technology does not ensure adoption (and that costs you millions) 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.

There are reasons why things work this way.
They’re invisible until you know about them.

And once you understand how they work, you no longer fall into the trap so easily. You can better distinguish what’s good for you from what’s good for the person selling it to you.

Especially when they tell you it’s “free.”

The entry VibeCorpsing: 80% of the projects you’ll see this year. 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.

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.

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.

It usually happens that the Business hires designers to “design”, and the two parties believe they are talking about the same thing … when actually, the Business is not expecting designers to make design decisions. But, to execute the design decisions that the business already made before calling the designers.

In other words, “make it pretty”.

This type of misunderstanding results not only in frustrations for all involved, but in various forms of waste (understood under the Lean philosophy): transportation (inefficient paper trails and communication failures), overproduction, over-processing, defects and non-utilized talent.

When in Kambrica we began to apply the distinction between design execution and design decisions, we found the space to be able to work those decisions together with Business. And on our projects, we discovered and started working on two more levels, which today are part of our UX consulting philosophy: Business decisions, and Organization’s values.

When design decisions are not supported on business decisions, they are subject to arbitrariness, changes of heart, second-guessing and suspicion by all involved. Common symptoms are that the design “doesn’t cut it”, that stakeholder “doesn’t feel it’s right”. Always there are shadows of doubt whether something else could have been done. Not necessarily better … but different. A situation that is inevitable if the expectation of the Business is that the design will surprise it. Because the surprise of the design being presented, lasts only a few moments. After the first glance, questions and requests begin to emerge, breaking down the basis of the decisions that had been taken up to that moment.

This loss of focus is greatly reduced when design decisions respond to business decisions. These decisions have the form of objectives: what we want to achieve with the project. Or, in Design terms: what problem are we trying to solve, whom are we solving it for, and how will we know if we have succeeded?

This loss of focus is greatly reduced when design decisions respond to business decisions. These decisions have the form of objectives: what we want to achieve with the project.

Sometimes, the proposed design leads to questioning business decisions: that is not only valid, but it’s for us a much deeper and more mature expression of “design thinking” than having a wall covered with post-its.

But we found that with that is not enough. Designing the User Experience requires making decisions about what experience we want to offer to those users. And ultimately, how we want to treat them. These decisions are also arbitrary, and must be expressed in the organization’s values.Without organization’s values aligned to UX, the Business may lose direction and consider decisions that could harm the relationship with its users and customers.

Few organizations have Vision and Mission statements that describe how the organization intends to treat its clients. But those statements, still incomplete, are always the best starting point to achieve those definitions.

Our UX Decision Hierarchy has a pyramid shape, representing that each level must be supported in the previous ones. And it has “UX” as a capstone, representing that although the execution of the design will be the point of contact of the users with the brand, the User’s Experience is the consequence of the decisions of everyone involved in the process.

The entry Hierarchy of UX Decisions was first published on Kambrica.

Introduction

Kongo is a set of tools for enhancing the layout process of complex web applications.

When designing web applications we combine basic standard elements such as text, links or form inputs, to produce custom Components such as navigation menus, shopping carts or products. So every bit of a web application is part of a Component.

These Components are meant to be used in different pages of the application. Moreover, some of them may vary according to the context. That is why an index of Components is so important, and the ability to show all the variations of a Component in a single window is Kongo’s main asset. This allows anyone to apply changes to any part of the application and know instantly how this will impact across views.

Besides maintainability, Kongo provides a good base for reusability, as each Component is isolated from the rest and can be easily exported and used in other projects.

Kongo is NOT…

A web application framework. It is intended for front-end developers.

Download

Compatibility

Currently based on PHP5.

The entry Kongo: Modular Front-End Web Development and Testing was first published on Kambrica.