Wireframes

Wireframes, when accompanied by concise annotations, serve to specify UI functionality and hierarchy for dev teams, and clarify user intent for design teams.

PROJECT

Hill-Rom

Industry: Medical equipment

My role

UX design lead.

Design a system to enable busy hospital staff to easily find and order the right medical equipment for their patients.

Bake in tools to streamline workflow such as intuitive product filtering, customizable favorites lists, and patient management.

Ensure UI component compliance with the SAP Hybris ecommerce platform in order to reduce development overhead.

My approach

Begin thinking about flows and component wireframes from a patient-based perspective rather than a product-based perspective. Research indicated that’s how this user base prefers to work.

Interpret user stories to create broad user flows and detailed task flows to delineate required screens and suggest the necessary UI components.

Iterate quickly with low-fidelity wireframes in order to get buy-in from the client as well as the thumbs-up from the development team leads.

Create high-fidelity wireframes depicting the functionality of UI components. Specify how interactions interface with the back-end system.

I paid careful attention to crafting components that would be easy to understand and use at first glance, but that could also streamline the user’s workflow.

Our audience was composed of power users, so I wanted to enable them to develop a rhythm to their daily workflow, and fly through fields and menus without having to reach for the mouse.

*Cart with various content states (shown here without annotations)*

Patient-based

In keeping with the patient-based approach, a somewhat unorthodox cart was required. Users often need to submit orders for multiple patients at once, and sometimes the equipment order fulfillment comes from multiple sources.

Content length

I am always careful to deliver solutions that are expansible based on content length. This approach solves for those edge cases where a unique instance of a component may have overly long content — or no content at all.

Annotations

Detailed annotations in my wireframes clearly articulate the functionality and intended behavior of on-screen components. They are an enormous benefit to the designers, copywriters, and developers who will base their work on these project artifacts.

Component states

For a technically complex product I like to show UI components in their various states – e.g. expanded and collapsed, enabled and disabled – and the effects those states have on other page elements.

UX Writing

Whenever necessary, I inject UX writing – copy that smooths the user experience – as a placeholder for content strategists and copywriters.

*Product and Reporting filters expanded views*

Tricky filtering

A large and diverse inventory of products demanded a robust but simple filtering system.

After working with the client to delineate the many and varied criteria users would need to filter on, I created expanded wireframes depicting each filter and the type of input that would be the easiest to understand and populate.

Platform challenges

Sometimes the out-of-the-box treatment that large-platform systems staple onto their UI components can leave users fumbling. So I try to find every opportunity to inject a higher degree of thoughtfulness and usability into my client’s brand. Given the limitations of the Hybris platform, finding the common ground between the ideal solutions and the capabilities of the platform took some trial and error, but with the support of the dev team, we nailed it.

Detailed breakout

Details like hover states and field focus are specified both visually, and within the wireframe annotations.

These things may seem minor, but calling them out in the wireframes helps ensure designers and developers don’t forget to account for them.

“You can capture meticulous user stories, deliver on your conditions of acceptance, satisfy all the requirements… and still end up with a mediocre product if you don’t have empathetic UX designers on your team.”

— Patrick Kuntz

PROJECT

Munich Re

Industry: Healthcare

Healthcare enrollment is complicated. But does it have to be? What if we really think through the experience and build a dynamic, transparent system? My role at Munich was to work with the product owners and subject matter experts to walk through every user story until we got them right.

My role

UX design lead. Art Director. Client-facing.

Create a skinnable, white-label employee healthcare benefits enrollment application that would disrupt the industry.

Research and apply best practice user input methods.

Work in an agile environment with multiple teams spread across the U.S. and Canada.

Create flows and wireframes to articulate a smooth, error-free user enrollment experience.

Provide art direction to the design team to create customizable components and typography for a white-label solution.

Provide UX oversight to 3rd party development team to ensure the coded solution conformed to the wireframes and annotations.

My approach

The client said they wanted to disrupt an industry. They also wanted to think divergently first – try to articulate the best optimal solution – then converge and try to make it all work within a given set of technical and budgetary considerations. I loved them for this.

I brushed up on my research of best-in-class UI for all types of data capture, as well as multi-step processes. I created flows and sketches and worked closely with the client’s product owners on a daily basis.

Working in this way, we wouldn’t waste time during those big presentation meetings debating minutiae – we were already all on the same page.

I engaged the design team early, and involved them in the UX process so they could maintain an awareness of the customizable nature of this product.

Artifact fidelity

The core project artifact – the wireframes – were medium- to high-fidelity. They had to be. The dev team needed a concise reference, the design team needed to know what could be customized and what was hard-coded, and I needed to compose detailed UX copy in order to provide transparency to users.

*Wireflows capturing critical use cases*

Artifact fidelity continued…

But there were also times when mission-critical use cases needed a wider view – something between a task flow and a wireframe – in order to drive discussions.

So I made wireflows as a tool to help keep everyone focused on the same problems.

And while we’re on the subject of fidelity…

Let me offer my 2¢ worth of sage UX pro advice. Fidelity should be a budget consideration in every project. Higher fidelity = more time and more money. If less fidelity gets the job done, use less. Spend that budget where it will improve the product. (Like maybe user research.)

“We want this product to disrupt the industry. So how about we do the UX first, then see if we can make that work from a technical perspective.”

The client actually said this to me in a meeting. I love them for that. This is how you think like a visionary.

When a date field isn’t just a date field

Depending on the nature of the date you’re asking your user for (e.g. birth date, hire date, flight or hotel dates) it makes a difference which type of input you use to enable your user to enter that information quickly, easily, and without introducing opportunities for error.

Thinking about things at this level is where I do some of my best work. This is how solid products – and good user experiences – are created.

Date of birth

Research confirmed that when entering a date of birth, the way to minimize user error and enable the quickest data entry is to use a drop-menu for Month and two text fields for Day and Year.

The reason is any adult’s birth date is several years in the past. Imagine being forced to use a calendar-style date picker to scroll back 20 or 30 or 60 years!

Conversely, a single text field can also be quick, but that solution introduces many more opportunities for error, especially if your back-end system has limited capacity for post-entry reformatting.

Hire date

Since the project was an employer benefits enrollment onboarding app, most users would need to enter a hire date that was just a few days prior to the current date. A calendar-style date picker – which displays the current month by default – was the ideal component. One click and the field is complete.

What I learned

I wish we had built interactive prototypes instead of just wireframes. We could have done it. We had room in the budget. But I was told it “wasn’t sold that way” and that the client “wasn’t expecting prototypes.” I probably should have pressed a little harder. Our usability testing might have been much more illuminating. Maybe we’ll get there on Release 2.

PROJECT

Shimano

Industry: Recreational Equipment

After working with SMEs from both lines of business to create user stories, I created wireframes that would streamline user workflow for bulk ordering from multiple warehouses while taking care to repurpose functionality across lines of business where appropriate. While I always advocate for the optimal user experience in any situation, it is equally important to be a good steward of your client’s budget.

Redesign a B2B e-commerce system while migrating back-end systems to Hybris and AEM. Shimano is famous mainly for two things, bicycle parts and high-end fishing equipment. As you might expect, these two lines of business have some user requirements in common, and several that are quite disparate indeed, particularly having to do with the ways Shimano’s customers order merchandise for their retail stores.

The nexus of experience, interaction, and visual design

The level of detail one puts into a wireframe varies by the project, and sometimes by the page or screen.

The two client teams came to be known as the “Bike” team and the “Fish” team (this is how they refer to themselves).

The Bike team needed all new functionality for their PDP (see adjacent wireframe), including

A non-intrusive, collapsable way to access product details, which are usually only used by new users
A fast way for users to order bulk products in specific quantities in their various sizes and colors.

The Fish team had smaller – albeit completely different – needs for their PDP, but once they saw the proposed solution for the Bike team, they jumped onboard. In this way we were able to save some dev budget and ultimately build a better final product for the users of both lines of business.

Component states and annotations

Wireframes are static (i.e. not interactive or animated), so I try to bake in component states wherever possible in order to specify the intended interaction design. Clients always appreciate this, and it makes the dev team happy, too.

Modals

I try to keep best practices always top of mind, especially when it seems necessary to add more UI to a system, such as a modal.

A modal may be appropriate when a user interaction is required to continue a task but you don’t want to interrupt the user’s workflow with a page refresh; or when some extra UI is needed for an edge case process that is not likely to be needed by most users.

A modal should never be a surprise. It should always be expected by the user, i.e. the modal is displayed as a direct result of a user action. The modal should only serve to aid the user in the continuation of that action. It should also be easily dismissible in the event the user want’s to “go back” to where they were.