When2Meet vs. LettuceMeet: a case study in UI and aesthetics
Why aesthetically pleasing design isn’t necessarily good design.
Not all scheduling apps are created equal.
As any college student will tell you, we use When2Meet almost religiously. Between classes, extracurriculars, work, and simply living, When2Meet is the scheduling app that holds all our commitments in a tenuous balance. There’s a lot of reasons why we like it: it’s free, easy to use, and has no frills.
On that last part: When2Meet is so no frills to the point that it almost feels undesigned. It’s typeset in Arial, not Helvetica; its accent color is a blinding electric green; and anywhere from a third to a half of the home screen is its black footer. “It’s not aesthetically pleasing, that’s for sure,” my friends would say, and I’d agree. For a site that hasn’t changed much at all since its debut in 2012, When2Meet certainly won’t be winning any design awards anytime soon.
Compared to When2Meet, LettuceMeet looks amazing (at least, at first glance). The site is typeset in Quicksand, a pleasing rounded sans serif; there’s a healthy amount of whitespace; and the tool maintains an overall clean aesthetic.
However, despite LettuceMeet’s aesthetically pleasing design, I’ve yet to see it used in the wild the way When2Meet is. So why has LettuceMeet not permeated the campus consciousness the way When2Meet has?
Aesthetically pleasing ≠ good user experience.
Part of the reason LettuceMeet hasn’t been used more widely is its relative infancy, having debuted just last year. More importantly, though, is the fact that underneath the sheen of tasteful typefaces and pretty placements lies a far inferior user experience.
The problem lies in the flow that LettuceMeet forces into to input information. Take, for example, the steps required to set up an availability calendar:
The user must go through two whole pages before getting to the meeting link. Compare that to When2Meet’s economical page that gathers everything you need to know in one go:
Actually adding availability in LettuceMeet isn’t much better, requiring users to go through three more pages before seeing their availability on-screen:
Compare the above flow with that of When2Meet, which condenses the same task into two pages:
By splitting information up into separate pages, LettuceMeet forces users through a taskflow that isn’t necessarily intuitive to how we chunk information. Why must we select what days to meet on one page and what time range on a different one? Why am I adding my availability before declaring who I am?
For a user who wants to schedule a group meeting quickly and efficiently, the streamlined taskflow of When2Meet just feels right, reinforcing the information I need to provide and then providing an immediate response to my need.
Remember the U in UI.
Let me be clear: When2Meet isn’t great design. There are many improvements one could make to the overall experience, like drawing more attention to the required info in When2Meet, or consolidating the taskflow for adding availability to one page. Moreover, LettuceMeet might get the upper hand on mobile, where its responsive design and bite-sized steps make a little more sense.
However, what When2Meet does better than any of its alternatives is understand the needs of its users, who prioritize efficiency over attractiveness. Despite the relatively steeper learning curve in figuring out how to use When2Meet, using it in the long-term is far less cumbersome than the multi-page design of LettuceMeet, aesthetics be damned. And on the whole, When2Meet’s core tasks are better implemented than LettuceMeet’s.
As UX designers, it’s very easy to get lost in the pixel-precision we desire—the thing is, that’s only one part of what we do. In actuality, we are tasked to create intentional experiences, and things like typography and color are tools to design for those intentional experiences. Rarely is a fundamentally bad user experience improved by making it pretty. So what do we do?
Keep the user in mind as you design your interface, and have users test it out themselves to ensure its usability. What are their needs? What do they prioritize? And how can I design this experience intentionally to meet their needs and priorities?
In this way, we aren’t making just pretty tools; we’re creating intuitive and useful ones, too.