Towards a crap decision You have a thing. You would like to improve said thing. So, you ask a bunch of people what they think, giving more weight to those with relevant expertise. It’s a time-tested strategy. The pitfall here is that if the participants are aware of each other’s contributions, they will almost always automatically switch to consensus-building instead of providing their honest feedback. Worst case scenario: the bandwagon effect gathers steam and drives you toward a crap decision. Baldur Bjarnason, On online collaboration and our obligations as makers of software collaborationdecisions
Adding up to hair-brained I have for myself come to the point where I say that people or groups or governments make the decisions that make sense to them, even if they look totally hair-brained to me. My task then is to figure out the constellation of forces, the pushes and pulls, that in fact do add up to that hair-brained decision-making. Then we can go into the next iteration and say, "What can we do about the balance of the push and the pull that seems to result in totally non-constructive decisions?" Ursula M. Franklin, Every Tool Shapes the Task decisionsrationality
It was all change until the very last second Every work of literature is the result of thousands and thousands of decisions. Intricate, minute decisions—this word or that, here or where, now or later, again and again. It's the living tissue of a writer's choices, Not the fossil record of an ancient, inspired race. Verlyn Klinkenborg, Several Short Sentences About Writing A concept of style decisionscraft
Tracing the answer back I submit that the materials that form the precursors to a product’s implementation have considerable value on their own. My vision is that I will be able to ask a question as mundane as one about the wording of a single button, and trace the answer all the way back to the overarching business strategy to see that it makes sense. Dorian Taylor, Skeleton, Organs, Circulation, Sinew, Skin decisions
Art and science "What the artist does is essentially the same as the scientist. In other words, what you do when you start to do a painting is that you begin with a basic idea, a hypothesis of what you're setting out to do. Then it's just a million yes-no decisions. You try something in the painting, you look at it, and you say, 'N-n-no.' You sort of erase it out, and you move it around a little bit, put in a new line; you go through a million weighings. It's the same thing in science, the only difference in the character of the product." Lawrence Wechler & Robert Irwin, Seeing Is Forgetting the Name of the Thing One Sees sciencedecisionschoice
The complexity and the gray One thing I assume of age is weariness. Damned if I don’t get more tired every day. Tired of what I do, following arcs like lobbed rocks — the inevitability of truth. But the complexity and the gray lie not in the truth, but in what you do with the truth once you have it. Rian Johnson, Knives Out truthlifeagedecisions
The management strategy that saved Apollo 11 An Article by Matthew Ström matthewstrom.com In 1969, the people in charge of Apollo 11 trusted a 23-year-old engineer in a back room of mission control to make one of the most consequential decisions of this decade-defining mission. And they did so in seconds, without deliberating or debating. Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon. Central planning gives poor resultsBeware SAFe, an Unholy Incarnation of Darkness managementdecisionstrust
Goodbye, Google An Article by Douglas Bowman stopdesign.com Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions. With every new design decision, critics cry foul. Without conviction, doubt creeps in. Instincts fail. “Is this the right move?” When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions. Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle. designdecisionsdata
Collaborative Information Architecture at Scale An Article by Brandon Dorn www.viget.com Here I describe an approach for defining new information architectures for large organizational websites managed by many stakeholder groups. Broadly speaking, there are four general phases to the approach: Auditing. Begin by immersing yourself in existing content and encourage stakeholders to adopt a critical, audience-minded perspective of their content. Diagramming. Work with stakeholders to develop new conceptual categories that better serve audiences and organizational direction. Elaborating. Think through content in detail and test new categories against specific instances and edge cases. Producing. Prepare content teams for production using a shared database of new sitemap pages and editorial considerations that you’ve developed incrementally. Half of design is facilitation The Ladder of AbstractionA Pattern Language decisionsorganizationpatternsanalytics
Design System as Style Manual With Web Characteristics An Article by Dorian Taylor doriantaylor.com In 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 Why? You click it, and it tells you. The proximate explanation will probably not be very satisfying, so you click on the next Why? until you get to the end, at which point you are either satisfied with the explanation, or you aren’t. The Design of Design decisionsdesignsystemsstyle
A Plea for Lean Software An Essay by Niklaus Wirth cr.yp.to 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 featuresEssential vs. nice to haveDependence is more profitable than educationThe most rewarding iterationsNever enough time A grossly obese set of requirementsFeatures and complexity softwareperformancefunction
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. featuresqualitycomplexity
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. Menus, Metaphors and Materials: Milestones of User Interface Designlittlebigdetails interfacesux
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 design concept documentation
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. So that you can get feedback on it and make it betterTo anticipate all the uses and abuses agileiteration
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. Deadlines are bullshitThe Thing-deadline calculus