I’ve spent the last two weeks in San Francisco, onboarding at Spoke, where I’ve joined as Senior Product Designer.

Spoke is an AI-powered ticketing and knowledge management tool for IT, HR, and any other team you can think of. Rather than directing your requests to a person, it figures out if it already knows the answer and surfaces the relevant knowledge. It’s impressively smart, and getting moreso all the time.

I’ll be continuing to work remotely from the Hudson Valley, traveling to the SF office a few times a year. It’s not a bad place to spend some time:

More to come!

I was interviewed for User League, a new online publication from Dave Martin, principal designer at Automattic.

This quote sums up what I believe about design:

I like to think of design as a form of hospitality — we’re creating digital environments in which our users will live for a time. Those environments should make our users feel comfortable and confident, and enable them to do things they couldn’t otherwise do. A good product gives the user superpowers without drawing too much attention to itself. It’s better to leave the user thinking, “Hey, I’m awesome” than “Hey, that product’s awesome.”

Thanks, Dave! Head over to User League to read the full interview.

“Can you make sure they add sounds to the next version?”

I’m standing in an aisle of a Wal-Mart in suburban Florida, scrambling to open up my notebook as the rest of my team walks out the door onto the bus. I’m still not entirely sure what’s going on, but the guy in front of me looks frustrated, so I’m pretty sure he’s about to tell me something valuable.

It’s the end of 2015; I’m doing UX work at a small agency, mostly for Fortune 500s who are trying to make their internal tools a little less horrible to use. On this project, I’m traveling around the country with a small team, shadowing merchandisers from a brand-name consumer-goods company as they drive to different stores and stock the shelves with their product. It’s just me, my project manager, and three consultants from a gigantic consulting company.

We’ve just finished shadowing this particular merchandiser and are getting ready to leave for our next stop. I’m the last one out of the aisle, and the merchandiser we’ve been observing pulls me aside.

“I’m not sure if you can do anything about this, but I’m having an issue with our new app, and I think other people have been having an issue too.”

TL;DR — The Dwell player was getting cramped, so when the time came to add some new functionality, I redesigned it to be more usable and better organized.

This is the story of how the new player came to be.

At Dwell, we use Hill Charts, a project management tool developed by the folks at Basecamp and built into Basecamp 3.

What are Hill Charts?

The basic premise is this:

To-do lists are imprecise (what does it mean for a project to be “42% done?”), so we need a visual representation of progress. A Hill Chart is a subjective visualization of progress in which each to-do is a dot positioned on a hill. The left side of the hill is for figuring out the unknowns of a project; the right side is for implementing the knowns.

The left/uphill side is for problem-solving, consideration, and figuring out uncertainty. The right side is for execution, implementation, and confidently taking care of the knowns.

Note: For more about Hill Charts beyond my oversimplified explanation, you can read Basecamp’s article, or watch this video from Ryan Singer (also embedded at the end of this post).

What’s Good About Hill Charts

I’ve found it helpful to have a visual representation of where we stand with different tasks, even (especially) if that representation is subjective. Hill Charts maintain a history, so you can scroll back and see the progress that’s been made in different places.

I haven’t done this, but I suspect that if I looked at the history of all of my tasks and projects, I’d see overconfidence at the beginning tapering off into realism as the dots get closer and closer to the end. Lots of progress in the “figuring things out” phase, followed by the realities of implementation bringing me back to earth.

What’s Bad About Hill Charts

Okay, now the part that was promised in the post title. There are some things I don’t like at all about Hill Charts, and while I don’t have a proposed solution, I thought I’d list them here in case somebody has some ideas:

Equal horizontal movement ≠ equal work. Moving a dot 50px on the left side of the chart doesn’t necessarily equal moving a dot 50px on the right side of the chart. It’s possible to go up the entire left side of the hill in a day, but take weeks to go down the right side. The time it takes to figure out the implementation of a task isn’t necessarily the same as the time it takes to actually implement it.

A downward slope implies ease. The “Figuring Things Out” side of the chart moves uphill, making it look like a slog. The “Making it Happen” side goes downhill, making it look easy. “It’s all downhill from here.”

The difficulty slope of each project is different. Sometimes, the figuring-out process is more difficult than the implementation; other times, the implementation is harder than the figuring-out process. There’s no way to express this on a Hill Chart, since the slope is identical for every project.

Progress gets more granular as time goes on. I’ve noticed this in my own usage of Hill Charts, so it could be just me. At the beginning of a task I tend to be overzealous in moving the dot from left to right. I’m pretty confident during the “figuring things out” process, but then once the implementation starts I move the dot smaller and smaller distances. The last portion of a task usually has a bunch of moves of a few pixels each. Maybe I’m just using Hill Charts wrong, or not breaking my work into tasks that are granular enough, but I suspect Hill Charts unintentionally incentivize this kind of usage.

Hill Charts are deliberately subjective, so perhaps this critique isn’t entirely fair. But since they’re specifically paired with to-do lists, I think they should be a more accurate reflection of the actual work it will take to move through a task.

How to Fix Hill Charts

We need a visual representation of progress through a task list. Hill Charts are a start, but I think we need a solution that incorporates some additional attributes:

Variable difficulty slopes. The user should be able to set the slope of the hill. Some projects might have a lengthy, shallow Figuring it Out segment; others might a steep, quick left side but a shallow, lengthy implementation side. Let the user decide.

Flexible difficulty slopes, with history. The initial slopes might be inaccurate, so users should be able to change it on-the-fly. These changes should be rolled into the Hill Chart history, so we could visualize how it’s changed over time.

I don’t know exactly what this solution would look like, but I’m hoping someone on the internet (or maybe Future Me) can help flesh this out into something real.

More About Hill Charts

Basecamp’s excellent Getting Real channel has two videos on Hill Charts as part of a larger series on how they work. Here’s the quick primer:

And here’s a more in-depth explanation with examples:

A Note About Ryan Singer, Product Genius

Hill Charts were pioneered by Ryan Singer, who leads Product Strategy at Basecamp. If you’re interested at all in product work, you should follow his writing and videos — I’ve learned more from reading him than almost any other single product person. His work gives me the same feeling as Ben Thompson’s or Patrick “patio11” McKenzie; it’s like they’re seeing in four dimensions what the rest of us only perceive in three.

Ryan Singer is @rjs on Twitter, and his website is feltpresence.com.

TL;DR — I’m building an iPhone app called Interlude, using the knowledge of Swift I’ve gained by working at Dwell. It’s a small project that will give me the chance to build something start-to-finish, rather than just editing an existing codebase, so I’ll learn more about the overall native development ecosystem.