Thread by @geoffreylitt

I'm skeptical that anyone can design truly great software tools if they haven't personally experienced the problem firsthand.

Here's a short story about my encounters with the limits of empathy... (with an optimistic conclusion!)

While in college, I joined an early stage ed-tech startup founded by some classmates. My first project was to design and implement a reporting interface for teachers and principals to view results from student feedback surveys.

I was totally new to the problem space so I knew I had a ton to learn. The company had a few customers already, so I tried talking to educators in those districts. After a bunch of conversations I started feeling like I understood the rough landscape.

Boy was I wrong. As we shipped, I just kept being surprised.

Here's an example. We know receiving feedback can be stressful. So I thought our product should frame student feedback in a friendly, non-threatening way. Many teachers agreed. Seems uncontroversial, right?

Wrong! Turns out that in some schools, the political context of student surveys is high-stakes evaluations. In this context, an overly friendly interface can feel tone deaf and weird.

This kind of trap is just hard to see in advance if you're operating off a sketchy map.

Over the years, tried so many things to deepen empathy.

We hired lots of former teachers/principals. I learned so much from them. Also did a bit of after-school teaching with some coworkers. Very eye-opening.

Could have done more/better, but genuinely tried really hard.

And yet...I never felt like I came close to understanding the experience of being a teacher.

In consumer, it's easier -- every designer at Instagram can just use Instagram.

B2B is harder. Teaching is an entire profession. Infinitely complex!

Designing in this context felt like fighting a headwind. When I'm designing for myself, I have solid intuition to lean on for every decision. When designing for an other, I'm relying on a sketchy view and an external feedback loop.

Still doable, but waaay more challenging.

Now, so far this may seem like a depressing conclusion. "Solve your own problems" is how we end up with 100 food delivery apps for young engineers living in San Francisco, right?

But I think there is a way out: democratizing the tools.

Some of my most fun moments at this startup were seeing the Excel spreadsheets that our customers would create based on our CSV exports.

Usually very ugly. Occasionally buggy. And yet, perfectly tailored to what they needed. Often more useful than our fancy online reports.

Also saw this kind of thing internally.

I also helped organize company-wide hackathons. We included every team, not just eng/product. One of our designers built our UI kit as a Google Slides template. Former educators on our team built some incredible mockups.

It made me so happy that spreadsheets and simple drawing tools could empower people who really knew the problem.

Of course their solutions lacked certain kinds of design expertise. But I think often deep problem context is the most important thing. Everything else is secondary.

So, I see powerful end-user-friendly tools as the best solution here. Yes, the reality is that people design best for themselves. But to avoid that becoming an exclusive concentration of power, we need to empower everyone with tools, not just the current programmer elite.

These ideas aren't original. The fields of Participatory Design and End User Programming have been thinking about this for decades. I'm just excited to keep building on them :)

A caveat: not every teacher will be great at designing tools for other teachers. Still requires a certain mindset.

But, I think we can grow the pool with accessible tools and education.

Going from 1% to 10% of people making their own tools would be huge

My experience here also relates to Andy Matuschak and Michael Nielsen's observation that the traditional "external designer" approach may not yield enough insight to take big leaps towards new tools for thought.

We need hybrid designer + domain experts!

numinous.productions/ttft/#how-to-i….

I think about this a lot re: my Wildcard project too.

I don't expect majority of web users to spend the time customizing websites.

But imagine if 5% of web users built browser extensions. There would be like a 1000x explosion in browser extensions!!!

https://twitter.com/geoffreylitt/status/1229251217118892032

I think this mindset can make malleable software feel a a lot more plausible.

We don't need everyone tweaking their software.

Just need to activate the 10% who already have the vision but can't quite code -- the tinkerers, the spreadsheet hackers, the entrepreneurs

And by the way, this is why Apple designs great software...

They design software that they would use themselves.

That's why they don't need focus groups!

https://twitter.com/geoffreylitt/status/1290670468987584513

Now by this point in the thread, you may have a nagging doubt that goes something like this:

"Sounds nice, but people would have asked for the faster horse! They can tell you their problems, but you need an expert designer to go deep and design an awesome solution for them."

Totally valid argument. I think the key is to consider relative value of problem context and solution skill in each domain.

In some domains, the problem is obvious, and the solution is really hard. Eg, the prompt might be "make cheap clean energy". The rest is engineering.

But in my experience, most design is the opposite. The hard part is understanding the needs, and the solutions follow naturally (maybe with a bit of editing from a pro).

In these domains, I believe empowered end users will beat external experts every time.

Case in point: I'd rather design my own living room than have a single, optimal expert-designed living room made for all people

https://twitter.com/geoffreylitt/status/1075404291534393344

https://twitter.com/geoffreylitt/status/1272549587308421123