We’ve already written a little on one of our other blogs about the lean approach we’re taking to building our new product, PingPong: a tool to help product designers and startups quickly schedule ‘test sessions’ with users so that they can carry out user research and interviews.
We’re building PingPong as an internal side project alongside our client work and other commitments. We don’t have an infinite amount of time or budget to spend on it and the goal at hand is to get the product to be self-sufficient as fast as possible.
This means we need to limit our allowance of what we call iceberg features. They include important features which may look doable in an initial version, but will suck up our time if we try to do them properly. And this is time that will inevitably have to be taken away from other work on the product’s features, business model and marketing.
The last thing we want is for our little ship to be sunk by an iceberg at the very beginning of its voyage!
We want to share a real example of how we’re trying to stay as lean as possible and navigate around icebergs with some ruthless prioritization and sneaky tricks.
The iceberg: Session booking UX
As you can probably guess, one of the most important pieces of functionality needed for a product like PingPong is a solid booking system for test sessions. When we send out invitations to users, we want them to be able to effortlessly accept the invitation and book a slot to join a test. The more friction in this part of the process, the fewer sign ups we’ll get. This of course, makes the product become less appealing to our paying customers (the product design teams).
An ‘accept and book your session’ screen might sound like a simple feature. All we need to do is define the dates for the tests and then let users select from a list of available time slots. We’ve built the product in Rails, so it should be simple to build this out–right?
Not so fast. Creating a strong UX for this isn’t so straightforward and there are many things you may not have anticipated:
- You need a really clear date and time selection UX so that users book the right dates and don’t get confused.
- ‘Available dates’ are not as simple as saying “any time on 3rd or 4th July”. Interviews are usually conducted by 1 or 2 people and only 1 test session can happen at a single time. You also need to factor in the working hours of the person conducting the interviews, test sessions that have already been accepted and booked by other users and break times. It may even be necessary to add sufficient ‘padding’ around sessions to allow for overruns and delays and avoid having sessions collide.
- You need to allow for multiple time zones–asking users from all around the world to select a time in Coordinated Universal Time is not good UX. It’s best to show the available session times in the user’s local timezone.
- We want to avoid receiving 20 bookings when only 5 test sessions are needed. And so, we need to be able to set a limit on the number of sessions that can be booked.
- When a user books a session, this needs to be added to the interviewer’s calendar so they don’t forget to attend. We also need to send a reminder notification to the user just ahead of the test session for the same reason. No-shows could hurt PingPong’s credibility with both of our user groups (interviewers and users).
- We need to allow users and interviewers to cancel the test sessions if a problem comes up. If there are changes to event times, this needs to be updated in both the users and interviewers calendars too.
So we build all of this (kinda)
Here’s what our booking UI looks like:
Looks great, right? It does indeed meet all the requirements we mentioned, but we actually cheated a little. Actually, we cheated lot.
You see, instead of building all of this ourselves, we realized that a little product called Calendly, which we were using in our day jobs, would be the perfect little solution for now.
We’re actually including a direct link to Calendly into the invitations we send out to users. So the invitation looks a little like this:
Sure, we’re entrusting a core part of our product to a third-party service: there are risks associated with that and we don’t underestimate this.
But the alternative: to try and build this ourselves and invest our limited time and budget into re-building a piece of functionality that’s available at very low cost to us, is not a smart (or lean) move.
We know we need to tackle this iceberg eventually. But let’s not try to do that right at the beginning of our journey, when there are so many other parts of this product that need our attention.
You’d be surprised at how lean you can build a product, even if you do have the skills to build features you’d like to add. As we’ve said before, the last thing you need is a programmer.