Test your code on people · Duncan Malashock

Would you say your latest module is “well-designed” and “nice to use”? How do you know unless you’ve tested it?

Don’t take your own word for it! Test your code on other programmers who would use it.

Here’s how:

Think of an example implementation your code would likely be used to write.

Get concrete, to the point where you could explain the goal to a programmer and ask them to attempt it.

Find a dev you work with, a friend from the software community, etc. who’s willing to try out your code.

The more likely that they’d actually be using the code you wrote for their work, the better.

Ask your participant to implement the example use case you thought of. Ask them to think aloud as they do it.

Clarify that you’re testing the code, not them, and that it’s fine if they make mistakes or get confused.

You may be tempted to explain how your design works and why it’s so clever.

Resist this temptation! Only explain what you need to get them unstuck.

Otherwise, you won’t learn anything about how people use it when you’re not there to explain.

What parts of your design confused your participant? What connections weren’t they able to make? What parts were missing? Where did they get stuck?

Write these problems down. Then, make the simplest changes you can that would solve them.

Curious about this method? I learned it from Steve Krug’s usability testing book “Rocket Surgery Made Easy”.

This post was originally a Twitter thread as part of Ship 30 for 30.