The Needs
We’re focusing this week on creating a simpler, more intuitive meeting room booking system. A system that could potentially be used by both the technologically inept and savvy alike, in any size company. As booking meeting rooms is a regular event (at least it is at Headshift | DachisGroup), the UX should allow for incorporation into the users daily tasks.
The needs of the users are: A quick and accurate view of both free and booked time, as well as easy creation, editing & sharing of events.
So to reiterate. The possible personas could be:
A tech savvy user who will be frequently booking rooms within a medium to large company.
A user who is not overly confident using a booking system, but still uses it regularly (this could be in a smaller company).
The IA could include: locations, colleagues, time/date of meetings and event description.
If you want to try this weeks week’s example, do your design now (no more than 10 minutes) and then continue reading.
The Outcomes
We concluded from our designs that the three primary use cases for scheduling systems were: viewing availability, checking bookings & creating events.
Creating an event / viewing availability
The most important improvement was regarding the creation of events. This raised a question on the importance of viewing existing bookings, which, from the perspective of users who are creating bookings, may be of little relevance. However, it is also worth noting that although removing existing bookings from the UI may make sense from a functional perspective, the user may not understand this change and its effects on the UX due to their pre-conceptions of how to interact with a booking system. Creating an event should still theoretically be the simplest interaction to make within a scheduling system. Here are some examples of our outcomes:
- Simple one click creation – Making available time slots actionable.
- Having saved preferences – Book a 45 minute meeting
each week at varying times? Insert this booking into the calendar from a list of favourites or recently created events. - Responsive – Input booking criteria to retrieve relevant feedback on available slots of time.
The simple one-click creation of events could be implemented into the UI, allowing interaction with slots of free time. This approach raises the issue of familiarity again. The interaction with free time may confuse some users at first as it differs from their past experiences, but if designed well, this change could alter the users habits.
I feel saved preferences could also be an easy solution for event creation, these preferences could be saved within the system and interacted within menus, ribbons, sidebars etc.
Checking your bookings
In many ideas this became a tool to manage time in a general manner. Colour identification was used for a variety of filters such as event type and location, as is the case in many existing scheduling systems. Having a desktop widget which displayed scheduled bookings was another idea, this separated the creation and viewing of bookings (in some respects).
The Calendar
Every outcome differed on the visualisation of time. Many ideas filtered time with other variables such as room numbers, floors, room size etc. Also, having groups of filters could allow the user to view timelines relevant to their needs, reducing the amount of information on the screen.