Bookmark Beat: EP 22

Breaking things down into the smallest pieces

Welcome back to the Bookmark Beat 🥁. I took a month off to settle into my new job and to make all the travel that comes with summer just a bit less overwhelming. But with a long break comes a backlog of new thoughts (and new links!) so get ready for a good one.

This month, I'll be exploring why design, like engineering, has a way of seeing the world that can easily confuse the people in our lives… especially our co-workers and customers! I've noticed that we tend to break things down one or two steps further than is required by most professions - which I find as interesting as I do frustrating.

But before we dive into those thoughts, let's check out those bookmarks…

“A” Section: This Month's Bookmarks

We don’t need a boss, we need a process by Miriam Suzanne

We must become a team, united against our work. Our job, together, is to hone and curate that work towards the exclusive vision through continuous questioning and articulation.

When eyesight fades and climbing provides comfort by Lacrux

When her vision began to deteriorate, Seneida found solace in climbing. But it wasn't until she found people like her through climbing that she finally learned to open up and accept her impairment. This film by Janelle Dransfield and Rachel Ross follows blind athlete and Black Diamond product developer Seneida Biendarra as she finds her way on the international competition stage.

Dungeons & Dragons taught me how to write alt text by Eric Bailey

We’ve put the most important thing first. We then supply detail in an order that aids in understanding the main point, and discard information that is irrelevant to the overall concept we’re trying to communicate and mood we’re trying to evoke.

Copying is the way design works by Matthew Ström

Copying helped me develop as a designer without needing to go to design school. For lots of people too young for college-level design programs, or without the means to attend these schools or bootcamps, copying serves the same function.

On Writing Well by Nikhil Bafna

Writing a technical document is surprisingly hard. That is not because of the skill to tell a story. It’s because writing forces a level of clarity that is easy to gloss over while thinking through a topic.

Design doesn't have to end like this by John Voss

Not all jobs that are created by AI will be as stable or well-compensated as the ones they replace. Today’s prompt engineers are yesteryear’s telephone operators. There will be a category of work supporting AI products — helping improve those products — until they can be operated without an intermediary.

The time for designers to learn to code is now by Andy Bell

That’s our job as designers. It’s not to pontificate over design tools and their ever expanding features; it’s to design things for people.

The beauty and drama of video games and their clouds by Christian Donlan

The act of seeing, of noticing. It's a scarlet thread that runs through his book, through the society, and through our conversation about games.

Don't be results-oriented by Nat Bennet and Optimizing For Feelings by The Browser Company

These two are perfect companion pieces to each other. I won't quote them so as not to spoil the excellent writing of both.

Not articles: but cool things from the internet

• Wealth, shown to scale is an interactive data exploration that shows how the richest people in the world's wealth measure up to basically everything

• Climate Zones is another interactive data visualization - this time focused on how unique climates are changing in places all around the globe

• all text in nyc is a search engine that enables exploration of New York City's urban landscape through text.

• Photo Gradient lets you paste or upload a photo to turn it into a beautiful gradient

• Charter is an updated version of a 1987 font that would hold up well on low-resolution output devices of the day—fax machines and 300 dpi laser printers.

• Typeset In The Future broke down all the different fonts in Pixar's WALL•E so you don't have to

• Tetris Font lets you write anything (yes, anything) with Tetris’ falling blocks

• It probably won’t be you is an interactive exploration of our lottery instincts.

• Forrest Brazeal wrote a fantastic song about Return To Office (RTO) mandates

• Radio Garden lets you explore the world's radio stations by clicking around on the globe or selecting from curated lists

That's it for this month's links! If that's not enough for you (or if you just want an endless stream of every song and podcast I'm listening to), check out the “I am” page on my website!

“B” Section: What's the deal with details?

Since joining Equall as its first full-time designer, I've realized just how much time designers and engineers spend talking about details when building software. While I am fully aware of the amount of detail in other professions - like the sheer number of numbers in Accounting or the consideration of the location for every single pipe and cable in Architecture - I'm still surprised by how often a question from myself or another “technical” team member can totally throw off the vibe of a meeting.

For instance, when interviewing a “stakeholder” (our fancy word for “person who doesn't work directly on the product”) or a “user”, I usually ask questions that pick at one or two layers deeper than they're used to talking about. While a team lead or a person outside the product team might come into a meeting expecting to talk about a general plan - with high-level action items coming out for folks to do on their own - I'll instead get specific by drawing out an example of what things will look like after we've completed all of our individual tasks.

Despite being a bit painful at first, this style of meeting does two things that I think are really important:

1. It externalizes the result of the work as one person imagines it so that we can all agree on a shared outcome

2. It highlights areas where we haven't gathered enough information

This second point is even more apparent in a user interview. For instance, after a user has described at a high-level what they do in a given day, I might ask a follow-up question that zooms in on just the first hour. Then I'll ask more follow-ups like “is that the first thing you do in that process? or is there something before that?” and “what do you do if you're unable to…” Often times, the response from users are usually presented with an answer like, “well, I didn't want to bore you with that” or a feeling of fear that I'll judge them for doing something “wrong”.

Humans have a funny way of skipping over the details. Perhaps we've been trained by repeated social encounters that nobody really cares about them. Or that by providing a skeleton of a story we're leaving more room for our listener to connect our experiences with their own.

But when we develop software that is attempting to mimic or replace the work that humans do, we have to really understand what they're doing in the first place. To project our own reality onto a person's story is to distort it. If we let ideas stay at too high of a level for too long, we risk building something that we believe will solve a problem instead of one that actually does.

This is why asking good questions is so important. From Don't Make Me Think to The Mom Test, countless books have been written about how to gather real information from the people we're building for; yet, one thing these books don't cover enough is just how uncomfortable it makes everyone involved.

Whether it's the facilitator of a meeting getting frustrated by going “too far into the weeds” when an engineer or designer grabs a whiteboard marker or a customer wondering why we're asking about how many windows they have open at a time, reactions to this detail-oriented questioning can get pretty awkward.

But these sorts of questions are worth the discomfort.

Without them, we jump to conclusions. We end up building things nobody wants or debating the color of the bikeshed instead of focusing on the main structure. Rather than shying away from these awkward conversations, I think we should just explain ourselves more. We can clue people in by saying things like “by asking this question, I'm trying to understand X” or “once we've drawn out Y, we'll know what's missing to build Z.”

Maybe then we'll garner trust from people who have only been taught that the details are boring or not worth discussing.

Coda: Books I'm reading

Here's the books I've read (or am still reading) this month:

• The Jellyfish is a graphic novel by Boum - a Canadian author and fellow low-vision artist. Their portrayal of what it's like to lose your eyesight was one of the best I've ever read.

• Kafka On The Shore is one of the most surreal depictions of being a teenager I have ever read. Despite this, it remains as accessible and charming as it is confounding.

• Last month I finished one of my long reads - The Silmarillion - and am still working on finishing War and Peace. I now officially have less than 6 hours left in the >60 hour epic and I'm still consistently excited to read Tolstoy's next rant about the futility of violence.

---

I'm afraid this EP has reached its final track 💽! If you'd like some more thoughts before the next newsletter, feel free to ping me in the comments on Substack (or just send me an email).

Catch ya next beat 🥁😎🥁