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
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.
Interested in how your business could be utilizing the Access API within your platform or application? Reach out to our sales team.