I’m working on some wireframes at work, which include a list of “amenities” for classrooms. And I realized that I’ve never designed anything with this many amenities before. For smaller lists I’ve used bulleted lists broken up by headings. But this is different and after mocking it up as such, it just doesn’t work. This led me to give some thought to a new layout. Writing this blog post is you witnessing me sorting out those thoughts. What a privilege ;)
When teachers want to “book” a classroom, our current method of searching is very outdated. My team and I have been tasked with creating a new app complete with a new interface and experience. But first, I wanted to really wrap my head around what the goal of this app was, and simplify it down to that basic need.
The psychology of search results
The goal of using this application is to find a classroom that meets all of one’s technological requirements, from DVD and Blu-ray to presentation recording and Smart Boards, even to 16mm projectors (yes, we still have those).
I started by thinking about search experiences I’ve had, specifically with hotels or other things that offer certain amenities. What do I want the experience to be like? What do I expect to see on the search results screen? On one hand there’s your basic web search engine, which searches the web for the most relevant sites that match the keywords you’ve entered. The results are familiar, showing the title of the website/webpage, a description, and maybe when it was last updated. We know that the results higher in the list are the ones suggested to be most relevant.
But a web search engine isn’t what I’m going for.
After choosing a building or two, a time slot (or dates and times if it’s a multi-day requirement), and my technological requirements, I’m brought to the results list. This list only shows the building name, room number, and the address (which is clearly visually secondary to the name and room). Hovering over each result item causes a button to appear (it’s hidden to reduce repetitive clutter) which takes you to the view details screen.
On that view details screen is where my struggles are. Do we show all of the options and use icons (checks or exes, probably) to show which things are available and which are not? Or do we only show those options that are available?
Option one: showing only available options
Showing only the available options was my first gut instinct. It reduces the number of “things” on the screen and reduces confusion by not having items that aren’t available. It only shows you what the classroom does have. You’ve searched for your building and the tech you need, now you can see everything available, get-in, get-out, happy day.
However, if you happened to forget some piece of tech that you need, only showing what this room has, is much less likely to give you any sort of reminder.
A mockup showing only available options
Option two: showing both available and unavailable options
On the other hand, showing a well-designed table with everything, and then using green checkmark icons and red ‘x’ icons (or only the green checkmark icons?) to those pieces of tech the classroom does and does not have, could be helpful. It adds more information to the screen, but if it’s designed well could help you remember that one thing you forgot? Maybe you also need an HDMI connection, or maybe you need a computer in the classroom?
Mockup showing both available and unavailable options. This could help remind of something you might’ve forgotten that you need.
Which is the better method?
Have you worked with this type of layout before? If so, which path did you choose and why?