I designed the screen in this example for a tool used by Equitable's internal Employee Benefits (EB) users to manage benefits packages at the group level. In EB, groups are organizations that provide benefits to individual members (e.g., employees), but the details of what coverages each group provides are unique.

The business unit had identified the need for a feature to set up new groups in the system to manage their requests and had drafted the basic requirements for what the new feature must accomplish. How it would sit within users’ workflows, screen layout, and functional behaviors were left to the designers to figure out.

As with all software development at Equitable, the project was executed using Agile methods. Requested features and capabilities were added to a project backlog in the form of user stories, then I worked with the product owner and development team to understand and prioritize items in the backlog. Technical feasibility, upstream and downstream dependencies, strategic alignment and many other factors were considered. On this project, many of the insights into user needs, preferences, and expectations that would guide my design efforts as the project progressed were gathered during this stage. While the specific information that needed to be gathered was already determined, the specifics around input methods, logical groupings, and screen layout were guided by end user preferences that I gathered through interviews, observation, and UI design best practices.

A screen design effort like this one typically consists of multiple user stories—each user story is like an individual brick that, when stacked up, completes the entire wall. Basic screen setup and layout was one story. Each section within the data entry form was another. On some projects, even individual components might be assigned their own user stories, depending on complexity. In this project, once the “basic screen layout” user story was committed to a sprint, I started off by sketching a variety of possible layout and functionality ideas on a whiteboard. Whiteboards are my favorite way of getting things started, because I can quickly gain feedback from other members of the project team, and in this case some of the actual end-users of the software since their desks were right down the hall. I like to use a portable, 3’x4’ whiteboard that I can physically carry from my desk to meeting rooms or other people’s desks to facilitate collaboration.

After working through a number of iterations of the basic layout and getting general agreement of the bast way forward, I prepared the initial low-fidelity wireframe. Although this helped stakeholders start to visualize how the final product might work, I needed to remind them that this isn’t what the final product will look like—it’s just a blueprint to show basic form and function, with visual treatment to come later. They identified a few gaps, and pointed out some areas where screen elements could be rearranged to better align with other tools that the end users are already familiar with. Once this initial wireframe was solid, I moved on to putting together an interactive prototype.

Since Equitable has a fairly standardized set of components and design elements in its design system, I don’t spend much effort on mid or even high-fidelity wireframes for internal enterprise UX. Instead, I usually work out any issues in the low-fi wireframes, then move straight to an interactive prototype. With an interactive prototype, I can get much closer to simulating the actual feel of how an app will function, much more so than with static wireframes. This helps both project team members and stakeholders who need to make decisions and grant approvals, but also for end-users who can use the prototype in a usability test to uncover any issues there. While modern tools like Figma have some great capabilities (particularly for collaborative design), I like to use Axure RP for the data-intensive apps commonly used in enterprise environments because of its built-in capabilities for creating interactive forms, complete with conditional variables and other scripting elements. By using pre-built components from the design system’s component library, I was able to quickly put together the interactions needed to assess the viability of the design with a minimum of modification to accommodate the unique needs of the project.