Use workflow experimentation to challenge design choices

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.

plain text in a nice-but-nerdy editorplain text in a nice-but-nerdy editor
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?