August Home Developer Portal

Solely designing B2B customer management and documentation portal
Team —
1 designer (me), 2 engineers
Role —
Product Design
timeline —
Oct – Dec 2021
LANDING PAGE
Partner developers use this portal to learn how to integrate their service into our app, either through OAuth or via our API.
At the top of the page, I surfaced the most common integration questions so developers can quickly orient themselves and jump straight to the right documentation. This also builds trust early by signaling that we understand the real decision points developers face when getting started.

Each recommended article includes a clear label that states what it’s for (for example, “OAuth setup” or “API authentication”). The goal is to reduce guesswork. If a developer is scanning without full context, the label acts as a quick anchor so they can judge relevance at a glance and keep moving.
LANDING PAGE

A common pattern is to send users to a separate “Contact” page with a standalone form. Instead, I placed the form directly under “Questions? Contact us” so developers can stay in the same context that prompted their question.

If the question is tied to something they just read, they can reference the relevant section immediately while writing and refining their message, which reduces friction and makes it more likely they’ll complete the form.

Highlighting a CTA
I surfaced the “pending invites” in two ways: an eye-catching call-to-action button and a taller list module than the other lists. This made it easier to spot at a glance and encouraged follow-through.
Preventing errors
I wanted to reduce the risk of errors that can come with inline editing on user profiles.

Instead of placing “Edit user” as a primary, always-visible action, I tucked it into a dropdown to make the step more intentional and less prone to accidental clicks.

Once selected, editing happens in a focused modal so the user clearly shifts into “edit mode,” can review changes in one place, and is less likely to make unintended updates.
Using card elements
A partner can have multiple OAuth/API credentials tied to their profile.

For security, I needed a way to store and organize these credentials without exposing sensitive values by default.

I used credential cards as the primary pattern so each set is clearly separated and easy to scan, while keeping secrets hidden until the user intentionally reveals or copies them.
Testing
I A/B tested the designs with ten engineers. Given time and recruiting constraints, all participants were internal engineers.

Each tester completed a set of representative tasks on their assigned version while I timed task completion and noted points of hesitation.
Interpreting results
With only ten participants, task times were more indicative than conclusive, so I used them as a quick check rather than a final verdict.

I used faster completion and fewer hesitations as a lightweight signal of intuitiveness, then paired those results with qualitative observations to make decisions in time for the deadline.