Building Developer Tools Your Coworkers Won't Hate by Amy Nguyen
It's easy to complain about bad tools. It's harder to write a great tool yourself. Once you step into the shoes of an internal tools developer, you realize that you're balancing feature requests and constraints from a dozen different teams and an entire universe of complexity behind what should be a simple UI. In this talk, we'll talk about how to gather information about your users' needs, how to balance between conflicting requirements, and ways you can fail to build a tool that your coworkers want to use.
Building Developer Tools Your Coworkers Won't Hate
1. @amyngyn J on the Beach 2018
building developer
tools your coworkers
won't hate
amy nguyen (@amyngyn)
j on the beach | may 24, 2018
2. @amyngyn J on the Beach 2018
hello!
● observability engineer at stripe
● excited about user experience design and
education for developer tools
● @amyngyn
● amynguyen.net
3. @amyngyn J on the Beach 2018
agenda
● motivation
● how to do user research
● UX design principles
○ command line tools
○ data analysis tools
○ build tools
4. @amyngyn J on the Beach 2018
why care?
● bad UX causes incidents.
incidents cost money.
● bad UX wastes time.
time costs money.
● bad UX creates hostility.
hostility costs money.
5. @amyngyn J on the Beach 2018
● talk to people
○ one-on-one
○ focus groups
how to do user research
6. @amyngyn J on the Beach 2018
how to do user research
● ask the right questions
○ don't ask questions that confirm
what you were expecting
○ dig deep, don't accept the first answer
7. @amyngyn J on the Beach 2018
● communicate as you follow-up
○ build trust
○ confirm your solutions are the right
solutions
how to do user research
8. @amyngyn J on the Beach 2018
● talk to people
● ask the right questions
● communicate as you follow-up
how to do user research
9. @amyngyn J on the Beach 2018
does anyone even know what that flag does?
command line tools
10. @amyngyn J on the Beach 2018
preview as the default
● if your tool makes critical changes to
infrastructure, don't allow users to make
those changes accidentally
./run-script --confirm
11. @amyngyn J on the Beach 2018
preview as the default
● provide diffs of what will change
12. @amyngyn J on the Beach 2018
be consistent
% man -h
Usage: man [OPTION] [SECTION] PAGE…
[...]
13. @amyngyn J on the Beach 2018
be consistent
% less -h
Value is required after -h
(--max-back-scroll)
14. @amyngyn J on the Beach 2018
be consistent
● match arguments to your other tools
● match arguments to historical usage
15. @amyngyn J on the Beach 2018
don’t break existing tools
● have integration tests for your internal tools
● design with existing tools in mind
cat ex.txt | grep hi | sort -r
16. @amyngyn J on the Beach 2018
command line tools should
● be consistent
● integrate with the rest of your tools
● provide previews and diffs
17. @amyngyn J on the Beach 2018
everyday we stray further
from unix philosophy
● these ideas have been discussed for decades!
○ rule of composition
○ rule of modularity
○ rule of least surprise
18. @amyngyn J on the Beach 2018
command line tool design
● provide previews and diffs
● be consistent
● integrate with the rest of your tools
● for more, read "The Art of Unix
Programming" by Eric S. Raymond
(or just read the Wikipedia article!)
19. @amyngyn J on the Beach 2018
does that data really mean what i think it means?
data analysis tools
20. @amyngyn J on the Beach 2018
rapid testing
● users need a REPL or
other way of quickly
validating ideas
21. @amyngyn J on the Beach 2018
discoverability
● autocomplete
● GUI or other menus for
showing all the options
22. @amyngyn J on the Beach 2018
correctness
● syntax errors and highlighting
● explanations for syntax errors
23. @amyngyn J on the Beach 2018
explorability
let me go back to the
previous page
don't lose my
place if I refresh
let me share URLs
let me open in a
new tab
24. @amyngyn J on the Beach 2018
data analysis tool design
● rapid testing
● discoverability
● correctness
● explorability
25. @amyngyn J on the Beach 2018
i don't know who broke the build
because i don't know how to find the build
build tools
26. @amyngyn J on the Beach 2018
navigation
● anticipate the most common actions
○ find my latest build
○ locate failing output
○ rebuild
● autocomplete!!!
27. @amyngyn J on the Beach 2018
fail fast
● if something is failing, don't wait to
finish before showing the result to
the user
28. @amyngyn J on the Beach 2018
helpful messages at the right time
● remind users to lint and unit test
before kicking off a long build
process
● suggest corrections for bad input
31. @amyngyn J on the Beach 2018
summary
● communicate early and
often with users
● imagine the context in which
users will use your tools
● user experience and good
design matters even for
infrastructure tools