When best practices can hurt you
Intro
I always start my workshops with a simple exercise: create a weather forecast app, presuming you have an unlimited budget and access to any technology. What would you make?
Without fail, workshop participants would dig deeply into the product features and lose themselves trying to generate solutions without considering the intended users, the context of use, or how to validate their concept. The benefit of agile-iterative-user-centered-data-driven approach is clear, but the application is often murky.
Context-aware design
The product we’re creating does not exist in a vacuum — it lives in the real world and connects users, business, legislation, procedures, micro- and macro-economics, technologies, and numerous unknown agents. This fits the description of a complex system. If you disregard any of the agents when dealing with complexity, it makes it difficult to understand the system, identify the context of use and design user experience. User-context is a model which fuses product-related agents into a continuum. Designing without understanding user-context is like creating the greatest ballet shoes only to realize they’ll be used in a construction site. The term “average user” is a deceptive syntagm: users are not a constant or a homogenous mass, they are real, irrational individuals who might have some similarities in attitude or behavior. The same person can behave differently, depending on their mood, situation, or company. To fully account for behavior, attitude, causality, quantity, sequence, emotional cues or other details about usage context, we can analyze relevant case studies, undertake fieldwork, conduct user interviews, or pursue any other research method where we can probe for specific examples of use. In The KEY Design Process, this is described as the Opportunity segment which consists of Research, Analysis, and Formulation.
It doesn’t matter if we are in Management, Development, Sales, Marketing, or Design, because we’re dealing with complexity the solutions might not be self-evident and the years of experience, best practices, or extensive knowledge may only help us come up with concepts. No matter how coherent, these concepts are conjectures until validated. Generalizations or best practices may be helpful shortcuts when we struggle to find meaning, but if we don’t validate them and turn a blind eye to context, we end up operating on misconceptions. Remember the “3 click rule”? Remember how many times it was debunked in the last 10 years? How about, “users scan from the top left corner”? Except, when interacting with a website, users might scan from the element with the highest visual hierarchy (e.g. the huge text in the cover section) or from the top right corner (because of those “important” notifications) and we don’t inherently scan in F or Z-shaped pattern (the content on those websites from 2003 was just organized in such way).
Amplifying coherent paths
With sufficient understanding about user-context, we can consider possible features or improvements for our product. We couple actionable insight from research with our knowledge, the team’s collective knowledge, or other available information, and follow the path of creativity and coherence to arrive at one or more concepts. The KEY Design Process described this as the Solution segment, which consists of Ideation, Iteration, and Development.
We conduct safe-to-fail experiments, such as prototype tests, smoke screens, A/B tests, data analysis, competitive audits, or unconventional validation methods, to identify the concept with the best chances of success. We want to understand if the user flow makes sense, what interactions to use, how to visualize data, what information to show immediately and what to hide, and how to layout the interface. Experiments provide quantifiable, objective information and act as catalysts, either amplifying or deterring coherence from paths. They can also uncover unexpected solutions or help us understand the correlation between specific user behavior and the experimental outcome.
The above visualization of coherent paths might look similar to a decision tree, however paths are not outcome-oriented. We are not chasing KPI’s or trying to engineer a strategy to reach a goal, we want to evolve a solution from the concepts, as described by Agile methodology. The coevolution between product and users advances as the product improves the user’s well-being and user-context influences the product features. If experiments amplify none of the paths or we notice an impossible outcome, we can conclude that our starting point is dependent on an unknown agent with higher hierarchy, in which case we should take a step back, gain better understanding about user-context, and then adjust or create new concepts.
Ideally, experiments should provide validation as soon as possible, but they might require a considerable effort and amount of time if the initially available information is scarce or the problem we are trying to solve is complex. It’s not always easy to conceive relevant experiment scenarios, but the return on such investment is real because consequently we can operate on facts, see things that otherwise would be easily ignored, prevent the creation of unwanted patterns, avoid countless opinionated discussions, or save business resources from being potentially wasted on the development of a useless product.
Demoting the complexity
After identifying a coherent path with the best chances of success, we can start with product development. Because we know what we’re making, we can focus on the optimization of the product development process and reduce complexity to an ordered system. Optimization can include defining business heuristics and guidelines, automation of various steps in the process, using bots or frameworks, and creating better communication channels. Well defined processes can decrease production time and cost, help in managing fails and edge cases, or simplify the onboarding of a new team member.
The downside of ordered systems is they only work well with predictable outcomes, they tend to break, they have limiting constraints, and they leave no room for experiments or innovation. A common way to streamline development while allowing some slack for experimentation is to invest in a research department. To be effective, a research department should keep note of the business strategy, but it shouldn’t chase metrics or be outcome-oriented. Otherwise, we could focus on creating phones with better buttons, until one day someone creates a phone with no buttons — -and we know how that story ended.
