A brief history of time
When I started working on putting time conditions into our visitor segment builder I thought: “Cool feature, should be simple to implement.”
Our mission? To provide users with the ability to target their visitors on both upcoming and past events. As it turns out, time is not as simple as I originally thought.
Time is deceptive — it’s linear, which makes it appear straight-forward.
But the problem with time is that, though it sits on a straight line, it has many different branches. Different actions cause us to take different paths, and lead us to different endpoints. Deep, I know. It also happens to be a nightmare to fashion into a clear and simple experience for building custom segments of visitors.
So our goal has been to tame time — and to do it without producing a product that resembles the inner workings of the TARDIS (although if The Doctor is in need of customer experience website personalisation and segmentation he should drop me a line).
So, how did we get our head round the complexity of this?
1. We laid out all the possible time options
Use cases are fairly essential to the design process and boy, we have written a lot of use cases. We’ve listed ones focusing on future activity, ones focusing on past activity, ones combining different types of actions at different times, and everything in between.
I’ll admit, all of this did initially seem like a big wish list, but it was actually really useful for identifying themes and seeing where we could cover the most instances of time.
After writing out a number of use case segments it was easy to spot patterns emerging. We started to see where certain segments used the same wording or the same time frames. From that we could prioritise various combinations of time to explore.
2. We looked at existing features
After realising that this was not going to be a simple thing to present, we were wary about adding lots of new functionality to the Adaptive Targeting builder. We wanted to make sure we didn’t overwhelm people and scare them out of using it.
A useful activity was going through the existing language and elements and matching those up with our prioritised use cases. We could quickly see which use cases were going to work seamlessly, and which had a larger learning curve.
3. We compared across industries
Part of the development process has involved making sure that we’re catering for all industries using the platform. The retail industry has different requirements to e-gaming, as you’d expect, and one of the most interesting parts of the process for me has been to work on the requirements for the travel industry.
The time aspect is particularly complex for travel brands: not only do you have the time that a booking was made (with all the variations that come from that), but you also have the duration of the journey itself, the time between the first and second legs of the journey, the time until the journey takes place, to name just a few! After a lot of exploration and discussion, we ended up looking at these as attributes of the ‘product’ being viewed or purchased. We could then create a clear distinction between when a holiday was booked and all the details of the itinerary.
4. We thought a lot about words
There is a disconnect between how humans think about time and how computers calculate and use it. We form sentences that string actions together. For example, I think about my snappy new pair of dungarees and I automatically attach a date to the purchase as part of its story. For computers this is a bit trickier as they think of each action individually. Somehow we needed to connect these two thought processes.
Of course, part of the linking of them together came through the UI functionality itself. But to make the whole process more human and natural, we had to reference how humans think about time and how they’d expect time to function—even when in a mechanical setting.
We wanted to make sure that our users could create that story by being able to say what and when they purchased as part of the same sentence.
5. And the classic — we tested!
Part way through the process I thought we’d cracked it.
We divided the sections up into relative and static time. Things like “First purchase date” and “Last purchase date” fell into the static time category, while “Days since last session” and “Days since last purchase” were categorised as relative. I thought this was unbreakable — we had successfully got a hold of time!
But when we tested in these early sessions we found that splitting up the time functionality into two sections caused more confusion. These users hadn’t been through the whole process so didn’t know why some time features were different from the others.
This seems obvious now. We got so deep down into the nitty gritty details of catering for all the use cases that we forgot about that initial moment when you first see this new feature. So we went right back to basics — allowing users to specify the product followed by the time it was purchased in either static or relative terms.
Hopefully we’ve managed to make the process of adding time a bit easier now!
This is just the first stop on our journey through time and space, with many more lightyears to travel. If you have any comments, questions, loves or loathe send them our way!
Sarah Benson. Product Designer at Qubit — just celebrating my 3 year anniversary — yippee! Give me a bell on twitter @sarahbenson18
Thanks to James, Dave, Giovanni, Simon and everyone else involved in bringing this together.
