Cutting out the busywork for developers with better design

It’s easy to joke that when a bar is set low the job of the design team is that much easier. But in truth, fixing problems in design only makes the experience satisfactory, it doesn’t make it delightful.

When’s the last time you had to read instructions in order to get your job done? Were you excited about it? Likely not.

No matter your daily responsibilities, most of us have been there and done that — muddling through sites only to be left with low expectations on finding what you’re looking for and comprehending domain specific gibberish. On top of this, you’re only reading this documentation in an effort to get something else done. Sigh.

Being delightful calls for exceeding expectations. The trick is to identify expectations, flag the let-downs and improve.

Defining experience goals

Experience goals articulate how you are going to meet the business objectives, satisfy customer needs and inspire creative direction for concept development. Every designer has goals, not everyone writes them down and shares them with their team. Writing experience goals down, provides team focus and serves as a benchmark to evaluate design ideas against. I like to capture them as they come to me during discovery and then formalize them with the team at the end.

Being open to insights during discovery allows the goals to come to you.

Define experience goals for any given project early in the process — during the analysis and discovery phase — by making a note of the ‘ah ha’ moments, insightful observations of the team and customer feedback.

A few examples of our experience goals convey what is important to us as a team as we’re developing our documentation for better ACH transfers:

• Ensure the developer documentation is a core part of the .com experience
• Ensure it is easy to navigate and simple to find what you are looking for
• Deliver how-to instruction that is easy to evaluate and follow
• Clean, clear and elegant reading experience.

However, none of these goals delight; done well, these elements should go unnoticed by a developer interacting with our page.

For us, during our developer interviews, we uncovered the importance of delivering delight.

Reduce the busy work

So how did we deliver this delight to take our portal beyond what was just expected?

Look for moments where developers expect things to be tedious and instead wow them by removing the busy work, make the processes seamless.

Developers are the first people to notice when a manual process could just be automated. Unfortunately, performing up-front tasks to get to the heart of what you’re trying to do is all too often part of the job.

Crafting and maintaining your documentation is an important foundation for a positive developer experience. Making information easy to find, understand and digest quickly is a relief, but it is the little things that go above and beyond that make a difference.

Visit our developer documentation and the first thing you will see is the code for a transfer request in the various languages that we support. In doing so we’re communicating the heart of our platform as quickly as possible — a positive first impression.

But here is what sets us apart, providing that ‘Ah! Cool’ feeling:

Our copy button so you can grab the code you need in one click

Global language selector, enabling fluid selection

Step-by-step guides which clearly outline the need-to-knows

With developers, cutting out the busy work with improved design is what will make for the best possible experience.

We are never done.

As we aim to delight, reducing the busy work is the most critical experience goal for our developer audience. It pushes us to go the extra mile as a team and provides direction for how we’re going to make our ACH API easy to use.

Over the coming months we’re going to continue to work on making our developer experience as good as it can be. If you have feedback on our developer documentation or on how we can better improve Dwolla’s developer experience, I’d love to hear from you. View the developer documentation now.

Originally published at blog.dwolla.com on January 12, 2016.