Laura Widener

VA Developer Portal

Current "Contact Us" page
Current "Contact Us" page

VA Developer Portal Audit

Challenge: I was given the task of reviewing the U.S. Dept. of Veterans Affairs (VA) developer portal contact form and suggesting stakeholder questions and product improvements with limited background information.

Context: I only know that users are internal and third-party software developers. The goal is to make it easier for these users to request help or support with API publishing or using the VA’s APIs.

Task: What are 5 questions you’d ask project stakeholders? What 5 improvements would you recommend for the ‘Contact us’ form?

Questions to ask: 

First 5 questions to ask the project’s stakeholders (given that the goal and users are already stated):
1. What is the timeline for the revamp project?
2. What are the most common problems users have?
3. What design and technical constraints exist?
4. What project decisions were already made?
5. How is success defined and measured in this project?

 

My recommended improvements to the ‘contact us’ form:

  1. Separate the “Publish your API to Lighthouse” option with its own menu item and form apart from “Report a problem or ask a question.”
    “Publish your API” language is unclear. It’s not obvious to users how to accomplish this — especially since they currently have to publish it through a “Contact Us” form. One of the main user intents of this page may be to publish APIs, so there should be an easy, simple flow to complete this task.
  2. Add more entry fields for API details.
    The first entry field currently lists five different bullet points of information expected to be entered into one. Important details may be left out of one comprehensive response and potentially lead to submission issues.
  3. Clearly label which entry fields are public-facing vs. internal-only.
    The current entry fields aren’t clear enough in telling the user which entry fields are intended for public-facing information. Users should have clarity here so they may better tailor their responses.
  4. Specify responses are email-only (if they are) and an expected response time.
    The form doesn’t give the user any idea how or when they’ll receive a response. Contact forms (or any action of submitting information) should not leave users with no idea of what happens next. 
  5. Separate the “Report a problem or ask a question” options into two distinct options.
    Combining question submissions and problem reports doesn’t recognize the different user intents and expectations. These two tasks should be separated into different areas so it is easier for users to find the right place, and so relevant user-focused microcopy can be included.