How we built our calendar @ CharlieHR
Why write this article?
To learn from re-living the experience.
What is the intention for readers?
To show people how we release and build features at Charlie, and share our personality.
What can readers do to help us get better?
Challenge our process, our thinking, offer feedback, or join our team. You pick.
One of the latest features to arrive on Charlie was our long awaited calendar. Being one of the main team members who helped to deliver it, I’ve been challenged by the team to write up the process, explaining how and why we made the decisions we did to get it out the door.
In acknowledgement, we have to shout out our current users, we received a lot of encouragement from them to build a calendar. Feedback informs a lot of our decision making at Charlie, and as such, we knew we were building something the crowd wanted. Equally, we recognised for a long time that our product missed this key piece of functionality.
For that reason, and to be more open about our internal process, we wanted to share how our calendar was born. In this article I’m going to talk about the three main challenges we faced when delivering this feature. I hope you find it insightful and learn something from how we overcame them.
The start of our journey
At the start of the process we spent a lot of time considering what a calendar may look like on Charlie and how we wanted users to interact and gain value from it. This bought us quickly to our first challenge.
Challenge 1: One size does not fit all
One of the most important things to consider whilst designing and building a specific feature, is the relationship between the volume of data and the ease at which you can infer meaning from it.
With that in mind, our current product is built for companies sized between 2–250 people; and within that bracket lives a hugely disparate amount of data for companies. With that disparity comes the fascinating challenge; how do you make a calendar view that is functional, informative and simple to use for both extremities?
Very good question. We thought the best place to start would be to replicate data-sets of lookalike companies. So that’s what we did.
After that, we knew a lot of great products already existed in the calendar space, with the likes of google and outlook having solid, well established products. Therefore, we decided to build on the shoulders of giants, learn from their mistakes and skip the initial work needed to get us up and running. Once we had thrown the dummy data in to these products, we immediately identified where we could improve and the lessons to be learnt for the next steps of our process. Win.
Initially, our learnings matched what we expected, their presentation of information was solid, yet a little limited. Calendars like these work for smaller subsets of data, achieving the basic task of managing a personal calendar really well. However, with the introduction of larger data-sets, the view starts to crowd and become un-informative.
Interesting finding number one: the filtering system in these calendars operate on a slightly forgotten level, with the interface being difficult to navigate and discern meaning from. Therefore, our filtering must be intuitive and easy to use; meaningful data should be presented in a digestible way, with smart defaults loaded to the view.
With knowledge in tow, we marched on.
Challenge 2: Give them what they want
Right, we’ve arrived at the realisation that filtering is where our calendar will be either made or broken. Great, but now we had to come up with a solution that solves this problem.
At this point in the project three of the team separated themselves to break the back of this challenge. I wasn’t one of the three, and I believed that fact served us well. In doing so, we bought some fresh thinking to the table and looked at our problem from a new perspective.
The team sketched out a number of different avenues for exploration, and presented them back to the others involved, including myself. The transference of knowledge helped us to move forward with an agreed implementation in mind.
We knew that initially for a calendar to serve any meaningful use, it would need to show you when team members within the same team had overlapping holiday as a bare minimum, simple enough. That informed how we would initially load the data to the calendar and what type of filtering would be handy for users. Momentum. However, we still weren’t fully sure how the information could be quickly scanned and provide value. Two steps forward, one back.
Challenge 3: Create meaning from the noise
Now that we’d overcome our first two challenges, we drew back our sword with confidence and launched forth at our third.
The final question we asked ourselves was: how can we create visual meaning from the data displayed on the screen, when filters are applied?
The primary direction we were exploring involved applying colours to the Time Off data based on the filter that included it as part of the search result. This got the ball rolling for us, and we began to find it increasingly informative to use. With a bit of work, this direction developed in to a rather nifty one, and one that we are pretty proud of.
And thus, our sword had slain our final foe, we marched forth with our pride in tow.
Once we’d settled on designs and an implementation strategy, the team got to work building the goods. The build process was actually pretty quick, due mainly to the fact a lot of the big thinking was done up front. We ended up with the below as our first deliverable, not bad for a couple of weeks of effort.
There is none. We had some challenges, and we worked to overcome them. In the end, we built a calendar and it was a fun challenge to tackle. We hope you find it useful. Thanks.
Huge shout out to the legends Involved in the process; Neo, Jørgen, Katie, Dan & Tom
Brief aside, I wanted to acknowledge the cross pollination of thinking that occurred throughout this project. In my opinion, this produced an outcome far greater than what could have been achieved in isolation. Inclusion and shared thinking for the win.