How each sentence got that way When the work is really complete, the writer knows how each sentence got that way. Verlyn Klinkenborg, Several Short Sentences About Writing intent
Cutting through to the truth The essential thing in the art of epistemic rationality is to understand how every rule is cutting through to the truth in the same movement. Your sword has no blade. It has only your intention. When that goes astray you have no weapon. Eliezer Yudkowsky, Rationality: From AI to Zombies Your intention to cut intent
Flurry and lapse "The process in creating that kind of canvas was like—what?—10 percent action and 90 percent ass scratching. First you prepared yourself, cleaning up and arranging your palette and tools, sweeping the floors, and then finally, when you were ready, you faced the empty white expanse of white canvas and made your first stroke." Lawrence Wechler & Robert Irwin, Seeing Is Forgetting the Name of the Thing One Sees intentcreativitymaking
Input as collage An Article by Austin Kleon austinkleon.com Your output depends on your input, but a lot of your input is random: you’re interested in lots of different things, and those things, occasionally, will talk to each other in your work. Lately I’ve been thinking about being more intentional with input. Thinking about input as collage. Taking the principle of juxtaposition (1+1=3) and using that to guide your input: what weird, seemingly disparate things can you feed your brain that will come out later in a new mix? The input collage can be subject or genre based and even better if it’s multi-media. ...There’s a balance here between feeding your brain intentionally and then backing off and letting your brain do the subconscious work of mixing your inputs together. creativityintent
AI-driven "Design"? An Article by Jorge Arango jarango.com Like a programming language interpreter, GPT-3 translates the designer’s intent from a language they’re already familiar with (English) to one they need to learn (Figma’s information architecture, as manifested in its UI.) This can be easier for a new/busy designer, much like Python is easier and faster to work with than assembly language. But that’s not “designing” — at least not any more than compiling Python code is “programming.” In both cases, all the system does is translate human intent into a lower level of abstraction. Sure, the process saves time — but the key is getting the intent part right. I’ll be convinced the system is “designing” when it can produce a meaningful output to a directive like “change the product page’s layout to increase conversions.” aidesignintentabstraction
Your intention to cut A Quote by Miyamoto Musashi The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy’s cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him. Rationality: From AI to ZombiesCutting through to the truth warintent
Product vs. Feature Teams An Article by Marty Cagan svpg.com This article is certain to upset many people. Empowered product teamsViability, usablity, feasibilityWhat went wrong? featuressoftwareagile
Empowered product teams When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
Viability, usablity, feasibility In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us. However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap. What went wrong? teamwork
What went wrong? If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong. Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question. And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question. Viability, usablity, feasibility