Test

Product is 99% perspiration, validating the specifics and sweating the details. It’s tempting when starting a project, to be seduced by inspiration and moreover substitute it for the tireless work of research, prototyping, validation and communication.

But the problem with inspiration is that it’s deceptively vague. Once subjected to the specifics of audience, feature set, scale, effort, marketing and so on, things start to look very different.

What usually remains is the motivation to solve customer problems so why not start there? Sure a solution might spark action but mileage varies.

Since starting a new role last year, I've picked up a lot more ownership at work, from product shaping to release. As my role shifts between design and product, I've had to reconsider how I prioritize my week. A simple variation on tracking my week, I use an LRT prefix on tasks to clarify my intuition. There's dozens of jobs that need to be done each week and treating them as equals is a fools errand.

L: Leverage work. Prioritize the time and space for this, it might be a value driver or unlock the team. R: Required work. These are things that just need to get done. Give yourself permission to be mediocre. T: Task work. These are barely worth doing. Ideally defer, delegate them or skip it entirely.

Coming from a large organization, one of the things I've had to unlearn is doing things that scale. In early stage companies you often try things that don't scale, until you validate a solution. It doesn't help that one of design's big contributions in the last decade is systems that scale. Beyond design tokens, trying to artificially uphold design consistency can hamper the experiences you design, especially early in a product's lifespan when you don't yet know what experiences will stick. I have a sticky on my desk that reminds me, "Design things that don't scale."

Knights of San Francisco hints at what Interactive Fiction (IF) could be.

Design is clearly more than implementation details, or so we say. While it's easy to quantify specs and feature releases, it's harder to measure research or obstacles avoided. It probably shouldn't be and design learnings could be tracked but it’s rarely a priority. So the recurring question of should designers code still seems like a misapplication of the role. I code, barely, but enough to understand the domain I work in.

The day to day challenges of software delivery feel less implementation problems and more shaping questions. Less how to build, more what to build and if it’s validated. Designers contributing to implementation rarely make up for poor discovery. The exceptions being microinteraction design and computational prototypes. So if you had to prioritize between a designer contributing towards research, shaping or development, would you still pick the latter?

Twitter stream setup.

Monopolization of the internet and the online behaviors it rewards has been a recurring topic in conversations with friends. So to try and get out from under it, I spent the weekend implementing Indieweb with 11ty on my site. In brief, I draft notes on a micropub client, IndieAuth authenticates my posts which are captured by Netlify functions and posted by a Github repository as Markdown. I like that I can focus on writing and the rest just works with Indieweb.