Lessons about Design Distilled from a Goodreads Challenge

54 insights about design from mostly-not-design books.

In 2019 I read 54 books, coming through the other side of — if I’m remembering correctly — my only resolution made twelve months ago to read 52 books as part of the Goodreads challenge. This was personally ambitious. I learned a lot about how to read, something I’m interested in sharing in another writeup, but my biggest takeaway has been that reading variety is a kind of combinatory play — think: random word association games — and the connections you’re able to draw between totally disparate subjects can be a source of a ton of a-ha moments.

So, here are 54 lessons about design from my mostly non-design body count.

  1. The services we design have a kind of agency of their own.
    The Subtle Knife by Philip Pullman

  2. We waste many good years of our lives caring too much about the quality of design or design thinking in the industry.
    The Witch of Lime Street: Seance, Seduction, and Houdini in the Spirit World by David Jaher

  3. J.M. Barrie introduced fairy dust as a component for flight because in an earlier production where only happy thoughts were necessary, children tried flying from their beds and hurt themselves. Test often.
    Peter Pan by J.M. Barrie

  4. Human language is an open-source service that adapts to jobs to be done in realtime.
    Because Internet: Understanding the New Rules of Language by Gretchen McCulloch

  5. The product is a means to an end that facilitates the service. Sometimes, the service is better served by a different product. In this case, the movie out-serves the book.
    The Exorcist by William Peter Blatty

  6. The key to talking to strangers is a foundation in service design. We are very bad at first impressions, judging strangers, but how strangers act is informed by their world: complex ecosystems of pressures and reliefs - jobs - and the services afforded in the environment.
    Talking to Strangers by Malcolm Gladwell

  7. An okay product in disciplined hands is better than a great product in any hands less than.
    The Revenant by Michael Punke

  8. “Coupling” is a critical component of user behavior. In a moment of grief, you can’t bring someone back from the dead if you don’t have a Pet Sematary in walking distance.
    Pet Sematary by Stephen King

  9. Design twitter: “It’s like a bunch of hipstery academic fucks try to have an adventure, and instead spend most of the time discussing the adventure they’re currently having, instead of actually having it.” From a funny comment on Goodreads.
    The Haunting of Hill House by Shirley Jackson

  10. The key is to just ask for help. Admit it when you’re scared, or out of your debt. It’s okay. Good folks are out there.
    The Art of Asking; or, How I Learned to Stop Worrying and Let People Help by Amanda Palmer

  11. A great service is front-loaded with a metric ton of discovery.
    Fire & Blood by George R. R. Martin

  12. Integrity and foundational design principles are difficult — but not impossible — for an individual to adhere to against nuanced, pervasive external pressures. Good systems of work are a better bet.
    Truman by David McCullough

  13. Our pseudo-scientific approach to design, hypotheses fine-tuned through trial, error, testing, are still at their core make-believe paintings on the walls of cave. Design now serves the same function as design then.
    Midnight Son by James Dommek Jr., Josephine Holtzman, Isaac Kestenbaum

  14. Your product, service, or organization will not only die, it will be forgotten - and you might not even see it coming. Memento mori. Subscribe to Stoic Designer.
    The End is Always Near by Dan Carlin

  15. Read the books your mentors read, then the books their mentors read. Try to understand how your own opinion has been shaped over time.
    How to be an Epicurean: the Ancient Art of Living Well by Catherine Wilson

  16. Meaningful quotes out of context are both motivating behavioral triggers - and lies. Context is the key. Try to avoid repeating quotes or ideas (or trend hype) without understanding wtf you’re saying.
    The Bed of Procrustes: Philosophical and Practical Aphorisms by Nassim Nicholas Taleb

  17. Context is key.
    The Adventures of Huckleberry Finn by Mark Twain

  18. Project managers get paid well to use sticky notes. The tools people use say little about their fitness for the job to be done. Focus on people, not tools.
    Project Management for Humans by Brett Harned

  19. Ask yourself: how much of your process is in place just because it’s common in the industry? Then, ask yourself: does this process actually work for what I need to do?
    Shape Up: Stop Running in Circles and ShipWork that Matters by Ryan Singer

  20. Good design is a value judgment that has a lot to do with the time you’re in. Be sure that the design choices you make actually work for now.
    The Fall of Arthur by J.R.R. Tolkien

  21. The temporal midpoint may be one of the most impactful project management tools at your disposal.
    When: the Scientific Secrets of Perfect Timing by Daniel H. Pink

  22. You too can write novels with a little time management.
    Renegade Star by J.N. Chaney

  23. You too can turn a podcast into a novel with a little time management.
    Welcome to Night Vale by Joseph Fink, Jeffrey Cranor

  24. Deliberate practice will rewire your brain, meaning you can train your mood, or even creativity.
    The Brain’s Way of Healing by Norman Doidge, M.D.

  25. A real danger of distributed systems of work, such as agile at scale, is that you can be engaged in unethical design work and not know it.
    Permanent Record by Edward Snowden

  26. Remember that paleontologists decided the Brontosaurus no longer existed, shattering our childhood dreams - before deciding that, in fact, it did. It is hard to come by objective truth.
    A Grown-up Guide to Dinosaurs by Ben Garrod

  27. Hype, expectation, and convention can mute an otherwise positive user experience. A user-experience is not in a vacuum.
    World War Z by Max Brooks

  28. The best hypothesis is the one that reflexively accepts its potential wrongness to begin with. Klosterman’s razor.
    But what if we’re wrong? Thinking about the present as if it were the past by Chuck Klosterman

  29. Good self-improvement advice earned organically through trials and tribulations are more easily learned by reading the Stoics.
    Unfu*k Yourself: Get out of your head and into your life by Gary John Bishop

  30. In some way, everyone you know - especially those you work with - are strangers.
    The Golden Compass by Philip Pullman

  31. Commit to re-reading books or articles you read — say — ten years ago. You are a different person, now, and you will see things very differently.
    Dracula by Bram Stoker

  32. Deliberately choose the people who you spend your time — especially your time working — with.
    Naturally Tan by Tan France

  33. You will be remembered by your actions - not your words. History, likely, will forget you. Glory is ephemeral.
    The Pagan Lord by Bernard Cornwell

  34. When you are confronted with a new design problem, tell yourself: “good.” Problems are clarifying. They make your decisions about what to do and how to spend your time easier.
    Extreme Ownership by Jocko Willink and Leif Babin

  35. Great content is evergreen.
    Alien III by William Gibson

  36. Victory does not come to people who listen to their fears.
    Death of Kings by Bernard Cornwell

  37. If you don’t read widely, witticisms, pull-quotes, and a tendency to cite sources in conversation will seem profound. If you read widely, you see these for what they are.
    12 Rules for Life by Jordan B. Peterson

  38. Do one thing well rather than two mediocre things.
    Good to Great by Jim Collins

  39. Classics are not sacrosanct and exist to be remixed. Remix them.
    The Song of Achilles by Madeline Miller

  40. Many of the components of your success are out of your control. Those who are wildly successful are so because of circumstances of luck. They are not the ones to learn from.
    Outliers by Malcolm Gladwell

  41. When you innovate successfully, your innovations will become conventions. Given time, your work won’t seem so innovative.
    Salem’s Lot by Stephen King

  42. Very complex award-winning designs probably got those awards because the award-givers couldn’t figure out wtf was going on, but wanted to seem smart.
    The Three-Body Problem by Liu Cixin

  43. The nueroscience of consciousness is mind-bending. When you try too hard to code a service, identify the most granular job-to-be-done, or understand a “user experience,” you’ll find that the physics of your understanding of design won’t hold up.
    Waking Up by Sam Harris

  44. Good service design allows for the product to retire gracefully. The job to be done remains, and a different product becomes a better vector for that service provision.
    Tiamat’s Wrath by James S.A. Corey

  45. “I realize that not infrequently books speak of books: it ias as if they spoke among themselves. In the light of this reflection, the library seemed all the more disturbing to me. It was then the place of long, centuries-old murmuing, an imperceptible dialogue between one parchment and another, a living thing.”

    Memetics. Design speaks of design. It is also important to not get trapped in the altar of design. Design-thinking is a tool, it is not to be worshipped.
    The Name of the Roseby Umberto Eco

  46. There is always a loophole, and always an industry — not just a person — that will accrue around it.
    The Dispatcher by John Scalzi

  47. Stoic Design is definitely the way to go.
    The Manual by Epictetus

  48. Honestly, if you want to see design lessons learned from the Stoics, read my work doing Stoic Designer.
    The Tao of Seneca, Vol. 1 by Seneca (!)

  49. We tend to accept and repeat maxims about actions being louder than words, but words — also — are actions - and they are powerful.
    The Raven Tower by Ann Leckie

  50. Plentiful wells empty eventually.
    The X-Files: Cold Cases by Joe Harris

  51. It’s services all the way down: functions are services, objects are services, sound software composition is good service design.
    Composing Software by Eric Elliott

  52. What stands in the way becomes the way. “Problem” is a perspective, especially in something as — let’s be honest, comparative to the world: — usually low stakes as design work. When you encounter a challenge, whether a bug in the platform or a pain point in a journey, then you can see that as clarifying. You know now what to do: address the problem.
    The Obstacle is the Way by Ryan Holiday

  53. Everyone is a stranger subject to behavioral coupling. It is naive to think you have anything better than an educated guess about how a person will act given a specific situation. Check your biases.
    The Demon Next Door by Bryan Burrough

  54. Your hands look a lot cleaner when you get to dictate where history begins, and what parts of it count.
    Persepolis Rising by James S.A. Corey

This took me a couple of days to write because of some of the mental gymnastics required to mine design insights out — let’s say — The Haunting of Hill House. In some of these cases, like World War Z, my lesson is about the book itself: you’re not going to find lessons about hype in this novel, but hype mutes experience and for as objectively neat and well-composed as that book, I was always waiting for it to rise to expectations.

My main advice is to read widely. Skimming? Go for it. Trash fiction? Awesome. It doesn’t matter. When you read enough, your mind can’t help but draw associations between Composing Software and The Fall of Arthur. These connections, more often than not, are silly, but I hope in this little jaunt 👆 I was able to demonstrate how they can be insightful.

I’m looking forward to another year with you all,
Michael Schofield


Liking (❤) this issue of Metric helps signal to the great algorithms in the sky that this writeup is worth your time. Please take the time. If you haven’t already, please subscribe.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Subscribe to Metric on Apple Podcasts, Google Play, Spotify, Stitcher, and all the usual places.

Remember that the user experience is a metric.


Photo by Ewan Robertson

UX Design is Morally Gray

  
0:00
-2:51

Folks tend to disagree with me whenever I say that user experience design is morally gray: there is no inherent requirement to making user experiences people like and prefer to competing experiences that leave users — morally or ethically — better off. Ethical design is a qualifier.

This is an important distinction and nuance to design work that is critical to accept if we intend to push best practice in a more deliberately ethical direction. It empowers individual designers, teams, companies, entire verticals, even disciplines to differentiate themselves by choosing to design ethically.

Assuming that good user experience design work has good intentions is dangerous — and naive.

This also means we must divorce the relationship by what we do (design to improve the user experience) from how we do it (ethically, or not). It means that to be ethical we must choose to be so at each step of the design process, at each touchpoint between conception and performance of a service.

To frame ethical user experience design like this make it easier to appreciate how difficult it is to create an ethical product or service. Perhaps not by intent — we all think we’re the heroes of our own story — but because the design of a thing is the culmination of a hundred decisions, hard ones. The CEO in the business of providing an ethical service might fail because of decisions made in engineering, or because they chose to design to optimize a conversion metric instead of some other made-up number.

It is for this reason we need to make time and resources available to design the design process, creating systems of checks and balances not just for quality assurance that a button can be pressed, but for ethical stresses.


Liking (❤) this issue of Metric helps signal to the great algorithms in the sky that this writeup is worth your time. Please take the time. If you haven’t already, please subscribe.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for Metric UX in your favorite podcatcher.

Remember that the user experience is a metric.

Michael

Can jobs-to-be-done replace "Front End Developer"?

  
0:00
-6:47

The “front end” is pretty nebulous. What makes a good front end developer? Its definitions, and so its answers, are all over the place. It’s not just the introduction of new front end frameworks that have changed how we talk about it, but in terms of the discipline of designing websites we have begun to think differently: in components, in services. We can see front end in flux in Ernie Hsiung’s “A fictitious, somewhat farcical conversation between me and the JavaScript programming language,” where Ernie as a front end developer — a successful front ender, look at his resume — imagines having an existential crisis because the front end changed while he was busy being a boss (a good one).

Our understanding of the front end as a place no longer holds up to scrutiny. We cannot define it by a specific suite of tools, a kind of user expertise, or even that — if anything — front end development requires a browser.

If we talk about the front end in terms of distance from a user, the “front” specifically being the interface between the user and the service provided, then we ought to accept that voice user interfaces (among other examples) challenge the notion that the front end has any tangible component at all.

Even here, we are cherry-picking a particular kind of user, one that is at the tail-end of a complex service provision - presumably outside the “provision” circle of the Venn Diagram altogether. We’ll call this person “end user.” But again, using “front end” as a descriptor of that distance from a user — while accepting there are no constraints on technology or medium (like a browser) — should be applicable to the RESTful API that I design for consumption by a variety of user interfaces. The consumer is my end user. When I design the interface for that user, am I performing “front end development?”

What I am trying to illustrate is that when we are thinking about user experience and service design, paradigms like “front end” and “back end” no longer align with an understanding of service clusters, ecosystems, or - frankly - users. These kind of identifiers are ephemeral and, as such, pose a problem to companies who organize themselves around these concepts.

You long time Metric readers and listeners — “Metricians?” — might find this latter concern familiar. The practice of thinking in services reveals that same ephemeral nature around the product itself, given that the product is just a tool in a larger service provision, it is thus — like a tool — replaceable. Choosing to design organizations around products will shape the way in which said organizations develop, which is probably against the grain of good service design. Hot take, I know.

So, practically, as service providers who make products that require engineers, how do we hire after we thought-spiral ourselves away from terms like “front end developer?”

I think there is an implied solution. In 2017, Rob Schade at Strategyn suggested a new kind of role called the “Job Manager” in “Product Managers are Obsolete; focus on the Job-to-be-Done.” As an alternative to a Product Manager, the Job Manager focused on the design and development of solutions for a given job-to-be-done.

If you need a refresher, a job-to-be-done describes a task where the user has a demonstrable need for the solution you provide. That is, if I need talk shop and further develop my own thinking about service design, a company like Substack provides a solution for my shop-talking need. The product — the newsletter editor and mailer that Substack provides — is a means to an end, not the end, and not necessarily crucial to my job to be done.

In this example, rather than there being a Product Manager in charge of the newsletter editor, there would be a Job Manager overseeing the entire service Substack provides that connects me to you. These circles overlap, but the lens is very different.

I think there is room then for “Job Designers” and “Job Developers.” These are the design workers who, alongside the Job Manager, provide the company’s solution for a specific job to be done.

A huge benefit, you argue, for “front end” is that even if the definition is super loose it implies some kind of big umbrella of skills around which people can identify. Maybe that is, regardless of which framework compiles them, something to do with HTML, CSS, and JavaScript. There is nothing about “Job Developer” that implies what that person does.

I agree. While I think it’s liberating to disassociate the technology from the service provided, it makes this shit hard in a different way.

Rather, I think there’s room for specialization, in the way that “front end” and “back end” are technically specializations of just “developer.” This specialization is also implied by jobs to be done.

A job to be done is composed of jobs to be done. In the job that is “understand the civic role I have in my community,” there is a subsequent job that is “see the agenda for upcoming city council meetings in my email.” There are jobs that imply the interface, so there is a role in the service provision to provide that service to that interface. Make up a title that works. Surely “interface developer” — or, even, “civic interface developer” — has more semantic meaning that “front end.”

That’s sort of about the point where I stop caring and let you all figure it out. Titles. Some projects need only one developer, others need one hundred. Few job titles really hold up to the scrutiny — I’m looking at you, Business Analyst 1 — and “front end” or “back end” won’t solve that.

More importantly, a jobs-to-be-done approach to role-making is still fundamentally about spatial relationship to the user. These kinds of roles are user centric - all of them. Whereas “front end” and “back end” might describe distance from a user, all job-to-be-done style roles imply the user in their very description. Each job solution has a userbase, and so fundamental skills like empathy, data-driven decision making, and user advocacy (privacy, accessibility, usability) are part of each job - regardless of where they are in the stack.


Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky that this writeup is worth a few minutes of your time.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for “Metric UX” in your favorite podcatcher.

Remember that the user experience is a metric.

Michael Schofield

The Temporal Midpoint of the Sprint

  
0:00
-4:41

The two-week sprint is totally arbitrary. We adopt the convention without really questioning the wisdom, but by such dogma of what’s-good-for-the-gander bake someone else’s practice into our organizational infrastructure. The thinking is that two weeks is just about the right time to prototype, test, scrutinize, and deliver a feature. But, is it?

All it took was David Grant raising that question as part of the Facebook Journalism Accelerator about this time last year for those of us at WhereBy.Us to concede the point and, within a week or two, consolidate to one-week sprints. Basecamp, just being Basecamp, shrugs the sprint convention all together, and just published a book that largely makes it clear we’re all just navel-gazing guppies trying to emulate other startups.

Shape Up, that book ☝️, made me question what practical reason do we actually need backlogs, or sprints, which was a refreshing reality check. I admit I find doing away with the backlog compelling - but that’s another writeup. Sprints, though?

While reading about Basecamp’s six-week cycles, it dawned on me that the key feature of the sprint is its temporal midpoint. That is, given any deadline, your activity declines until you’re midway through a milestone before climbing. Why? You realize time is running out.

This is described by Daniel H. Pink as the “Uh-oh Effect” in When: The Scientific Secrets of Perfect Timing:

After the first meeting there is a period of prolonged inertia, then a sudden transition followed by a new, more productive direction.

Human culture is organized around temporal milestones — the beginnings, middles, and ends of things — and so, subsequently, are our moods, hopes, productivity, and the like.

The sprint is an arbitrary division of time we tend to conflate with the timeline of a deliverable, but after about a year of one-week sprints I argue the deliverable is the least important aspect. Rather, the sprint is a structure for sustainably pacing our team’s movement through a service provision by placing temporal milestones at advantageous points.

  • Beginning: the beginning of the sprint is a fresh start. It’s like New Year’s Day. We make good initial progress keeping our resolutions. We’re hopeful.

  • Midpoint: the midpoint of the sprint is the ticking clock. It is, no lie, a stressor. It’s designed to make you go oh, shoot, and be honest with yourself and your squad about your progress.

  • Ending: the ending of the sprint is the dropping of the curtain. Time’s up, we touch base, we fist bump, we move on.

Temporal milestones have different emotional tones and the midpoint tends to be the more anxious. Knowing this, however, allows you to design for those emotions, providing another project management tool for templating a mentally healthy sprint.

For instance, if the anxiety of the temporal midpoint is related to the build-up of to-do items you scramble get on top of, what if we just reduce the number of to-do items? Without reducing velocity, if you cut the sprint in half — from two weeks to one week — you move-up the temporal midpoint significantly, which not only reduces the number of to-do items that got away, but literally reduces the stress period between midpoint and temporal ending.

This is anecdotal but I’ll make a note to check the numbers, but I believe the temporal boon of the one-week sprint is a factor behind the increased “greenness” of the company’s team health. At a glance this feels counter intuitive, because surely one-week sprints equate to higher stress, but the reality is that in that same two-week period we have twice the emotional highs (beginning and ending milestones), and our milestone-related emotional lows are much briefer.


Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky that this writeup is worth a few minutes of your time.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for “Metric UX” in your favorite podcatcher.

Remember that the user experience is a metric.

Michael Schofield

The Service Reactor

  
0:00
-4:57

We pitch this idea of operational user research as a means to scale and democratize user experience design practice across an organization. For decision makers already familiar with our user-centric-business gospel — reminder: aggregation theory demonstrates how the user experience is the differentiator for services that have no cost of distribution (because the internet is free); or: good UX is good business — but are concerned about costs, then all they need to hear is how a few tweaks to the workflow and a Google spreadsheet can get the wheels turning with little to no overhead.

It’s easyish to imagine how making the tools to curate feedback you’re already intercepting (emails, reviews, comments on Facebook) easy to use will over time aggregate a robust catalog of that feedback, which decision makers can use to gut-check their ideas.

That hot return on a small investment is why no-frills ResearchOps is hard to argue against. We often stop our evangelizing there.

The long game is interesting, though. Spin something like this up then take a gander at your organization’s RPG skill tree, where a few experience points and a snowball-effect leads you to the service reactor.

The service reactor is this work-in-progress model to demonstrate how a virtuous user research cycle and a commitment to discovery-validated delivery will generate enough proven insights to power a small city.

That’s a lot of made-up vocabulary designed to just consolidate this shit to a single sentence, so let’s break this down.

  • A “virtuous user research cycle” describes a system where your effort to make sense of some data results in the design of the next test to perform, the results of which return to the system.

  • “Discovery-validated delivery” is a requirement that end-user facing features of a product or service won’t be pursued until their demonstrable need and solution can be proven by existing user research.

A chain reaction beginning by cataloging raw data — survey answers, interview transcripts, a/b results, and so on — creates tactical and strategic insights, some aspects of which require more validation thus foreshadowing the next round of tests. Like a nuclear reactor, discovery-validated delivery creates pressure to perform those tests, which continues the chain reaction.

The chief product of the service reactor are insights that we use to validate our business decisions. At small scales, examples of these insights are:

  • evidence we need to rethink our menu structure because it’s confusing users,

  • indication that users need a way to opt-in to plain-text emails,

  • validation that this call-to-action works better than that one.

But as the catalog grows over time, new patterns emerge among unrelated sets of data, and that compounding value directly correlates to the scale of new insights. These are demonstrable proof that there is need among the userbase for entirely new services, let alone features. What’s more, because the service reactor creates insights as the byproduct of a process rather than insights that are specifically sought-out, the resulting service ideas may be orthogonal to your existing service provisions.

This is the drill maker getting into the business of designing entertainment units*. A service reactor powers the “innovation mill.”

The most important ethic I’m trying to convey with the service reactor is that while it is a vision to motivate an organization’s investment in ResearchOps, it is fundamentally user centric. Over time, there is no part of a service or product that is not derived from user research. The reactor ionizes the air with user centricity. You can’t help but breathe.


Note: The drill metaphor is one of the core fables to the jobs-to-be-done approach to design thinking. It basically explains how the drill-maker that is most successful when their drill is an aisle filled with other drills is the one who realizes that people aren’t buying a drill but the mounted television on the wall. The drill is a means to the end. What I’m saying is that an orthogonal business for the drill-maker is in entertainment units: both drill and furniture are means to an end when the job-to-be-done is to relax in a finished living room.


Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky that this writeup is worth a few minutes of your day.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. You’ll find it in your favorite podcatcher.

Remember that the user experience is a metric.

Michael Schofield

Loading more posts…