Design for a developer tool 1. Motivation
Jan 2024
What drives us to build
Can you remember your first computer? The click of the power button, the short beep right after? I bet it wasn't your future tech salary firing up your mind at this moment, and it's still the same thing that makes you stare at your IDE all night long.
...developers’ main motivator, which is to create something they can be proud of. That gives them the opportunity to say, “I made that.”
Developer Relations by Caroline Lewko, James Parton
For a successful developer product, it's best to support the deepest drive to build. "I made that" refers to a powerful and complex feeling, and I would like to unpack it. Many discussions and survey results about developer motivation, productivity, and happiness are available online. For example:
With some help from fellow engineers, I boiled it down to this:
Driver
Interest
The core of a flow state.
Aesthetics
Good code is beautiful.
Self-worth
What I do is important for others.
Pain
Boredom
Routine kills the flow.
Ugliness
For example, spaghetti engineering.
Anxiety
Inability to solve the problem.
Resolution
Automation
No more distraction.
Elegance
Less parts, more meaning.
Magic
My new superpower.
Proportions define the tone of voice and the accents on specific features. For example, Uploadcare is 60% automation, 30% elegance, and 10% magic. Our most successful users know how to build around AWS S3 but prefer a simple, quick solution instead.
CJM of developers
Let's take a look at another dimension. Product people often use Customer Journey Maps. Basically, it's a scenario of a user getting the value, from awareness to retention. The challenge is if you outline the scenario by watching developers move through your website, documentation, and dashboard, you'll get a seemingly random picture. Here's where Developer Journey Map comes in handy — it defines stages by a change of intent:
1 • Discover. You don't just trust the random crap from the google, do you? Well, sometimes you do. But we're talking about time investment and responsibility. So, answers on Stack Overflow, Twitter memes, guides on building your own Instagram, YouTube tutorials — everything adds up.
2 • Evaluate. Is this really a solution, or should I go set up S3? Can it fit my stack? Does it scale? Does anyone use it in prod? Is it future-proof? Can I afford it now, next month, or next year?
3 • Learn. This is where they get an idea of how this new tool works — a mental model. It doesn't have to mirror reality but must help make correct assumptions to create a “Hello World.” If I do X, I get Y. Time is important: the faster they get there, the easier it feels to use the product.
4 • Build. Now, they are ready to create something specific for the problem they are trying to solve — build a proof of concept. Check your guides and snippets twice. If they encounter something broken, they'll leave.
5 • Scale. They released into production and became a customer. Your task is now to help with maintenance and inspire to expand integration.
Remember that users will go through these stages whether you prepared a path for them or not. Your job is to detect and reduce friction. How you detect the change of stage depends heavily on your product and what data is available to you. For Uploadcare it looks like this:
Focus
The main challenge I dealt with at Uploadcare is how to define a context for a specific artifact (page, screen, demo, example). Is the user ready for this information? What details matter at this point and what doesn't? Both unneeded nuances and incomplete data for the chosen task cost us new clients.
There are as many layers as you have time to discuss, each one relating to a deeper need. A deeper reason why. But when you’re exploring the value of a product, there are only so many layers that are productive to discuss.
The layers he talks about are:
Use: "I use the drill to make holes." — the action itself.
Product: "I’ve made holes to hang photos." — the context.
Outcome: "I’ve hung photos and now have a more personal home." — the vision.
Choose the right layer at the right time. To put it simply, you don't want to end up "empowering your business" right below a code snippet. All three layers are present at every stage. I will map the most prominent.
Let's put everything together:
What's next
Now we know what tone of voice to choose at each stage. What exactly to talk about is yet to be defined. In the next part, I will go from the other end, sorting and prioritizing features, and give you a practical example.
