Application Selector (Interaction design sample):
How to help hundreds of people find their needle in a haystack with 2 days of work.
I designed everything in 2 days, including:
Information architecture, Hi-fidelity screens/content/interaction design, development guidance and communication
The ask
I was called in to design an Application selector for Northwestern Mutual's staff, taking over for another designer to address information architecture and interaction design issues. This resulted in a complete rework out of necessity, done over 2 days. I brought the original designer and another designer along as a collaborative learning experience.
The following is an examination of how I consider and communicate detailed interaction and visual designs.
The feature
This is the Application selector. its sole purpose is to help insurance field reps select the form they need out of the 100+ available to them.
My goal with this quick V1 was to offer:
Clarity: in both layout and content
Modular: in functionality so it can be built piecemeal without much interdependencies
Scalable: not require much change even the number of forms grow into multiple times what it is currently
Usable: Easily learnable regardless if the user is a newbie or a power user
Designing the line item: Breaking out the data
Problem: The main list in the older design (not shown) displays all details in a single line; data was lumped together or hidden, making it difficult to understand.
Visible details: Whereas the previous designer only updated the style of the design but didn't touch the content structure, I analyzed the data to break out different categories of data and metadata, providing clarity through a more organized layout.
Invisible details: Only a fraction of the forms in the entire system has tags associated with them, which calls out unique parameters. The design thus utilizes multiline variable height rows when tags are active, creating an easier to read overall list while making tagged items.
Categorization and filtering
Problem: To navigate hundreds of documents, a nice looking UI with good information design alone wasn't enough. Categorization and filtering behavior was a priority in the design.
Visible details: I designed a simple filtering system based around the metadata that was available to the user and system. The components were split out according to mutually exclusive vs inclusive data categories.
Invisible details: Speaking of mutually exclusive and inclusive data categories., part of my design is a simple boolean logic tree that visually outlines how they should affect the outcomes of the filter.
Search, behavior and content
Problem: Categorization and filtering alone can still be insufficient or inefficient for finding the EXACT document people are looking for. For that scenario, there's search.
Invisible details: Even though I didn't have access to the dev team, I focused on both specific microinteractions (inc. keyboard, time-based, mouse-based), and search term priority details,
(Even more) Invisible detail: The searchable items are prioritized by order of how specifically unique the entered syntax is. This is beneficial for filtering out unique terms first and truncating the search results as soon as possible.
For frequent use: a carousel
Problem: Many users also repeatedly used a handful of documents. Thus requiring manual seeking of documents every time is likely not great for users like them.
Visible detail: I designed a horizontal carousel to accommodate frequently used forms. This didn't go into the table mostly because "Frequently used" is a compound parameters of time range, frequency, and expiration; and I had to incorporate this fully into the design.
(Somewhat) invisible detail: Though we didn't have research, I also specified preferred method of calculation for tweaking to ensure the carousel always has exact partial card proportions revealed when there's overflow.
After a very quick design iteration, the design received very positive feedback from the product team, and this was ultimately put in the development backlog for future research and execution.