The Importance of Generalists
Major communication shifts (such as the invention of the internet) have produced human behavioral patterns that take a while to result in any sort of coherence, and far too many people just run on ahead, without thinking consequentially about those patterns and their meaning.
Meaning is what informs value. Context matters.
Far too often, corporations have isolated silos of skill-sets & opinions, and as a result, no one can see the forest for the trees. This is especially true the bigger the organization gets. This can result in not only poor communication within a team, ultimately, it can cripple a design and adversely affect your ability to change rapidly as the marketplace demands. Suddenly, instead of a speedboat, you're on the Titanic with a tiny little rudder, desperately trying to avoid an iceberg, and most people on the ship aren't even aware there's a need to turn. This is why generalists are critical to an organization. They bridge gaps of understanding.
Utilizing a multi-disciplinary approach to problem-solving exploits the special expertise of a variety of players to overcome this challenge, & gets people out of their information silos. It provides more than a product "vision" it creates perspective, which is more humble, flexible, and responsive to change. Therefore, effective software design incorporates, not just engineering, but social and behavioral science, evolutionary theory, chaos theory, ethics, neuroscience, fine art, history, economic considerations, etc.
Erroneous Presumption of Order
Too often in software design, there is a presumption of operating in an ordered, predictable system. However most systems simply aren't that ordered, and how you manage that system is profoundly dependent upon what kind of system you're actually working with. Aspects of chaos always intervene even in highly ordered systems.
Yet the common default position is erroneously THINK you're in an ordered system, and then try to determine the main driver, obtain repeatable metrics, and then that will allow for reliable predictions of future results, and enable planning. But in complex systems, which are heavily influenced by variables like feelings and opinions, the “drivers” are all in motion and dynamically changing to adapt to the system, and vice versa.
To survive in this dynamic environment, you simply must employ exaptation. The use of generic ideas in unexpected ways is key. Managing exaptation ironically requires introducing targeted inefficiencies that allow for innovation, and then creativity can result. In other words, you have to introduce space for play.
First, you must understand how we actually see the world. Most people perceive "reality" based upon partial data recognition.
The challenge of a UX Design is to both recognize complexity, and then assist the user to slow down, and pay attention. If you have a multi-disciplinary approach, you will know that neuroscience research has discovered that you really only consciously perceive 5% of what you’re looking at, and that’s if you’re really concentrating. So therefore, making more information available, doesn’t necessarily give the person more information.
Instead, you need to trigger them to behave in an alert, adaptive way, rather than engineering an approach which tries to boil-down and centralize the cognitive process. Additionally, this must be done in a simple (not simplistic) way that is both appealing to the user, and MAKES SENSE.
If you can’t draw the model of an average piece of software on the back of a napkin, it has already lost its utility. A sense-making model, makes sense.
Co-Emergent Design
Once this is understood, the question becomes how to develop a theory-informed practice, not theory derived from practice. The idea that you can derive design just from user observation is not enough.
So while it may seem counter-intuitive, designs that use sensor networks of users to actually co-create or co-emerge the design itself are typically more productive for everyone. In this method, a large number of people with no contact with each other, make judgments about content in real time – which is manifestly more accurate than polls & surveys. What it reveals is not causality, but dispositionality.
The LACK of contact between participants is critical, because their mere interaction can corrupt the results. There are power story tellers, and viral thought leaders in any system, whether it is a simple or complex one. It's therefore important to recognize these players in a complex system and factor their influence into your design, but not to rely on them too much. By developing testing systems that isolate them in some cases, and then observe the consequences of their inclusion in others, you get a better sense of how things actually work. So in other words, good design is always trying to find new, even sometimes counter-intuitive ways to reach out to & resource users, then derive design ideas from the expressions of their needs/wants.
That means you must take into account the heretics & contrarians as well, and not dismiss their observations. For example, most search algorithms and user research methods tend to produce Gaussian distributions of resulting data which crush outlier events, and those outliers are where opportunity for contextual understanding occurs. It's much better to use attractor landscapes of quant data derived from the users creating dynamic narratives. You have a greater chance of avoiding black swan events with this method.
Creativity Requires Failure
It's exceedingly important to allow a "blue sky" space for people to not just experiment, but also fail safely. Only when you remove personal risk from the calculation, is real creativity possible.
Architect with Emergence in Mind
Caveats to remain conscious of, when building co-emergent software that allows for adaptive complexity:
+ Stop designing applications. Design architectures with objects in which applications naturally emerge from people, interacting with those objects inside those architectures.
+ Strive for theory-informed practice, not theory derived exclusively from practice. The idea that you can derive design just from user observation, is not enough.
+ Take into account distributed cognition by building an initial scaffold of boundaries, but which also allow users to create the narrativesthat are most useful for THEM. The final product will likely not even include this initial scaffold - its purpose is to provide a non-static observational framework that allows for emergent behaviors to take place. From this process, you can determine the most efficient method to achieve the user's goals, rather than trying to engineer perfection, you allow for adaptation, and actually achieve better results.
+ We evolved to tell stories, not read documents. Those narratives have a fractal quality to them that makes them self similar at various levels of society. Unprompted stories generated by users are often the most interesting, and inform the best designs across the board.
+ The desire for determinacy is common and dangerous.
+ Premature convergence on a solution is also dangerous. Don't rush into solutions. Stay open to possibilities.Advantage Nodes
One of the root problems in application design, is thinking about user processes in a linear fashion, when a non-linear, non-destructive approach to performing a set of tasks (and development) has more merit, and is ultimately more efficient. I’m talking about an overall approach to a build here, not just the interface appearance, or user experience. These are fundamentally connected in ways many do not think about.
When designing an application to support a complex set of tasks, we have to understand each phase of a work process in a step-by-step fashion. We find this information out through user reasearch and subject matter inquiries. This helps to establish a baseline of functionality, that enables us to construct easy-to-access, preset layouts for the users that get them from Point A to Point Z and accomplish their goals.
Most applications do this in one fashion or another, which is great, until the user needs to accomplish a custom task. Typically, this means iterating development with new features that are added into additional versions of the software. While this is of course valid and will occur as a matter of course naturally anyway, there are alternate methodologies that offer more flexibility in both design, and development, allowing the functionality of an application to grow, without requiring wholesale versioning changes.
Ideally, what you want to do, is both support all the baseline functionality, while enabling users to do things that you may not have thought of in the initial build, thereby allowing for both user and programmatic flexibility far into the future. This extensibility needs to be clearly thought out from the top, to avoid problems later. You don’t want to have to endlessly refactor the design to accommodate functional expandability, and you don't want to get into a situation where you're endlessly patching the application just to accommodate one-off feature requests.
A more elegant way to achieve this (both in terms of programming and interface). More sophisticated banking, film compositing, and 3D applications use nodes to give the user an explicit path view of any particular process, not just its function. Additionally, users need to be able to change a range of settings globally, as well as being able to customize smaller, more discreet functions. Node graphs are ideal for this.
The advantage of a nodal approach, is that it essentially blurs the lines between what a programmer creates, and what a user does physically in an interface. It’s really just like turning a flow diagram into an actual app. Users like this because it’s non-linear and allows them to create complexity through simple "plug-and-play actions within an interface.
If you think of nodes in terms of a natural language sentence, all we're talking about here are nouns, verbs, adverbs, etc. If a new "idea" or task is required, simply build a new node, with the same look/feel as other nodes, and allow users to plug them in to other nodes. If "Node A" has a function with no relation to "Node B" you can prevent the user from plugging one into the other by color-coding relevant inputs/outputs.
Programmers like the nodal system, because it quickly reveals programmatic bottlenecks as well, in a visual manner. Rather than having to parse a lot of text-based code to find such things, it takes code and bundles it into useful visual blocks, and their corresponding connectors. Problem areas then become self-evident.
This concept can be combined with a dashboard utility, with a nodal representation under the hood, which can be exposed to the user based upon their user profile, thereby allowing you to create custom user experiences based upon job title, seniority, or task requirements. You can then expose that nodal system to advanced users who might need it to perform more complex tasks.
Remember Why You're Building Software
Your software is meant to solve a problem for the user, not just solve an engineering challenge. Everything you do is in service to the user, so be like Tron. Fight for the user.
An analogy might be a simple toaster. The user doesn't give a happy damn how the toaster makes toast. They want a piece of equipment that looks good on their countertop and consistently makes toast "the right way" based upon their choices. The degree to which you deliver that, is a measure of success, not how many features you've loaded up the toaster with.
The job is to deliver:
+ Usefulness
+ Pride of Ownership
+ Control
+ Reliability
+ Confidence in ResultsSomething to be mindful of is the Strathern Variation: "When a measure becomes a target, it ceases to be a good measure."
Many teams get bogged down in Agile frameworks that can give the impression of progress, but not necessarily produce something useful to the client. Even regular delivery metrics/targets can be problematic and can potentially distract from your ultimate development goal. Most such calculations only measure whether you delivered a bunch of stuff, it doesn’t answer the question, “Have we delivered the right stuff?”
Remember, the priority is: Outcomes over outputs. Measure value.