Systems
A new gestalt
Why aim small?
The number of ways in which things work
Inputs and outputs
Taylorism
Sets and systems
Every paper cut is felt
Technology is a system
Technology is not the sum of the artifacts, of the wheels and gears, of the rails and electronic transmitters. Technology is a system. It entails far more than its individual material components. Technology involves organization, procedures, symbols, new words, equations, and, most of all, a mindset.
Notes on the Legibility War
An Article by David R. MacIverThe basic idea of legibility is that the act of making something comprehensible enough to control is itself an act that shapes the thing to be controlled, often with far greater consequences than the control itself. This is because it removes complexity that is deemed as irrelevant that makes it harder to control, and that complexity may be in some way essential to the health of the system.
Primitive design
An Article by Matt Webb- I want it to feel intuitive
- I want any new features to be platform features, not one-offs.
And the second of those is weird, right? It’s like sketching out a toy spaceship, having a list of rules about play, and attempting to simultaneously invent the shape of the Lego brick.
That’s platform design I suppose. Redesigning a newspaper will mean bouncing between comps and style guides, designing both. Inventing the iPhone user interface will have seen apps and app paradigm evolving together.
Design Systems, Agile, and Industrialization
An Article by Brad FrostI’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
In these structures, people are stripped of their humanity as they’re fed into the machine. It becomes “a developer resource is needed” rather than “Oh, Samantha would be a great fit for this project.” And the effect of all this on individuals is depressing. When people’s primary motivation is to move tickets over a column, their ability to be creative or serve a higher purpose are almost completely quashed. Interaction with other humans seems to be relegated to yelling at others to tell them they’re blocked.
Reading “AS PER THE REQUIREMENTS” in tickets makes me dry heave. How did such sterile, shitty language seep into my everyday work?
When Customer Journeys Don’t Work: Arcs, Loops, & Terrain
An Article by Stephen P. AndersonThinking [in terms of loops and arcs] allows us to let go of a specific journey or sequence, and imagine dozens of scenarios and possible sequences in which these skills can be learned. This doesn’t mean there aren’t more fundamental skills that other skills build upon, but we can let go the tyranny of how, precisely, a person will move through a system. We’re free to zoom in and obsess on these loops, which does two things for us:
- Approach the design of a system as the design of these as small but significant moments of learning.
- Consider the many ways these loops might be sequenced, with the exact order being less important.
Stress systems
An Article by Ethan MarcotteThe [Lake Erie] ecosystem underwent a series of changes, each of which were related. There was an increase in the human population; which led to higher phosophorus levels in the water; which led, at last, to an increased level of algae in the lake. In effect, Lake Erie’s ecosystem was rewritten. Changed by human activities into…something else.
But Franklin cites the study because it’s doing something slightly novel: applying Selye’s principle of stress to ecological systems, suggesting that they are, much like humans, just as susceptible to external stressors. And I’ve been thinking about that a lot lately, especially this week. Because Franklin’s suggesting that the work begins not by “fixing the system.” Rather, she suggests it’s about shifting the priority a little: to removing whatever stress you can.
The Art of Systems Architecting
A Book by Mark W. Maier & Eberhardt RechtinThe design systems between us
A Talk by Ethan MarcotteIn the early days, design systems promised us more consistent interfaces, more collaborative teams, and improved shipping times. While they’ve certainly delivered on some of those fronts, they’ve introduced new challenges too. Let’s talk through what’s working well—and what could be working better—as we take a closer look at the systems between us and our work.
Design System as Style Manual With Web Characteristics
An Article by Dorian TaylorIn my opinion, what makes a designer competent is precisely their ability to credibly justify their conclusions. If you can’t do this as a designer—no matter how successful your results are—then neither I nor anybody else can tell if you aren’t just picking things at random.
What I am proposing, then, is no less than to make a designer’s entire line of reasoning a matter of permanent record. On the surface is the familiar set of prescriptions, components, examples and tutorials, like you would expect out of any such artifact. Attached to every element, though, is a little button that says You click it, and it tells you. The proximate explanation will probably not be very satisfying, so you click on the next until you get to the end, at which point you are either satisfied with the explanation, or you aren’t.
Now I get it
An Article by Ralph AmmerTo design a system means to orchestrate the interplay of its elements.
Such a system is considered “interactive” if it is open, which means that there are ways to engage with the processes that are happening inside of it. There is of course a range of interactivities which spans from very basic reactive behaviour to highly complex conversational interactions.
A Plea for Lean Software
Software's girth has surpassed its functionality, largely because hardware advances make this possible. The way to streamline software lies in disciplined methodologies and a return to the essentials.
Measured by the number of its features
A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want. Any incompatibility with the original system concept is either ignored or passes unrecognized, which renders the design more complicated and its use more cumbersome. When a system's power is measured by the number of its features, quantity becomes more important than quality. Every new release must offer additional features, even if some don't add functionality.
Essential vs. nice to have
Customers have trouble distinguishing between essential features and those that are just "nice to have." Examples of the latter class: those arbitrarily overlapping windows suggested by the uncritically but widely adopted desktop metaphor; and fancy icons decorating the screen display, such as antique mailboxes and garbage cans that are further enhanced by the visible movement of selected items toward their ultimate destination. These details are cute but not essential, and they have a hidden cost.
/
Increased complexity results in large part from our recent penchant for friendly user interaction. I've already mentioned windows and icons; color, gray-scales, shadows, pop-ups, pictures, and all kinds of gadgets can easily be added.
Dependence is more profitable than education
A customer who pays—in advance—for service contracts is a more stable income source than a customer who has fully mastered a product's use.
Customer dependence is more profitable than customer education.
What I find truly baffling are manuals—hundreds of pages long—that accompany software applications, programming languages, and operating systems. Unmistakably, they signal both a contorted design that lacks clear concepts and an intent to hook customers.
The most rewarding iterations
Initial designs for sophisticated software applications are invariably complicated, even when developed by competent engineers. Truly good solutions emerge after iterative improvements or after redesigns that exploit new insights, and the most rewarding iterations are those that result in program simplifications.
Evolutions of this kind, however, are extremely rare in current software practice—they require time-consuming thought processes that are rarely rewarded. Instead, software inadequacies are typically corrected by quickly conceived additions that invariably result in the well-known bulk.
Never enough time
Time pressure is probably the foremost reason behind the emergence of bulky software. The time pressure that designers endure discourages careful planning. It also discourages improving acceptable solutions; instead, it encourages quickly conceived software additions and corrections. Time pressure gradually corrupts an engineer's standard of quality and perfection. It has a detrimental effect on people as well as products.