Bringing Bench Accounting's date picker up to speed with their new UI.
My role
Lead designer

Collaborating with
Design: product design team
Product: PM, engineering
Business: operations team, sales team

June 24, 2021 — July 8, 2021 (2 Weeks)
What is Bench Accounting?
Based in Vancouver, BC, Bench Accounting supports thousands of small business owners across the United States when it comes to understanding their finances. From daily bookkeeping to year-end taxes, Bench aims to make dealing with the financial side of a business simple and effortless. What initially started as a service offering has naturally grown into Bench developing their own software to better serve their customers, as well as enable their in-house accountants to succeed at their jobs.
At the time, Bench had recently shipped V2 of the UI to a small group of existing users, as well as any net new users that join Bench after. 
Since the update, we received some feedback from users who transitioned into V2 that they were no longer able to quickly select the date ranges they needed to generate and view financial statements.
This was a problem because business owners are usually wanting to look at monthly, quarterly, or yearly reports. Having to manually select the specific days for the date range was not only inefficient and time-consuming, and prone to error.
For example, if a user wants to see how they did in Q1, they would have to remember what dates are within Q1 and manually input them. As we all know, humans are prone to making errors, if you’re off by even one day, it can throw off all sorts of numbers that the business relies on.
On top of all that, the V2 date picker looked like something out of Windows 98, which clearly didn’t match the rest of the new aesthetic. This was an opportunity to fix that as well.
Things to consider
There were some things to keep in mind while redesigning the date picker.

User considerations
➔ Enable users to select custom date ranges
➔ Provide users with relevant preset date ranges

Design considerations
➔ Make sure the new date picker adheres to the V2 aesthetic
➔ New design supports all current use cases for the date picker

Product considerations
➔ Work with design team, PMs, and dedicated front-end engineer in the process
➔ Be aware of constraints due to the technology used to implement component
The date picker as we know it
I looked at the date picker from our V1 UI since about 80% of our clients were still using it. Maybe I can borrow some ideas from there?
I liked the simplicity of how the V1 date picker worked. The preset ranges provided to the user a quick and intuitive way to select the range they cared about. What if they wanted to check the transactions on a particular day or over the course of a certain week? While it’s definitely possible for us to get this information from the data we have, we don’t expose this ability to the user.
While the date picker in V2 enabled users to select a “from” and “to” date, giving them the flexibility that was missing in V1, it looked out of place in the new UI. It looks like we took a very generic date picker, plopped it in and said good enough. It was also missing the preset ranges that I knew our users were missing.
There has to be a middle ground where I’m able to have the best of both worlds.

Bench's V1 UI

Bench's V2 UI

How are other people doing it?
I looked into how other companies designed their date pickers. Smarter people than me had spent a lot of time and resources building date pickers, so I used some of their designs as inspiration.

Stripe had a simpler calendar with fields for a start and end date built into the component. It had a “Custom” drop-down that was interesting, as well as other options such as “Quarter to date” and “Year to date”. That might be something I can use.
After thinking about the “Custom” drop-down a little bit more, I came to the conclusion that something like this wouldn’t work very well for my use case. With how bookkeeping works, users need to be able to quickly view different years and compare them. This dropdown just wasn’t conducive to a flow like that.

Airbnb had a cool date picker that would show two months at a time. I thought this was an interesting idea that I might want to try out. The added element of the highlighted dates on the calendar appealed to me, as I thought this might help users visualize the date range they had selected. It also offered something like preset dates if you selected “I’m Flexible", but it didn’t fit the purpose I was looking for.
As you’ll see later on in this case study, I created some mockups similar to this one, where the user could see two months at a time. While it looked nice, it didn’t really make sense. For our use case, users would likely want to look at their financials over several months rather than anything shorter than two months.
I decided that this two-month view was not the way to go.

I took a look at Zenhub’s date picker, which is very similar to Airbnb’s date picker but it didn’t offer any preset options. I was again initially intrigued by the two-month view, but then when I realized that it wouldn’t work I didn’t continue looking into this option. Zenhub’s date picker didn’t work for the same reasons that Airbnb didn’t.

Amrinder Sandhu’s case study
I happened upon Amrinder’s case study while looking up best practices for designing date pickers. I found his designs and findings to be very helpful and inspiring. Seeing his designs really showed me all the different ways one can approach designing a date picker. There were many ways to jump to other months or years and options to select preset date ranges. While there weren’t really elements I wanted to borrow, I did get inspired to explore different options in my designs.
Customer feedback
Due to the time constraint, I didn’t have as much time as I would have liked to research all I needed to know about date pickers. I had to be selective in how I wanted to get the information I needed so that I can make the most informed decision I could.
Because of this time constraint, I couldn’t set up interviews and talk to users myself. Instead, I had to rely on getting second-hand feedback from account executives. I would have loved to conduct some interviews myself, but this second-hand feedback was better than nothing.
Design iterations
With all the information I had collected, I started creating some mockups. I designed a variety of date pickers. I shared these variations with the design, product and sales team for feedback and to see what aspects they liked and disliked.

Single-day date picker. Users would have to select "to" and "from" dates individually.

Date picker with two months visible at a time.

An early iteration of the hybrid date picker with a large toggle at the top.

An early iteration of the hybrid date picker with a smaller toggle at the bottom.

Narrowing down our choices
Eventually, we narrowed it down to a hybrid date picker. Just this variation alone has its own host of iterations. There were a lot of discussions around where the toggle should go and how it should look.
I experimented with the toggle at the top, bottom, and different toggle styles. I finally settled on the right-most design below that has the larger toggle at the bottom. I moved it to the bottom because it’s not a primary function, a user would be looking to pick a date first rather than swapping modes right away. The larger toggle is more obvious and is easier to click compared to the smaller toggle which would require users to be more precise.
Toggle labelling
Then there was what the toggle should say.
Here I got to flex my writing muscles. There was a lot of discussion in Product and Design around what type of words we should in order to be clear yet concise. Near the end, we were tied between “Default | Custom” and “Preset | Custom”. We ultimately decided on “Default | Custom” because we felt the word “Preset” could be confusing.
The “Final Final For Real” Designs
After many discussions and iterations, we decided on the final design. To start, we provided a means for the user to clearly select the year they were looking at via a nifty year-selector clearly visible at the top of the date picker. Below that, we either showed default date ranges that users would most frequently use, or gave them the option to select specific dates if they toggled it to the “custom” mode. Most importantly, the date picker finally looked like it belonged in our V2 UI! 🎉
Client feedback
The date picker has been in production for a while now. Some changes have been implemented into the product since then.
New elements that were introduced after the date picker was implemented are now competing with it and confusing users. (The “Range” button)
As you can see, the “Bookkeeping Status” card has month and year buttons, so I understand how users think that this is a date picker. The location of the date picker button is also lost in the UI now, and it's unclear what it is for. Is it for the Bookkeeping status card? Is it for the whole page? Is it a mistake and just randomly there? It’s unclear because it’s not really grouped with anything.
As for feedback on the date picker itself, it seems that the way that it functions currently didn’t exactly match what I had in mind. I was expecting it to default to having the entire current year selected, but I don’t think I made that clear enough in my designs. This is one of those times I wish there was a design QA phase in the development cycle at Bench as I likely would have caught this.
If I were given the chance to improve upon the date picker, I would definitely take some time to speak with our users and observe how they use it. The second-hand feedback, while helpful, did not give me insight into what our users are really trying to accomplish. I could only base my designs on what other people told me about our customers. I wasn’t able to really dig deep into the core issues that they were experiencing. Which I believe would have helped immensely during the design process.

Take a look at my other projects!

Back to Top