Purpose in Functionality
As a web designer/developer, I’ve found that there exist several common (if not nearly universal) truths when it comes to clients. One of these is that they love to talk about functionality. I have had several clients whose initial approach when they contact me is to provide me with a complete list of functionality – in other words, a listing of what they think that their website needs to do.
What I tend not to get quite so often is a description of what the purpose of the site is.
To my way of thinking, that is a problem. Recently, I wrote an article entitled “HTML (and CSS) do not a Website Make,” in which I discussed some of the things that I thought constituted a website. Obviously, part of the argument that I make is that a website is more than just its HTML and CSS, and one of the areas that I touch on is the notion of purpose. I think that some of what I wrote there has an important bearing on what I want to discuss in this article, so instead of rewriting it, I will simply quote my original words:
Every website should have a purpose. It may be to inform potential customers about your business (probably one of the most common types of websites). It may be to function as an informational resource. It may be to connect people with other people. It may be to showcase yourself, or even simply to entertain. Whatever the purpose is, it is ultimately the core of the site, the nucleus around which everything else that we have looked at so far is ultimately wrapped.
The purpose of a website is, in a very real sense, also its heart. It is the very reason for its existence. Every other element should be built, created and designed to support that purpose in some way. This of course, includes the basic (or advanced) functionality. In fact, I would even go far as to suggest that this relationship of support between functionality and purpose is actually more important than the actual design–which is not to say that the design is not important (because it most certainly is).
Since I’ve been spending a lot of time there lately, let’s take a site like the popular design community, Dribbble as an example (you can follow me and no I don’t have any invitations). The purpose of the site is ultimately to connect designers together and allow them to share what they are working on and provide comments or feedback on what other people are posting. It was created to foster a spirit of camaraderie and connectedness, through the very act of great design, and the basic functionality works to support that purpose.
Let’s take a closer look by comparing the purpose of Dribbble with some of the existing functionality.
To start, the purpose of the site is (as already noted) to allow designers to share their what they are working on, in varying stages of completeness. To achieve this, it is necessary to allow users to post their screenshots. Without this little bit of functionality, there would be absolutely no way for the site to fulfill its own purpose. So, to fill this need, Dribbble includes its own easy to use upload function.
Next, in order to achieve the feedback aspect of its overall purpose, Dribble also needs a way for users to actually offer their thoughts and critiques (or just compliments) on the various “shots” that are uploaded. Without this, the site would really be nothing more than another online gallery (a point that might be suggested anyhow?). This requirement is fulfilled through basic comment functionality. It may seem relatively mundane or simplistic, but it’s an absolutely essential element.
The other part of the driving purpose is the concept of networking and building relationships between different designers. The idea is to make the site a community, and in order to accomplish that, there needs to be some way for the designers that use the site to actually connect with each other. Taking a cue from Twitter and a number of other social networking sites, Dribbble allows is users to “follow” one another, thus building the necessary connections to really make the site work.
Of course, all the networking and following in the world isn’t going to do a bit of good without some form of related functionality that actually allows users to interact with those in their networks. So, the last piece of functionality that we want to look at is the listing of shots, which by default shows a grid of the most recently submitted work by designers that you follow. This brings meaning to the follow functionality, and allows you to see content specifically from those individuals with whom you have fostered a relationship (however casual that relationship may be).
We could probably go on to talk about some of the other functionality – like the different ways of browsing (popular, debuts etc), the invitation-only sign up and the activity streams, but I think by now you get the point. Every bit of functionality that exists on the site is included because of the way it supports the overall purpose, not simply because it is cool. Though Dribbble is, in its own way, a social networking site, it doesn’t try to emulate all the functionality of Facebook because it doesn’t need all the functionality of Facebook.
It doesn’t need fan pages, because they would not serve the site’s purpose. It doesn’t need direct messaging because it is intended to focus on the work, not provide another avenue for us to talk to each other (we have Facebook, Twitter and a myriad of others for that). It doesn’t need games, apps, events, relationship statuses or pokes (come to think of it, does Facebook even need pokes?). For Dribbble, all of those things would just be superfluous, functional fluff that does nothing to support the site’s overall purpose.
As I started to formulate my thoughts for writing this article, I happened to come across an interesting and relevant tweet from the ever inspiring Tina Roth Eisenberg (aka SwissMiss):
I agree with @marcoarment: If you start a webservice/product, make sure it solves a problem YOU have. #brooklynbeta @instapaper
From what I could gather, she was agreeing with a comment made by Marco Arment about the creation of the popular web service Instapaper. It was a timely tweet for me because it really encapsulates exactly what I am driving at here. If you are going to create a website or a web service, make sure that it is something that will actually help solve a problem that you yourself are faced with on a regular basis!
That kind of thinking is all about purpose.
By starting from a problem and looking for a solution, we ultimately direct our minds towards a singular purpose. We begin to consider functionality as a means of solving the problem in question, rather than as an array of independent plug-and-play features used to make a site cool.
The moment we begin to start sketching out and developing functionality by picking the coolest features from different sites all over the internet, we are in significant danger of leaving purpose behind and crossing over into the realm of bastardized pastiche. The site may capable of doing all sorts of really interesting things, but the functionality is almost certainly going to seem like a disjointed patchwork of features, with no binding unity in purpose or vision.
Dealing with Clients
Of course, I am reasonably confident that, as experienced designers and developers, most of us are already aware of the dangers of creating a site where the functionality is not bound together by singular purpose. The real challenge comes from clients who, as I described at the beginning of this article, will often come to us with a list of functionality rather than a defined purpose. This can leave a very large gap in the information we need in order to properly approach our work as designers.
Often, we can use the provided list of functionality to make solid, educated guesses as to the purpose of a given website, but those guesses will always be relative, based on our own perspective and understanding of what has been set before us. It is far better to have the purpose established by the client themselves–assuming of course that the client knows what the purpose of their site is.
Sometimes, a client’s obsession with a list of functionality can actually blind them to the purpose of their site, or even to the fact that they need a purpose at all. When this happens, I find that the best thing to do is to gently lead the client along through a series of probing questions. You might ask things like:
- how does this bit of functionality add value to the site?
- I see you would like your site to do this, which suggests that the overall purpose is to… Am I correct in assuming this?
- This bit of functionality suggests that this site will work in one way, while this other bit suggests it would work in another way. Could you help clarify which is more important?
Obviously, the exact questions that you will ask will depend a great deal on the specific context of an individual project, but hopefully these examples will provide some guidance for how to formulate questions that will penetrate through the surface of requested functionality and get to the real heart of the matter – which is to uncover and reveal the true purpose of a given website.
With that purpose in mind, we are then in a better position to turn back to the functionality and begin making informed, critical decisions about what needs to be included, what can stay and what should be either reevaluated or even completely discarded. We are then able to better serve our clients by creating sites founded on purpose driven functionality.