developer console

Redesigning the go-to tool developers use to leverage email data in their applications.

Redesigning the go-to tool developers use to leverage email data in their applications.


CIO is supposed to be the easiest way to integrate email data with any application, but it could (and should) be easier. This project was a part of our initiative to improve the developer experience and is focused specifically on the developer console.


As with any new project, I like to sit down with the people most affected by its outcome to collaboratively build out a requirements document. In the past, I've relied on just the Product Manager to do this, only to later run into all sorts of issues - from misunderstanding technical feasibility to miscues on overall metrics. Everyone has a stake in the project, and design requirements are a great way to account for everyone's thoughts and creativity from the get-go.

Outcomes & Metrics

What problem are we solving and how will this project deliver?





User testing




Dan Corbin (product manager)

Cecy Correa (developer)

Dane Carmichael (developer)

  • User value: a dev sandbox that easily demonstrates the power of our API’s and how devs can leverage the email data we deliver to and for their apps.
  • Business value: Having a tool like the dev sandbox makes it much easier to onboard new users, show them how to use the API, and retain existing users.

What metrics will be used to measure success?

  • Increase the level of engagement from existing users (logins and running queries through the explore tab)
  • A reduction in support tickets for the console as a whole OR per tab.
  • Developer confidence in the product (signups, surveys, etc)
  • Speed. How quickly can we get new devs to the console (Time to Value)

What needs to be accomplished by the end of the timeline?

  • Defined personas of users
  • Concepting
  • Wireframes
  • User testing 

Constraints & Assumptions

What assumptions and/or constraints will impact the solution?

  • Are tabs necessary?
  • Must maintain the 2.0 and Lite versions within the console
  • Dashboard should include call stats / volume and user stats (See graphs in admin console)
  • Not ALL devs know how to interact with API’s
  • Errors occur and we assume dev knows what they mean and how to resolve
  • Add to knowledge base and connect the dots across the console back to the API
  • Logs, Explorer, O-Auth, Settings, Account Management as MVP
  • Devs use dummy emails to log in and interact, but don't engage with received emails


What are the specific requirements?

  • Demonstrate all of the API functionality more clearly
  • Architecture needs to be flexible enough so the dev console can be updated quickly and easily in the API (function of the backend moving forward)
  • Pseudo-onboarding that prioritizes client-product fit (DIG DEEPER HERE)
  • Update the UX to meet the conventions of today (usability, look and feel API specific conventions)
  • Must allow multiple logins for multiple accounts (one API key, many developers)
  • Ability for 2-factor authentication for both privacy and ease of use
  • Explicit permissioning (this is how your data is being used)
  • Privacy

All of the above information came out of one meeting and was captured in this document. That meeting included front and backend developers, as well as our Product Manager.

Other work