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!!!

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!

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

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Geoffrey Litt

Geoffrey Litt Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @geoffreylitt

16 Nov
The tragedy of modern computing: too often we conform to the software, rather than molding it to our needs.

How can we empower everyone to edit their tools? Here are 3 ideas I think can help us get there:

(1/n)
1) Customization by Direct Manipulation.

Back in the stone age of CLIs, you had to fumble around in the dark, with no visibility.

GUIs were a huge step forward, letting us directly see and act on the objects we care about.
But then, what happens when you want to go beyond the existing features of your GUI software?

Time to do some programming.. which means right back to the stone age, where you can't see your objects.

Even "user-friendly" customization tools like AppleScript have this problem.
Read 11 tweets
13 Nov
Just assembled a new bookshelf to hold some of my favorite books about computing ☺️
Two of these I see mentioned less often:

- A People's History of Computing in the US: great counterweight to hero narratives in computing history

- Changing Minds, by diSessa : incredibly deep insight into designing empowering computing environments for kids
Also, The New Media Reader is incredible. Felt like someone had perfectly curated a collection for my interests
Read 5 tweets
11 Nov
1/ Interesting discussion today around the idea of Apple adding realtime collaboration to AppKit...

But I wonder if a focus on realtime collab misses the more fundamental issue of the web vs native battle: zero-install apps.

stratechery.com/2020/apples-sh…
2/ As pointed out by @kevinakwok, Figma vs Sketch isn't just about designers collaborating in realtime.

It's about the CEO being able to give feedback with one click of a link! No fiddling with installation first.

kwokchain.com/2020/06/19/why…
3/ Same point comes up in this great paper by @MidasNouwens and @cklokmose analyzing the "app" metaphor

They find that web vs native is more about the mental model shift from "files and apps" to "URLs", than the realtime collab per se

pure.au.dk/ws/files/12160…
Read 8 tweets
22 Oct
Engelbart, on the danger of building "natural" systems
He references this point in this 1986 talk looking back at The Demo and his work on NLS / augmentation. Strongly recommend

I think I would be very sad if I time traveled forward to 2070 and found their version of computing immediately familiar, "natural" and "easy to use"
Read 6 tweets
22 Oct
Hypothesis: the next big end user programming environment won’t be a “programming environment”.

It will be “just an app” where you put your data. But then sneakily becomes super powerful
I’d argue spreadsheets basically work like this.

This also isn’t a very hot take, I think Airtable, Notion and Coda all see this as their path to varying degrees
Read 4 tweets
22 Oct
Showing spreadsheet dependencies by subtle blending back and forth, rather than a separate "dependencies mode"

from 1998 work at PARC: www-ui.is.s.u-tokyo.ac.jp/~takeo/researc…
This feels loosely related to Observable’s dependency view... giving ambient glimpses of the dataflow structure underneath

I no longer agree with my prior take on this

It’s true the most naive approach doesn’t scale well, but the design space is vast

Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!