Test your code on people

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:

๐Ÿ” Choose a use case to test

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 participant

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.

๐Ÿ‘€ Watch the participant attempt the task

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.

๐Ÿคซ Observe, don’t explain

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.

๐Ÿ“ Take notes and address the issues

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”.

Learn more about it at https://www.sensible.com/rocket-surgery-made-easy/

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