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’ online community was to have the ability to request an IP address from within the software product, IP Address Manager (IPAM). Our product team decided to take on the challenge.
Primary Research: Surveys and User Interviews
I collaborated with a dedicated UX Researcher to gain insight into our customers’ IP request process and their top needs on our software platform.
We first sent out customer surveys to help us determine which users to interview and what questions to ask.
Then, we conducted user interviews with 10 key users to identify their needs and pain points.
Secondary Research
I also took the initiative to compile data from the online community and other online sources to learn more about the world of IP addresses.
I uncovered some interesting findings from this research:
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.
Synthesis: Feedback Chart
To synthesize the survey and interview research, I created a spreadsheet to catalog the data and uncover insights. Themes emerged around having the ability to select a subnet, customizing data fields and requesting multiple IP addresses.
Synthesis: Process Diagrams
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.
Personas
Because of our diverse customer base, instead of defining personas based on job titles, I took a Jobs-to-be-Done approach and identified two key personas:
IP Address Requestor
IP Address Assignor
These personas helped spur team conversations around user needs and technical requirements for account permissions.
Ecosystem map
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 between the users and the system.
Design Sketching, Mockups & Concept Testing
Utilizing the ‘ideal’ process flow, I sketched a concept and created mockups using our design library.
Given the complexity of our system and user requirements, we decided to gather user feedback on our initial design concepts, to gain clarity on our design direction. We were particularly interested in learning more about subnets and required fields.
Testing Results
Our testing results indicated two 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 form fields, ideally, users wanted the ability to customize form fields. Due to technical limitations, however, this wouldn't be possible. However, we were able to include solutions for two key users needs - assigning a ‘hostname' and assigning a ‘Media Access Control (MAC) address'. The role of a MAC address in the request process became a major discussion point for the team.
User Flows
The testing also clarified that the Requestor persona had two primary goals and user flows: Requesting an IP Address and Reserving an IP Address. And that 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 to help identify requirements.
Requirements and Design Sprints
Then, we went to the whiteboard to map out requirement details, which led to more complexity.
Feature creep & prioritization
Given the complexity of the IP request process, 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 - a first phase - a bare bones request form without subnet selection or permissions.
I created a MoSCoW prioritization chart and user stories to document requirements.
Now that we had some clarity, I revised the mockups and created two versions.
Version 1: Requesting an IP address:
For the first version, the user would only be able to request IP addresses, either with a 'guest' account or an existing IPAM account with limited permissions.
Version 2: Reserving an IP address:
In the second version, the user would have the ability to reserve IP addresses and have the ability to request a subnet, if those permissions were granted.
Finally, I presented Sketch mockups to the product owner and developer, via an InVision prototype.
During the build, I participated in the sprint reviews as well as performed QA, entered JIRA tickets and monitored the integrity of the design.
The End