Over the course of many iterations we tried to tie certain colors to certain data types (e.g. Location info was orange, and Contact info was purple), but that never really caught on and we ended up informally abandoning it. The result was that some sections of the profile had vestigial color-coded elements, but they were meaningless without the greater context in which they were conceived. We removed these colors, avoiding any potential misunderstanding based on a now-non-existent color system.

We removed color where it wasn’t being used to convey functionality or specific meaning. All “icon jewels” became gray. Unnecessary blue CTAs under Contact info were deleted, and the primary text became clickable. Empty sections (“No Results cases”) no longer had colorful images demanding users’ attention. The whole page became simpler, lighter, and easier to digest.

Revamp your advanced filters

I wrote an entire article about this:

Actually design mobile first

We had been struggling with a five-column, stacking-on-mobile, row pattern for months. The design originated on desktop, and had been massaged and wrangled to kinda work on mobile. Even so, a single row took up the majority of a mobile screen.

Since the multicolumn design converts well, project stakeholders are generally hesitant to change it. As a compromise, we limited the number of columns to never be more than four, and we did a major code refactor that made maintenance easier (Comment if you’re interested and I‘ll write more about the refactor). To be fair, this still isn’t mobile first, but it’s better than it was. We’re working on a truly mobile first solution right now, and will start testing it soon.

Don’t stick elements willy nilly

Left: old version that just sticks at the top; Right: hides the map

Our sticky panels were a constant headache. Implemented on one page they might have been possible to maintain, but the simple reality was that they had to handle too many unknowns, and responsive behavior added a whole additional layer of complexity. On top of all that, they didn’t really add to the user experience. If anything they allowed us to be sloppy in choosing what to put in each panel because we could expect it to just stick around if it grew past the viewport height.

The new sticky panel is essentially a more intentional, restrictive implementation of what the original sticky panel should have been. Since only the last panel can be fixed in place, it forces us to be intentional about what we put there. It also allows us to hide the map, which is a visually oppressive, functionally useless element we are required to keep for business reasons.

Design for the worst, hope for the best

Our subpanel was about 430px at the widest screen size, but could flex to as small as 330px for smaller screens. If everything had to work at the narrow size, why did we ever allow it to take more space than it needed? Our subpanel went from about 1/3 of our page to about 1/4. Limiting the width provided more space for the primary content, and solidifies users’ understanding that the subpanel presents secondary information.

Limit feature dependencies

Putting borders on each panel allowed us to think of them as independent entities, so functionality was scoped and we were better able to rearrange or add/remove panels. Code-wise it dictated that behavior in each panel was self-contained and relatively decoupled. Creating artificial restrictions such as these force designers and developers to think more critically about how they want to implement features. Obviously we could remove this restriction, but our product development process would look like the wild west. We create constraints because they make our design stronger, not because we like to make arbitrary rules.