The Haystack

Designing in public, iteration 3

2026-10-02T00:00:00Z

This iteration: updating the Now page, moving the Designing in public message to a temporary new home, and adding a recent posts block to the home page.

In iteration 2, I made a small set of design tweaks that had a big impact on readability. These changes aren't final. I'm "sculpting" a bit. Again, I'm not maintaining a todo list; things stand out to me while looking at the website as a whole, and I just decide on what I'd like to do next, and I'm jotting down some of my thinking and methods as I go.

Compared to iteration 1, iteration 2's improvements to text column width and line-height make a big difference.

And since showing code is a normal part of the website, using the Emacs package htmlize and a little bit of CSS yields passable syntax highlighting.

The colors generated by htmlize came directly from the color theme I'm currently using in my text editor: ef-dream, one of Protesilaos Stavrou's wonderful ef-themes.

Updating the Now page

My Now page wasn't really "now", as I wrote it five years ago. (That unsettles me in more ways than one. Also, dates are important.) Derek sent me multiple emails (likely automated) asking if I was ready to update it. Apparently, I was not. But now I am.

What I started debating, is whether I should keep old Nows. It appears that Derek doesn't do it, but I saw that Maggie Appleton does, which made me pause. Her approach creates a timeline.

After a brief internal debate, I settled on Now having a single purpose: to talk about what I'm doing right now, and replacing the content with each update. While I enjoy Maggie's timeline approach, I prefer the pointed purpose.

Putting the designing in public message in its place

I won't be writing this series forever. (Or will I? Last time I only did two parts 🙈.) And while I'm doing it, the message telling everyone why the site's content and design is wonky needs to be somewhat prominent, but also out of the way. A cheap way to get that hierarchically "correct" is to put it in a banner of sorts up against the top of the page. Putting it there would be pretty standard, I'd say, but there's good reason for it. Putting a banner slightly lower puts space all around it. That space would create a form of emphasis, and likely more than it deserves. Against the top of the page, there's a slight blending with the browser chrome, which hugs it on three sides. This gives the balance I want between attention and a sense of being part of the periphery. As for the color, I haven't chosen a palette yet. A color from the code syntax highlighting should work well.

.banner {
    margin: 0;
    background: #8fcfd0;
    color: contrast-color(#8fcfd0);
    text-align: center;
    padding: 0.5em;
}

The CSS contrast-color function returns either white or black, whichever contrasts enough with the background. Here, it returns black. The text is centered, and we give it a bit of padding.

I moved the banner up in the HTML, and I decided to give it its own grid-area.

  body {
      [...]
      grid-template:
          "b b b" auto
          "h h h" auto
          ". c ." auto
          "f f f" auto / 1fr min(70ch, 100% - 4rem) 1fr;
      [...]
  }

.banner { grid-area: b; }

Manipulating a grid with the template syntax is designer-intuitive and quick. What I like most about it is that it feel more natural to me than the row and column syntax. That feels too much like a carryover from tables (though it is useful at times).

The hard part: recent posts

As I mentioned in iteration 1, one of my goals with this project is to learn Emacs lisp for the fun of it. I have a long way to go. A simple function might have me searching docs and the web for way too long, only to have me forget exactly what something does or why I chose to do it that way.

As I write this, there are two places for which I collect a list of posts: the archive and the feed. So I write a function that does almost the same thing, but takes only the last n number of posts. Here's the bit from the archive layout function:

(defun haystack-layout-archive (posts)
  "A layout that loops through POSTS to create a full archive page."
  (let* ((only-posts (cl-remove-if-not #'haystack--post-p posts))
         (sorted-posts (sort only-posts (lambda (a b)
                                          (string> (plist-get a :date)
                                                   (plist-get b :date)))))
         (items-html (mapconcat #'haystack--format-archive-item sorted-posts "\n")))

    [...]

This takes a list of content (which I now see that I've annoyingly already called "posts"; I'll fix it later), applies the predicate haystack--post-p to make sure it's only a list of posts, and then sorts the list by descending date. Then the list is formatted into the HTML I want.

Any programmers out there will think what I just realized: I'm repeating the creation of a list of posts two times, once in each function that needs it (archive and feed). Doing it for recent posts makes that three times. This is not DRY. It's also why I don't call myself a programmer. The problem is, now that I know this, I'm doomed to eventually make a make-a-post-list function and have the other functions make use of that. Should I do it now? Nope, don't want to. Oh, but wait… if I don't do it now, that means generating the website creates three lists and sorts all three. Dammit!

(defun haystack--sorted-posts (db)
  "Return a newest-first list of posts."
  (sort (copy-sequence (cl-remove-if-not #'haystack--post-p db))
        (lambda (a b)
          (string> (plist-get a :date) (plist-get b :date)))))

This is essentially the repeated code, but put into a function, and using a copy of the list instead of changing the original list. This allowed me to remove the code from the functions that build the archive and feed. db is basically a list of all the site content.

Now that this function is separate, I created a global variable for db and then a function for recent posts, so I can use those from the template.

(defun haystack--recent-posts-block (posts n)
  "Return an HTML list of N most recent POSTS."
  (concat "<ul class=\"recent-posts\">\n"
          (mapconcat #'haystack--format-archive-item
                     (take n (haystack--sorted-posts posts))
                     "\n")
          "\n</ul>\n"))

I read that there's an Emacs lisp convention for function names. I'm still getting used to it. But the convention seems to be that the first part is a namespace (here, that's haystack, so the function is related to this website), and if you use one dash after that, the function is public and can be used outside of the package. (For example, I can call it from within my editor while I'm working.) Two dashes means it's an internal helper, and only used within the context of the package.

So now, the home page template can call the function:

(haystack--recent-posts-block haystack--db 3)

Oh, by the way, to compress the images I'm including here, I just run optipng on them from within the images directory:

optipng -o2 public02*

Also added a missing space between the date and the post link in post lists.

Until iteration 4!

Designing in public, iteration 2

2026-09-29T00:00:00Z

Today: A few design principles and some temporary readability interventions.

Some design principles to get started

There are a couple of design principles that I almost always apply, and I'll do my best to apply them to this project:

Add only what's needed. This was the principle behind my former consultancy Zero Interface. The ideal UI is no UI: you think something and it's done. Stay as close to that ideal as possible. Designers talk about removing the unnecessary. I think it's better not to add it in the first place. Think in terms of additive sculpture.
Design from the content out. What your content and functionality need, in addition to any other constraints you have, inform your design decisions. In a sense, they "tell" you what they need. But in order to hear them, you need to start with the content.

And I'm applying one more specifically for this project:

No roadmap and no backlog: I have no plan. I have enough roadmaps and backlogs at work. With a personal project, there's no need. I'll be "listening" to the content as I mentioned above, but I also might be inspired by different sources along the way. We'll see. Refactoring is a part of the work.

What the content says: readability

Here's how the end result of iteration 1 looked:

I'm writing about this process, so it must be readable now, even if I might make different decisions later. First thing is to change the font to a generic sans-serif (I don't like the default serifs much), and give ourselves a reasonable text column.

body {
    font-family: sans-serif;
    display: grid;
    grid-template:
        "h h h" auto
        ". c ." auto
        "f f f" auto / 1fr min(70ch, 100% - 4rem) 1fr;
    background: #faf7f3;
}

p { line-height: 1.4; }

body>div { grid-area: h; }
main { grid-area: c; }
footer { grid-area: f; }

I'm using CSS Grid here even on this simple layout intervention, because I know I'm going to use it later. I've set the main text column to 70 characters or the full width minus 4rem, whichever is smaller (for e.g. phones). I'm not worried about anything outside of the main content area yet. I also set the background to be not-quite-white. And finally, paragraphs are much easier to read with more spacious line-height.

Not pictured here: a couple of lines to remove the default margins on <figure>, and to give images a max-width of 100%;

Code blocks

Since I'll be showing code often, it will be easier to read with some syntax highlighting. A package for Emacs called htmlize takes care of adding classes to the HTML that correspond with the text decorations in my editor. As a bonus, it makes it possible for me to export the exact colors my editor's theme is using, so I get a decent result without having to think about it. I can change these colors later when I choose a more robust color palette. Running (org-html-htmlize-generate-css) from within Emacs provides me with all the CSS I need with the right colors. I can adjust these at any time. Here are a few, as an example:

.org-comment,
.org-comment-delimiter {
    color: #a0a0cf;
    font-style: italic;
}
.org-string {
    color: #f3a0a0;
}
.org-keyword,
.org-css-property {
    color: #deb07a;
    font-weight: bold;
}

This should make code more readable than it was. Just a handful of little interventions yield big improvements. I love finding and applying those; they add up over time.

Until iteration 3!

Designing in public, iteration 1

2026-09-28T00:00:00Z

Work is done for the day. Cooking's done. Dinner devoured, kitchen clean. and I'm seated here, laptop on lap and tall glass of water at hand. And I am excited.

It's been four years since my last blog post. There are reasons why, and they're hard to express. I'll do that in time. Well, I can tell you about one of them right now: a bit of software called WordPress.

Writing my own static site generator

This website, which at the time of this writing has only the default browser styling, used to be published via WordPress. I would log in and type out a post in a rich text editor that I didn't like. Said post would be displayed in a slightly modified WordPress template that was made by someone else. Because I couldn't be bothered to wrestle with WordPress when what I wanted to do was write something. As a designer, I also like to design, but I'm particular about the constraints I'm willing to accommodate for personal projects.

Now there's nothing wrong with WordPress. But for me personally, it created enough friction that I didn't want to design on it, and I disliked writing on it (or copy/pasting into it). It didn't feel like self-expression to me.

I wrote on my now page (which, yes, I need to update) that I would use Eleventy. But I decided that writing my own generator would allow me to keep it as minimal as I like, program it to do exactly what I want it to do, and it would allow me to learn along the way.

Self expression, learning, and writing about it

Ethan recently redesigned his website. I think he did a wonderful job of it. It inspired me to finally pick this project idea up and dust it off.

I've been pondering what the most important part of creative work is to me. It's the making that matters. The end result is great, but I'm most happy making.

In the mire of social media, even making seems performative. I don't really see that as making. It's curated. There are no doubts, no mistakes. The kind of making I want to do is the kind that makes me struggle and learn. The kind that feels good when I've tackled something difficult. And I want to log it. For myself, as a kind of journal, but also for anyone who's interested in following all the little considerations and decisions involved in making something for the web slowly, by hand. Why would one do that? For the fun of it. So, I'll be designing this in public, and putting my process into writing.

Is writing performative? Eh, maybe a bit. But I'm also a writer, so I get to do two things I like to do.

First bites

This first post is already longer than what I'll usually be writing, but there are a couple of cool things I want to note before we get this party started. First, I've always loved how Derek Sivers uses short URLs (though I'm using a different method). So, while I've kept the old WordPress URLS (because cool URIs don't change), all my new ones will be short, including this one.

Second, I'll write more about my static site generator in the future. But for now, just know that it's written in Emacs lisp, and this is the build function:

(defun haystack-build ()
  "Build The Haystack website."
  (interactive)
  (message "Starting build...")
  (haystack-load-templates)
  (let ((db (haystack-build-db)))
    (mapc #'haystack-render-post db)
    (haystack-build-archive db)
    (haystack-build-feed db))
  (haystack-copy-assets)
  (haystack-copy-static)
  (message "Build complete!"))

The fun feeling that gives me is mildly disconcerting. But I'm learning Emacs lisp as I go by building this website.

And finally, why Emacs lisp? Mostly because Emacs is the editor I've been using for over 10 years. And I like writing in org-mode more than in Markdown.

I was going to put a screenshot here showing how this post looks in the editor, but I'll do that another time. I don't want to break anything 😉.

The Text Method for determining visual hierarchy

2022-01-06T00:00:00Z

A colleague recently came to me with a question about an existing web project that he had "inherited". His question was about heading levels. HTML only has six, and this project had way more than six. If you removed the headings, there would be very little content left. Due to various constraints, he had limited options to solve the problem, so we had a chat about it. This is not an unusual situation. In apps and websites, it's easy to mistake the visual hierarchy as accurately representing the appropriate structural hierarchy. This particular design's visual hierarchy made many things appear to be headings. But should they be? Ideally, visual hierarchy should reflect structural hierarchy. But it can be hard to see the structure through the styling. The advice I tend to give is a form of designing in text: take the entire text content of the design and paste it into a word processor. Now your job is to make that content work within the context of the text document. No layout, no colors. Just basic word processing styles like headings, quotes, and the like. If the document were your final deliverable, how would you structure it? What would be a heading? What would be a subheading? What would just be body text? What is the linear order? Try to make it so that if you let the program create a table of contents automatically, that table of contents would reflect the content as accurately as possible. I use "Word documents" as an example, but thinking in terms of something like Markdown works just as well. Often, the resulting structure will be much simpler. Stripping the content of its visual context allows you to see it for what it is, examine it, and in turn make more appropriate visual design decisions.

Not all design opinions are created equal

2021-03-25T00:00:00Z

People have opinions about everything. You'd think that after almost 30 years in design, I would get used to that fact. But sometimes it's hard. Many people either forget or don't realize that design is a legitimate field of study. There are things you can learn and understand about design that others don't, just like with any other field of study. But for some reason, the fact that one can have an opinion about design can make them mistake that opinion for expertise. But everyone is a designer, right? In a sense, I agree. Many people can write, too. I'm a writer. But I'm Stephen Hay, not Stephen King. The fact that people know things and do things doesn't mean they know or do them well. Milton Glaser famously said, “I move things around until they look right.” Doesn't that feel like subjectivity? But there's nothing subjective about the amount of knowledge and experience behind Glaser's ability to know when things were right. I would have trusted Milton Glaser with a design problem. I would not trust my dentist with the same problem. Good design choices don't come from anyone with an opinion. Some people will come to you with their opinion on your design decisions. They'll package it as educated advice. They'll base it on something they have seen before, or that well-known companies do. They'll confront you with “best practices”. Their goal is to get you to make the decision related to their personal preference. The discussions will be frustrating and demotivating. If you did the same to them, that would be different. After all, they have lots of experience in their chosen expertise, which is likely not design. These are the people who think “it would look better in hot pink”. (Really, what doesn't?) Other people will ask you questions. They'll try to understand the context of your decisions. They'll kick the tires of your choices by challenging you with what-ifs. They'll ask what you've explored, what you've discarded, and why. They'll question how your design handles applicable constraints. They'll seek consistency. Their goal is to help you make the most appropriate choice for your problem. And they would welcome you to challenge them in the same way. The discussions may be challenging, but they leave you with either confirmation or more options to consider. The opinions of people from the second group are more valuable to you than those from the first.

Dates provide context

2021-03-05T00:00:00Z

I was reading Joel Hooks' article on “digital gardens”. He argues:

“Chronologically sorted pages of posts aren't how people actually use the internet.”

This may be true (unless you spend most of your time reading mail, news, blog posts, or social media). Even so, dates can provide context. Hooks' post (which is worth reading, by the way, as well as his others) is not dated, underscoring his perspective that dates are not as important as we might make them out to be. But there's a difference between presenting by date and including a date. Hooks includes a date in the footer of the website, but it's hard to tell what that date means. I'm not picking on Hooks here. His post got me thinking. Dates are important metadata. When was written? Other articles and information published around the same time might provide insight into an author's line of thinking. People change their minds as they learn over time, so it could be possible to discover how authors' ideas change over time. In articles of an instructional nature, dates can tell us a lot about the relevance of the information provided. Not all writing is evergreen. Omitting dates might offer the illusion of perpetual relevance. Leaving out this important bit of context might mask how current the content is or how often it's updated. Authors are free to do this, of course. That's part of the beauty of web publishing. I don't care if articles are presented by date. But in many cases, whether on “digital gardens” or blogs, I feel I'm missing something useful when I can't find a date at all. (I wrote this at around 17:30 UTC+1 on March 5, 2021, in case you're wondering.)

Design review means asking questions

2021-03-01T00:00:00Z

As design leaders/managers, our tendency during design reviews is to express our opinion of the work. This seems logical enough, as our opinion of the work can be—and for experienced design leaders, often is—relevant, depending on the context and the reviewer's experience. Even so, it can be helpful to be mindful of this tendency, and just hold off on it for a bit. If we just observe first, what do we see? What can be observed and judged, but expressed without the judgement? Expressing an observation and holding off one's view can allow the designer to consider the observation. They'll either have a proper explanation for it, and then we can talk about that, or they might have not even seen what we noticed. Having seen it, they're still free to explore what their revision might be, and the only "critique" that has taken place is their own.

A template for questioning design choices

Expressing observations can be done by asking questions. I've distilled the types of questions I tend to ask down to a template. It can be useful as a starting point to discussion (and follow-up questions):

“I notice [observation]. Can you tell me more about that design choice?”

This seems simple, but there are some powerful things happening. First, there's no direct judgement, but there's still an implication of judgement. This observation—without being explicit about the judgement—encourages the designer to start thinking on their own about what possible issues there might be related to the observation. This might already be enough. Secondly, we're emphasising the fact that what's been observed is the result of a choice. We don't yet know if it was the designer's own choice, but they probably know if it was. Calling out choice means:

If it was their choice, they can either explain it or reconsider it
If it was someone else's choice (e.g. a technical constraint), it can be discussed or challenged.

Focus on choice encourages ownership and emphasises agency. You're not telling the designer what to do, but you are asking about the origin of their choices. This also underscores the fact that there is a large pool of possible choices, and they simply used one of them. This helps create distance between the designer and the result of their choices, which can lead to a more fruitful review since they're less likely to take things personally. It's just about the work.

Be yourself

Don't take the template too literally. The wording should be natural and can be changed to avoid sounding like you're reading a script, but the parts should be there. Here's slightly different wording with the same effect:

“I see that [observation]. What led you to choose to solve it that way?”

and in practice it might sound like:

(Smiling) “I see you've used a hot pink background. Now you know I'm curious about that one! What led you to that choice?”

Please note that generally, designs violating brand standards or design systems are no-brainers. But you should still be curious about those design choices! Maybe the system needs improvement. Maybe the designer found a new edge case. Maybe they saw something you didn't, or know something you don't. Often, you'll need to follow up with more questions. “What happens if ?”, “Have you considered ?”, “What effect would this have on ?” This will usually be enough to allow the designer to start suggesting revisions to address the issue. Of course, when they don't see it, or don't get it, that's when we can help out by providing our own explicit view of the work. Just try to guide toward the solution. Don't dictate it. If you find yourself repeatedly having to dictate design solutions to a particular designer, one of you needs to improve in their work.

Questioning beats answering

The above approach is most useful when the purpose of the critique is as much on learning as it is about improving the work (which should be always, I think). In some rare cases, it can be useful to get straight to the criticism. But in many cases, asking questions empowers designers to grow and discover possible improvements on their own. You might be responsible for the design direction, but allow them the fun part of design: coming up with the specific answers within the space that the design direction affords them.

Use workflow experimentation to challenge design choices

2021-02-24T00:00:00Z

or How Copying and Pasting Made Me Question My Use of Complex Blog Software. I use WordPress for this website. But not for long. A few days ago, I published the first blog post I've written in two years. But that's not the only writing I've done the past two years. Most of my writing has been notes. I write these notes in a text editor. Each note is a separate file in Markdown-ish plain text and I use some nice-but-nerdy software to search, filter, concatenate, and otherwise manipulate these notes as I see fit. This post in my nice-but-nerdy editor More on those things another time. Let's talk about the WordPress thing. That blog post started as a note. Some of my notes are journal-like; I've dropped the idea of different note systems for different types of notes. This was a personal note. And while writing it, I decided I wanted to publish it. When I wrote more frequently on the blog, I would do all of the writing in WordPress. I felt that "notes are written here, blog posts are written there" (meaning in WordPress).

Writing as process, not product

It felt quite different to be writing and then decide to publish rather than to decide from the start, "And now I shall log in to WordPress and create a blog post!" I felt free and I could just focus on getting my thoughts down. It was all about the content. This was a new process for me, and I liked it. My nice-but-nerdy text editor allows me to export this plain text markup into a ridiculous number of formats. I figured the easiest would be HTML. So I entered a key combination, chose HTML as my output format, and instructed the software to open the resulting HTML file in my web browser. It popped up immediately. Plain, structured, unstyled HTML. I copied the contents of the page and pasted it into WordPress' rich text editor. Quick check, and publish. This probably doesn't differ much from how many people publish to the web: using the CMS as a glorified input field instead of as an authoring environment. But it did get me thinking about workflows and systems, the assumptions of each in relation to one another, and how we can experiment with workflows in order to test the assumptions built into the products we make for others (or use ourselves). WordPress is a pretty impressive and complex bit of software. It mailed me this morning that it had updated itself. I get a kick out of that kind of thing. But from the perspective of someone who had just used it as a glorified input field, what exactly needed updating? The answer is: not a lot that needs to be done on a web server.

Workflows inform solution choices

I've been a fan of static site generators for a while, but I've never had an actual reason for moving my personal site to one. I already have WordPress, so migrating is just a lot of work. But I had found a reason. My one-time copy/paste workflow used almost none of what WordPress has to offer that makes working in WordPress itself useful. This workflow, which I like and find intuitive and frictionless, basically nullified the usefulness of the software for me. The way I had used it before was fine, but my workflow changed as I changed my perspective on the writing process. I'll be redesigning this site, and rebuilding it with Eleventy. People will ask, "Why Eleventy?" I will say because Zach and the Eleventy community know their stuff. I will say it's because my workflow has simplified so I want the software to complement that workflow and Eleventy is elegant in that regard. I'll say it's like my copy/paste workflow but without even having to do the copy and paste. And I'll say that it has the greatest logo of any static site generator. I'll write about the process here, long prose or not, not worrying about TLDR's and bite-sized takeaways for the 2x-speed YouTube watchers, but not afraid to put out a short note when I feel like it. Because I'm making this fun for myself again. I'll jot down as much as I can about my design choices and what leads to them.

Uncovering improvements via a workflow lens

There is a takeaway here, though, at least for me. If you're designing or building some kind of digital product (or anything really), there are tons of ways to improve it and test the assumptions that have become embedded over time. One of those ways is to do the mental exercise of throwing away existing workflows and coming up with new ones. Ask users to come up with new ones with you. Ask the question, "If this [product/app/whatever] would magically adapt to your own workflow, how would that workflow look? Walk us through it." Like many thinking exercises, this is one to let loose and have fun with. And then look for patterns in the resulting workflows. What do they reveal to you?

Memento Mori

2021-02-21T00:00:00Z

A topic pops up periodically in some of the books I've been reading over the past year, grabbing my attention and then disappearing under the surface of my thoughts again, in cycles, like some kind of sea creature of consciousness. Memento Mori. Remember you must die. This is something I would rather not think about, having already spent a half-century not yet being dead. But Epictetus, Marcus Aurelius, William Irvine, Ryan Holiday, Derren Brown, and many others have spent time thinking about it, and so have I. Especially over the past year in lockdown. And not just because of the words of these writers. The sense of "running out of time" is pointed. Sharp. It pricks me at unexpected moments. Not because I'm afraid to die, but because of some ambiguous dread about not having accomplished… what, exactly? I'm not sure. Having had a youth with very little, I'm thankful for what I have. I have a family, a home, work. Nothing's missing. So what is that feeling? I think I know what it is. Derek Featherstone wrote a small piece about the fear of becoming irrelevant. I'm sure this is part of it for me. Five years ago, my career transitioned from doing design leadership work from my own companies, to doing this as an employee in other companies. During this time, I practically stopped speaking at conferences. I made no time to keep up with web development on a deeper level. This partially stripped away one of my strong career expertises: the integration of development practices into design processes. Any writing I did dwindled away. My blog had become a ghost town of outdated perspectives. My book, itself appealing only to a very specific audience, went out of print. Ideas I talked and wrote about more than a decade ago were discovered again by others on their own; no one knew about my previous work. It seemed lost. I seemed lost. Then the thoughts came. Ignore the 30 years of experience: how did I get here? What footprint have I left in the field? What do I have to offer? Am I even any good at all? I've climbed to the top of a mountain, only to see a sea of more peaks. All the things I don't know. This focused awareness of being a perpetual beginner, this concern that my work and I matter less as time goes on… these are parts of the feelings I've been having. But there's something else. Something my friend Brad unknowingly touched upon once while poking some fun at me about one of my blog posts:

“I don't always blog, but when I do, it's fucking brilliant.”

I love this because it's one of the best compliments I've ever had. But it has a flip side. Brad's quip reveals my problem: I only put work out there when I think it's good enough. And as a chronic compare-my-work-to-the-greatest-hits-of-others-er, that's not often. This is the problem. Not legacy, impact, fame, whatever (though ego is part of it). It's that I'm happiest as a maker. I need to make things. Design, art, funneling my perspectives into writing, teaching, learning. What stopped five years ago was the making for the sake of making. But also sharing it. Learning is also making, so learning should also be shared, as it inspires more making. It occurs to me that even since college, it never mattered to me what other people thought while I was making things. That only mattered when I wasn't making, and was latched onto what I had already made. That's a mistake. I wonder why I'm writing this. If I should write it. If I should publish it. But I will. And if you're reading this, I have. Because I don't think I'm the only one who has felt like this. I'm not the only one who can feel down on themselves at times, unable to explain that feeling to others. So, if even one person gets something out of this little article, it's worth it. Even if—maybe especially if—that person is me. In much art, process is more important than the end result. The work becomes a snapshot of experience, experimentation, thinking, and learning. This is what makes the work interesting and fun. I want to do this, and I'm starting now. As I learn, I intend to share. If you're reading this and have similar feelings, this might not help you, but I doubt it will make things worse: Create. Share. Memento Mori.

Thinking vs Choosing

2019-09-20T00:00:00Z

This is the first of two articles about critical thinking in design. In part one, I discuss why I feel there's so much “design sameness” on the web, and the drawbacks of our tendency to focus on existing solutions. In the upcoming Part 2, I'll present a model that I've found useful in making more context-appropriate design decisions. My thinking and research on this topic also resulted in a recent conference talk: “I Don't Care What Airbnb is Doing (and Neither Should You)”.

Those who have spent any significant amount of time working in design—or most other creative fields—become aware of an ocean of prior solutions to various creative problems. I don't mean frameworks for developing creativity, ideation exercises, or lessons on how to get out of one's own way and allow creative insight to appear. These are aids to thinking. I mean existing solutions executed by others at some point in time, for any particular type of project. The massive repository of existing work that's easily found by a keyword search in your web browser. Portfolios. Showcases. These are aids to doing. Or copying. There seems to be a tendency to repurpose existing solutions to other people's problems. I propose that this is the main cause of the design sameness that we encounter on the web (and in apps) today. In our (un)conscious attempts to reduce the effort needed to do our work, we've become experts in choosing rather than in thinking.

But, conventions

We rely on conventions because they often provide us with a working solution via a minimum of effort. This may be our natural tendency; Daniel Kahneman has written that the brain is “a machine for jumping to conclusions.” While this may be true, it's this very same thinking that we criticize in those outside of our designer role when they voice their opinion. When they ask, “hey, can we do something like our competitor does?”, we might cringe accordingly. Since when is imitating a competitor a solid differentiation strategy? Yet the moment that person goes away and we're in need of a solution, we're knee-deep in some UI pattern library or Google image search. But we don't always copy outright. We remix. We think tailoring an existing solution to our own problem constitutes a creative solution. (It might, but not always.) Worse, we tell ourselves stories. We justify our choices by conflating ubiquity with appropriateness. The fact that many people do the same thing doesn't always mean what we think it does. It could just mean that lots of people copy what other people do. We seldom really know. Many designers talk about using “social proof” to influence customers, yet we allow that same principle to influence our design choices. The more we see something out there, the better it must be. We owe it to ourselves, our customers, and each other, to think critically. To carefully examine and be honest about why we make the “creative” choices we do. Behavioral economist David Hirshleifer describes this phenomenon in his 1997 paper Informational Cascades and Social Conventions¹:

With many individuals, with virtual certainty a point is reached where an individual rationally ignores his private information and bases his decision solely upon what he sees predecessors do. The accumulated evidence from predecessors outweighs his private information. The decision of this individual n is uninformative to later choosers. Thus, individual n+1 is no better informed than individual n, so she joins the cascade.

When discussing this with designers, I often get a response like, “So what? What's wrong with using proven conventions?” Very recently, a designer told me that they'd like to see more designers looking at what other companies are doing, rather than coming up with their own unproven ideas. I tried to reassure them that they needn't worry: there's no shortage of designers looking at existing solutions. The entire web serves as sufficient evidence of this. And it's nothing new. Early in my career, when I worked in print design, most designers I knew would reach for their collection of design annuals—collections of design work done in a given year—to “get inspired” when starting a new project.

The basis for our decisions

When we use existing solutions or patterns, we use a different kind of thinking. Our focus is on finding which pattern will work for us. Too quickly, we turn our attention away from closely examining the problem. Deeply understanding a problem, ignoring the solutions of others (or generic solutions) at first, and ideating one's own solutions becomes a process of learning. You learn why something will or won't work. Simply applying a known pattern because “users know these conventions” involves no increase in your knowledge. You've narrowed the landscape of possible solutions to those others have devised. By extension, you will never be one of those “others”. Sure, you just need to get the job done. Being a forerunner is not required. Learning is not our goal. While this may be true, and while many existing solutions may work perfectly for your situation, there's a more insidious aspect to working this way. As Bent Flyvbjerg states²:

(An) exclusive use of analytical rationality tends to impede further improvement in human performance because of analytical rationality's slow reasoning and its emphasis on rules, principles, and universal solutions. Second, bodily involvement, speed, and an intimate knowledge of concrete cases in the form of good examples is a prerequisite for true expertise.

I often use the example of A/B testing. When testing A against B, the results come from the specific comparison. B might be the best solution, but we only know anything at all about B as it is compared to A. B then becomes the new A, and subsequent choices are derived from that. Perhaps a better visualization is that of a fork in the road. The roads available to you in the future depend on the choice you make now. How are you making that choice? Based on existing work on similar problems, or based on a deep understanding of your own?

Design is hard

The hard part of design is the thinking. When we try to eliminate thinking through imitation, we rely on the thinking of others, and attempt to apply their thinking to our problem. Not only have you effectively outsourced the valuable part of design, but it might not be the best solution for your project. From Bent Flyvbjerg's collection of misunderstandings in case-study research³:

Misunderstanding no. 1: General, theoretical (context independent) knowledge is more valuable than concrete, practical (context dependent) knowledge.

The above quote yields a glimpse into my position on the entire matter: stop focusing on the solution, and start focusing on the problem. You probably know more about your specific problem than the people behind your “found” solutions do. It's a reasonable approach to give this knowledge precedence over the unknown data that influenced the design decisions of others. We often consider something “creative” due to some unexpected juxtaposition of elements. The elements themselves are rarely new or otherwise special. A deep focus on our specific problem and our context-specific knowledge around it can lead to such “creative” solutions, and is a solid start toward creating appropriate design. It might not be what everyone else is doing.

Comments

A Web Revolution

Based on existing work on similar problems, or based on a deep understanding of your own? Design is hard The hard part of design is the thinking.

Footnotes:

Hirshleifer, David A. “Informational cascades and social conventions.” University of Michigan Business School Working Paper 9705-10 (1997): 9705-10.

Flyvbjerg, Bent. Making social science matter: Why social inquiry fails and how it can succeed again. Cambridge university press, 2001.

Flyvbjerg, Bent. “Five misunderstandings about case-study research.” Qualitative inquiry 12.2 (2006): 219-245.