New Feature Design
Design an IP address request form for the SolarWinds IP Address Manager (IPAM) software product.
My primary contributions: Interaction Design: user flows, mockups, prototypes; User Research: personas, user interviews, analysis.
One of the top requests from users on the SolarWinds’ THWACK online community was to have the ability to request an IP address from within the software product, IP Address Manager (IPAM). Our Product Manager decided to take on the challenge.
The UX Researcher and I decided to interview some of our users to get a better understanding of their IP request process and needs. We first sent out surveys to get general feedback to help us determine which customers to interview and what questions to ask. Then, we conducted user interviews with 10 users.
I also took the initiative to perform secondary research. I compiled data from the users’ THWACK conversations and searched the internet to learn more about the world of IP addresses.
To synthesize the survey and interview research, I created a spreadsheet to catalog the data and uncover insights. Themes that emerged were around the ability to select a subnet, to customize data fields and to request multiple IP addresses.
We also discovered our users had a variety of methods for requesting an IP address - including via email communication, through a ticketing system or even manually pinging a device to see if an address was available. To better understand the complexity of a request, I diagrammed the current and ideal processes for one of our key users.
Based on our online user forum and a quick search around requesting IP addresses, I uncovered some interesting findings:
IT professionals spend an average of 16% of their total time troubleshooting IP problems.
Currently, a typical way to track IP data is via static spreadsheets.
One basic and important criterion for efficient IP address management is to avoid IP duplication.
Common IP issues: manual assignment of static IP address, misconfigured DHCP server, multiple wireless access points or devices with DHCP server turned on by default, devices entering and leaving a network.
Our current IPAM product, while offering a better solution for IP management than using spreadsheets, does not address the first part of the process - making IP requests.
Because of our diverse customer base, instead of defining personas based on job titles, I took the 'jobs to be done' approach and identified two key personas - the IP Address Requestor and the IP Address Assignor. The Requestor would have two categories based on account type - Guest and Authenticated. The personas helped spur team conversations around user permissions and the needs for the Assignor.
To help bridge the gap from discovery to design, I sketched an ecosystem map for an IP Address Request. This helped to identify core content and got me thinking about relationships and requirements.
Sketching, Mockups & Concept Testing
Our initial research led to more questions. To gain clarity on direction, we decided to show initial design concepts to some of our key users. We were particularly interested in learning more about subnets and required fields. Utilizing the ‘ideal process’ flow, I did some sketching and created mockups using our design library.
Our testing research indicated two primary areas of concern around subnets and required fields.
For subnets, sometimes there are thousands of subnets. The current dropdown selector wouldn't be efficient for this.
In regards to fields, ideally, users wanted the ability to customize fields. Due to technical limitations, however, this wouldn't be possible. Given this, we wanted to include the fields that would best address our users' needs. We identified key needs as the ability to assign a ‘hostname' and to assign a ‘Media Access Control (MAC) address'. The role of a MAC address in the request process became a major discussion point for the team.
Based on our concept testing, it became clear that the Requestor persona had two primary goals - Requesting an IP Address and Reserving an IP Address. Each goal was dependent on a Requestor's permissions. Using the ‘what the user sees, what the user does’ exercise, I created high-level user flows. Then, we went to the whiteboard to talk out requirement details...which led to more layers and questions.
Requirements and Sprints
Given the complexity of IP addresses, the project quickly became bloated with feature creep. We took a step back and decided to take a more Agile approach and created an MVP version for the first phase...a bare bones request form without subnet selection or permissions. I created a MoSCoW prioritization chart with user stories to document the version requirements.
Based on feedback and with guidance from the Lead UX Designer, I revised the mockups and created two versions. For the first version, the user would only be able to request addresses, either with a 'guest' account or an existing IPAM account with limited permissions. In the second version, the user would have the ability to reserve addresses and have the ability to request a subnet, if those permissions were granted. After a couple rounds of revisions, I presented final Sketch mockups to developers via an InVision prototype.
Version 1: Requesting an IP address
Version 2: Reserving an IP address
During development, I participated in the sprint reviews as well as performed QA, entered JIRA tickets and monitored the integrity of the design.