Calendar Widget Round 1 Designs

My brief was to redesign an existing calendar widget used to create date filters with Relative and Absolute Date Ranges. Below is my first pass with notes on the old design’s weaknesses and a description of how this new approach would be more effective.

“Updated designs for the Calendar widget used to create date filters with Absolute Date Ranges. My Project Manager wants to get this underway by Wednesday, so any quick feedback is appreciated!” — Ryan

Feedback on Round 1 Designs

This feedback is from another Product Designer. True to the product designer role, his feedback is primarily concerned with making the user flow as efficient as possible. His point about designing a solution without presuming a user’s intent is excellent:

“I like…

1. The neatness of the expanded menu in revealing the calendar
2. The visual clarity of the language in communicating different date states (hover, highlight, select, range, etc.)

My challenges…

1. Large Time Ranges
Seems to be a lot of clicks to play with larger date ranges. I imagine in non-operations, big-data worlds we will want to define large ranges fairly often, i.e. across months certainly, likely across years. This is one reason we favoured an immediate feedback style slider for setting large ranges. You can always fine tune with the calendar picker once you’ve set the larger range as close as you can.

2. Guesswork
We went through just about every hoop in figuring out how to allows users to set start and end dates with the fewest clicks and came to the realization that it’s extremely hairy to guess their intention. So we avoided automatically switching from setting start and end, or swapping the values. You have to physically indicate that you want to set start, and then move yourself to setting end. Otherwise you get into questions like “Just because I clicked past the previous end date, how do you know that I wanted to move my end date? I actually wanted a new start date” or “Why did you switch my values? I just wanted to move my start date and reset end” etc.”

Feedback from a Visual Designer. He’s concerned with color contrast and consistency with our Salesforce1 product:

“Great work Ryan! This is a ton of work in a short amount of time.

Just super quick feedback on color. The Range Value blue doesn’t have enough contrast between itself and the blue background. I would try to bump up the contrast between the two.

Another background color could be a solution. I think this blue is much more interesting than the white calendar but what are gaining from it?

If you go white we can carry a base level of consistency with S1 and avoid the vibration between the blue outline of the menu and the blue calendar background clashing. That solid blue background as cool as it is pushes against the light and airy feel we want to strive for Solaris [color palette].

For the date field try leaving the text black and just using the blue outline and arrow below to indicate selection. Unless you think we need more highlight to call it out?

Again killer stuff. Lets talk in person more if that helps. This is a pretty complex tool you’re designing here.”

Feedback from a User Researcher who’s seen users confused by the old design during his research sessions. He’s the most familiar with the problems I’m trying to solve, so it’s good to know he thinks this is a step in the right direction:

“Really liking this new direction, Ryan! I think this could go a long way toward addressing the confusion we saw with end-users discovering absolute vs. relative range selection functions, and the use of a sentence-like structure makes the start-end selection process clearer for absolute ranges.

I wonder about ways to help see the “big picture” with ranges that span multiple months, or cross over a monthly boundary — have you explored those? (Apologies if I’ve missed it…)

I’ve seen people struggle with having a one-month keyhole (e.g. seeing only the days in March), when they’re trying to select or modify a multi-month range (such as from January 15 through March 15). Hope that makes sense.

I realize there might not be a solution to this, given that people’s scales/scopes will vary based on use case, but early calendar investigations revealed that some people expected to drag-drop start/end dates.”

Round 2 Designs

My responses to the first round of feedback, with updated designs incorporating some of their suggestions:

“Thanks for the feedback everyone. I’m still working on some iterations to address selection behavior (what happens when you try to put a Start point after an End point, etc), but I have a new solution to address scale.

My concern with the current slider is that it is used to select values, however its nearly impossible to land on a specific precise value. However, the interaction of a slider is convenient in that it can replace the high number of clicks needed to drill in and out of years/months/weeks.

So, instead of selecting values, I’m proposing the calendar slider be used to dynamically change the scale of the calendar input. Simply sliding would enable the user to quickly move from viewing days to viewing years and back into days. Still working on how selection will work within this concept. Will keep you posted.” — Ryan

Feedback on Round 2 Designs

Feedback from my primary manager. Her role is to oversee our designs and make sure our team is operating effectively. Here she’s noticed inconsistencies between my design and well-established patterns for Slider behavior.

“Awesome! This approach significantly simplifies the date picker interactions. Interesting use of the slider. One quick note:

Based on slider patterns, I expect to be able to pull the slider to the left of Years in the 3rd screen. Would it be possible? What is the value when you have the circle on the left-most point of the slider?

If that interaction is not possible, then maybe this is more a stacking metaphor than a slider metaphor. In that case, I’d expect the order to be weeks, months, years instead of the reverse.”

Feedback from my other manager. He’s been at Salesforce for ten years and is responsible for many of the current product’s design patterns. He suggests simplifying the selectors to more common existing patterns. It’s important to remember you don’t always need to come up with a novel solution. Often the right direction is one users are already familiar with.

“Much better. For the range selector, since there are only two options, it could be a more explicit toggle.

“Select Relative Dates” flips to “Select Absolute Dates”

Slider interaction is a bit strange. Why not just…

Day | Month | Year

below the range toggle.”

Round 3 Design Spec

My last note to the design team with a spec file I gave to the developers.

“Here’s the spec I submitted to the scrum team. Thanks for all the feedback, I ended up integrating a lot of it.” — Ryan

The End Result

Ultimately, this design wasn’t implemented. Other features were a higher priority and the Project Manager pushed these designs back. By the time the scrum team was available to address the Calendar Widget, a new designer had joined the team and was selected to take over this small part of our product.

This result isn’t uncommon in an agile environment at a large company. As a designer, we use visual deliverables to move the conversation forward. My design influenced another design, which influenced another design, and so on, until a final version is produced. Even then it’s likely User Research will discover some inefficiencies and we’ll make adjustments to future versions down the line.

In design, you can’t get too attached to a single solution because nothing is ever “done.”