Form & Function: Continuing the Debate of UI vs. Functionality
It is the pervading law of all things organic and inorganic, Of all things physical and metaphysical, Of all things human and all things super-human, Of all true manifestations of the head, Of the heart, of the soul, That the life is recognizable in its expression, That form ever follows function. This is the law.
At a panel discussion I moderated recently at RE Tech South on “The Future of Real Estate Search”, a very interesting point was made by the assembled panelists. (And it was a rockstar-filled panel: Corey Kozlowski of Diverse Solutions, Rudy Bachraty of Trulia, Andrew Tillman of Center for Realtor Technology, Greg Tracy of Blueroof.com, Dan Woolley of Dwellicious, and David Carroll or softRealty.com)
The question was whether UI (user interface/design) is more important than Functionality (the actual search logic/behavior). The panelists were nearly unanimous in saying that UI > Functionality.
@robhahn asks at #RETS would you tell agents to spend more money on a web designer(UI) or a programmer to improve search. Panel says UI. If panelist agree UI is more important than search then it doesn’t bode well for @robhahn (OnBoard) lifestyle neighborhood search.
Because we were so limited on time (30 minutes to get a discussion with six panelists?) I really didn’t have the chance to get that discussion going. But that’s what blogs are for, right?
I made a semi-serious point to Greg via Twitter that it wasn’t whether panelists agreed that UI > Functionality that bodes ill for our Lifestyle Listings Engine, but whether they were right or not. I’m going to argue (surprise!) that actually, functionality trumps user interface when it comes to foundational enabling technology.
Form Follows Function: We All Agree!
The principle that form follows function has been a cornerstone of modern architecture and design for over a hundred years (Sullivan wrote his manifesto in 1896). And it has been adapted in large part into the art and science of user interface design.
In fact, the entire notion of “user interface design” is premised upon using visual, audio, and textual cues to help a user accomplish something. Otherwise, it would simply be called “graphic design”.
And I think Greg Robertson would agree with that. Design is not how something looks, but how it works.
The real question then, is not whether UI/design should be divorced from functionality for the sake of satisfying some designer’s creative urge, (and to be fair, none of the panelists were making this claim) but which takes priority for the real estate web: user interface design or functionality.
On Priority: Argument for Why UI > Function
The strongest argument that UI trumps functionality is that the greatest functionality in the world doesn’t mean jack if it’s hidden behind crappy UI. If folks can’t figure out how to use a thing, then it don’t much matter what that thing can do.
For example, take a look at this:
This is a tool for building and executing SQL queries. Given any set of real estate data — including listings data — the functionality of a tool like this is enormous. You can probably find whatever property you may be looking for, narrow down results quickly, and so on.
But it is safe to say that a real estate search site that simply puts a SQL query front-end as its “Find a Property” interface will fail miserably. Unless you have a specialized practice catering only to database administrators. In which case you’re probably going to be out of business soon enough.
In today’s real estate world, what determines success or failure is user interface design. Companies like Trulia, Blueroof, Diverse Solutions, and softRealty spend thousands of manhours and millions of dollars creating compelling user experience for search. That these websites hold a competitive advantage over a poorly designed site is readily demonstrated by traffic analysis or simply by putting a consumer in front of a computer.
(It should also be mentioned that far too few brokerages and agents pay enough attention to UI design. Greg Tracy said, after reviewing a circa-1997 website, that it looked a lot like most realtor websites in 2009.)
Functionality vs. Enabling Technology
On the other hand, there is a distinction to be drawn between “functionality” and “enabling technology” — what one might call a foundational functionality.
For example, Adobe Flash is enabling technology. It enables all manner of other functionality. Things that could only be dreamt of before that technology is introduced are now made possible.
Google Maps is also arguably foundational functionality, because it expands the universe of what is possible. It seems to me that the introduction of Housingmaps.com by Paul Rademacher in 2005 was the seminal breakthrough for real estate web. (In fact, Housingmaps.com may have been the spark that lit the Web 2.0 fire.)
After Google Maps (and Housingmaps.com), it seemed that you could not design a real estate website without incorporating listings with a map display. All of the second-generation real estate websites of today owe a huge debt to the original Housingmaps.com and to Google Maps.
The key point here is that design, and user interface, naturally followed these foundational functionalities. Once the enabling technology made it possible to put listings information right on top of a graphical map, the user interface had to adapt to make that possible. Search boxes shrank in size, moved to the margins, etc. in order to accommodate the screen real estate of a map. Designers began to put links into the pop-up bubbles, and map-based search began to make an appearance.
At the same time, however, as Dan Woolley of Dwellicious mentioned on the panel itself, while visualization of search results took a giant leap forward with the introduction of mapping, the property search itself hasn’t changed very much since the earliest days of the real estate web. We are still living in the Zip/Bed/Bath world for the most part — map-based search is the sole exception.
Whether it is Realtor.com of 1996 or Trulia of 2009, the paradigm of search itself has not changed much: property features/characteristics within a geographical boundary.
That paradigm is what we have set out to change with Lifestyle Listings Engine (LLE).
Our view is that if we are successful with LLE, we will enable a range of new functionality that is currently unavailable on the real estate web. And that this new set of functionality is something that consumers are hungry for.
The theory — which we are testing, by the way — is that when people go to perform a property search online, they are actually not looking for a “3BR, 2BA house in 07054 under $700K”. Our theory is that what people are actually looking for is something like: “Someplace with enough space for the kids, with good schools, that we can afford on my husband’s salary… and boy, it’d be nice if there were some decent restaurants nearby.”
In conversation after conversation — and now, in focus group session after focus group session — we are finding that consumers have a picture in their head of what they want. Usually, these pictures are very hazy. It takes time and a good deal of research to go from hazy desires to defined set of criteria like “3BR, 2BA, $700K in 07054”. The process is filled with frustration, dead-ends in research, and a real sense of powerlessness on the part of consumers.
We think that consumers would use a tool that can more directly translate what is in their heads to results on a webpage. We believe that this functionality will drive a new period of real innovation in the real estate web. We think that talented developers and designers within real estate can’t wait to get their hands on a new toolset that will help them deliver new ways to answer consumer questions. LLE is not, in my opinion, “lifestyle search”; rather, it makes “lifestyle search” possible.
That will require excellent user interface design. Just as the introduction of mapping (and related GIS concepts) to real estate brought forth a new generation of user interface design, I believe that “lifestyle search” will change the user interface in fundamental ways.
I don’t know what that UI will be. Is it a single-field natural language search, like Google’s? Is it a set of dials and levers and sliders, similar to Kayak? Who knows? But I do know this:
That UI will follow function.
This is the law.
Please contact us if you have questions about the underlying data referenced in this article, or would like to have access to that data in the form of custom reports, API or bulk files.