Form Follows Function, But How Far Behind?

I go into this blog-post blind, but I am conscious of two things: firstly that I have a question, but no conclusion; secondly, I’m haunted by an image of neatly aligned post-it notes, stuck on a whiteboard.

The Question

Does the designer need to be involved in a development project from conception to sign off, or should they be roped in once all development work is done?

That Image

This picture is taken from the presentation How We Make Websites by Matthew Wood and Michael Smethurst of the BBC, given at the Institutional Web Management Workshop 2009. I remembered the image as a page layout, and I imagined the different coloured notes to be some kind of attention mapping.

OK, I got it wrong as it turns out, the image is from the “Design your URI schema” slide. In my head it is linked with Matthew saying, and this could possibly be a misquotation “We don’t do any mock-ups in Photoshop” which is more likely to have come during the “Apply decor CSS” section.

What am I on about?

The workflow outlined in the presentation is dealing with masses of data, so I can understand why the web designer is being brought in late in the process.

We do however seem to have two concepts of design, and two stages of design: firstly design as a process of organising and structuring information; secondly design as a process of decoration. In essence, one is functional, the other is frivolous.

I agree that form should follow function; the site needs to work, but I think some degree of designed visualisation throughout the process can improve the final outcome.

Grids, Wire-framing, and Attention Mapping

Loads has be written about these so I don’t think I should write an overview, but I think they really help set the agenda for what you want an application to do. I think they can help a designer communicate ideas with a developer, and the developer can feedback whether or not something is workable…

Some Examples

I designed a homepage for E42, Edge Hill’s magazine and mocked it up in HTML and CSS. I figured it was a simple job for the developer, so I gave to him and said “Make it work!”. Presenting the stories in two columns turned out to be a nightmare, something to do with odd and even numbers of stories, and closing div tags. Anyway a bit of communication and a simple wireframe mock-up could have saved an afternoons work.

Conversely our main events page was created by the development team: it functions perfectly, but has no visual punch. If a monotone wireframe had been used, the focus could have been drawn quicker to the latest event; and if some attention mapping was done, you wouldn’t have to scroll down to find the button to the Events Timeline!

One Thing about Wire-framing

Wire-framing is great in certain contexts, getting the balance and composition of a static page right, early in the workflow, increases consideration for the end user throughout the process.

With applications like GO, where the end user can add and remove their own content, they are also creating their own page composition: In this context it is worth concentrating on the individual components.

By using Photoshop layers you can compare how the components sit next to one another, and see if you are achieving harmony or just making noise.

The Accidental

Experience has taught me the importance of planning up front: however nothing is conceived and visible in an instant. Just about every project hits a lull, where things look OK, but there is a lack of balance, or something just isn’t standing out the way it should do.

This is where a happy accident often occurs, usually by hiding layers in Photoshop the right juxtaposition of text, imagery and colour can miraculously happen, and everything falls into place.

This can’t be built in as part of your core plan, but by involving a designer throughout, little twists to the plot can happen, and you could end up with a more effective website.

To Conclude

Well the answer to the original question is no: let’s face it if something works it works; but people are becoming more conscious of the visual appearance of applications and how the intuitiveness of a layout gives them confidence as a user; also there is a psychological element that if something looks good it probably works better too.

Obviously there are other aesthetic questions: why do so many interfaces resemble a Mac operating system, or the dashboard of an Audi; but this is beside the point.

2 thoughts on “Form Follows Function, But How Far Behind?

  1. Hi Sam

    First off I’d better point out I came to this post via Mike Nolan’s twitter feed – not a vanity search (honest). Also there’s quite a lot in your post so apologies in advance for the over long comment…

    I guess the first thing to talk about is full stack application ‘design’. The best analogy I’ve come across is in Cal Henderson’s Building Scalable Web Sites book where he compares a web app to a trifle.

    Where a trifle has a spongey bit, a web app has a database. Where a trifle has a fruity / jelly bit, a web app has models / business logic. Where a trifle has custard, a web app has controllers (the urls that are surfaced and how the user can interact). Where a trifle has cream, a web app has views (html, rss, json, xml etc). And where a trifle has sprinkles, a web app has css.

    The point is that whilst it’s relatively easy to change the sprinkles / css, a little bit harder to change the cream / views the further down the stack you go the harder / more expensive it is to make changes. Changing any layer impacts on all the layers above and in general the people who can make changes to the layers get rarer / more expensive the further down you bury.

    The other argument is the obvious one. I’ve worked on projects in the past that have been entirely driven by photoshop comps. 18 months in with the markup all fine and the css working in god knows how many browsers we’ve found that the server side tech wasn’t capable of powering what had been designed. Which is painful…

    The obvious downside of designing from the database up (rather than the ‘ux’ down) is the usual argument – I don’t want a website that’s been designed by software engineers any more than I want a car designed by chassis engineers…

    …which is where domain driven design comes in. The whole point is to design from the bottom up but involve users every step of the way. Even before you start to design the database talk to users about the domain, make notes on the words they use and use those words all the way up the stack. If you’re making an application about beer and users use the word pint then have a pints table, a pint model and a pint controller, use ../pints as a url, class=”pints” in your markup and .pints in your css. Ubiquitous language up the stack that every team member knows and uses makes life much easier. User experience starts with the things you model and the words you use to describe them.

    The second point about DDD is that given one well designed, user centric, domain driven database you can make many products just by adding new model / business logic / fruity-jelly on top. In the BBC’s case that’s one domain model / database to describe programmes on top of which you can add different model code to make /programmes and iPlayer. Add in a little more data and you get /music and Wildlife Finder. So one domain model, one core database and 4, 5, 6… ‘products’.

    Looking back at the ‘How we make websites’ post it seems a little more linear process-y than it really is. It’s not supposed to be ‘do step 1, now do step 2’ etc. In reality every opportunity is taken with every step to test with users. If something’s wrong go as far back as you need to correct stuff. If you can’t afford formal user testing grab someone on the street or ship less features and spend the money on user testing. If you’re working in a corporate environment get one ‘business unit’ to user test the ‘site’ of another ‘business unit’.

    Which obviously brings up the subject of user centered design. At least IMO the standard UCD process is as far removed from user centric design as it’s possible to get without the company chair’s husband / wife specifying the font size in pixels. The process mess of personas and moodboards and sitemaps and wireframes keeps development uncomfortably remote from real users. Spending months ticking UCD boxes won’t help you to make a usable app. The sooner you can show real code to real people the sooner you can get proper feedback and act on it.

    So onto your original point 🙂 “I can understand why the web designer is being brought in late in the process”. He / she isn’t. In the case of /programmes the remarkable Jamie Tetlow has been on the project since the start. In the case of /music the remarkable Sacha Sedriks has been on the project since the start. Which means they’ve sat through and contributed to endless domain model conversations, endless database conversations and endless, endless, endless conversations about urls/uris.

    All the team work together with a single domain model, a single language and a joint understanding of what is / isn’t possible and is / isn’t desirable. And this isn’t always technical stuff – way back in the chain the data has to come from somewhere and where it comes from is governed by legal / licensing agreements. Every member of the team knows at least some of the details of these agreements cos they have to to determine what’s currently possible / what would need to change to make something possible.

    Also roles get blurry because the “software engineers” know about markup and css and the “designer” knows about uris and the database schema and the “client side developer” knows about markup and css and database and etc. And sometimes even the project manager knows something. This blog post talks about some of the people involved and the “process” followed:
    I guess the key term is T-shaped people!

    Anyway, the key point is the “designer” was involved all the way through so grokked the domain model and knew what was and wasn’t possible (and more importantly what would need to happen for something that wasn’t possible to become possible). The designers role (like the software engineers role and the information architect’s role and even on occasion the project manager’s role) was much more about abstract problem solving than “make mock-ups”. To prove the point these are 2 of Jamie’s posts on “designing” /programmes:

    The second point is wireframes! I tend to fear wireframes because they conflate 3 things: the data you need to trawl up to build the page (via annotations), the layout of the page and by implication the markup of the page.

    The first one is important because it’s not just about the page. Or not just about the desktop web page. If you take the one web / linked data / content negotiation approach there are multiple pages (desktop web, full fat mobile web, stripped down mobile web, all in multiple languages) at the same uri. In addition there are multiple data views (ical, json, yaml, rdf xml….). Wireframes ignore all of this. IMO it’s better to identify the thing(s) the uri is talking about and spec out what data is needed to describe each of these things. An obvious example is created_at / updated_at datetimes. You might not want to show these in your desktop web page but you’ll need them for rss / atom etc.

    Speccing the page layout in wireframes has similar limitations. Which page are you talking about? Or rather which device are you talking about? Do you make separate wireframes for desktop web and iphone and n6x? Separate wireframes to describe what happens with the print css? Often many pages use a single “partial” to render a common piece of markup. If you make a change to that partial you end up having to edit hundreds of wireframes to keep them in sync. Pretty soon you spend all your time servicing the documentation and no time servicing the code… At least in my experience.

    The third problem is the implied markup that wireframes suggest. Hand over a worked up wireframe to many web developers and they’ll start at the top and code down. Which means you end up with acres of global navigation at the top of every document. Which screen readers (and google) have to fight their way through before they get to the content. I strongly believe that good document design is a neglected skill – and document design should precede css for accessibility and seo reasons…

    Finally [honest :-)] on photoshop. If you work with an old style print designer they get the separation of content and design cos they worked with old style print specs. Since the 1980s and apple macs and photoshop and desktop publishing designers seem to have acquired a ‘what you see is what you get’ approach. They’ve got used to having complete control over visual design…

    …but the web isn’t WYSIWYG. What if the user has a visual impairment and needs to reverse colours? Or up the font size? Or use a screen reader? What if they switch css or javascript off? What if they choose to not install flash? Even ignoring the variations in rendering you get across multiple browsers with varied levels of support for css. Does the photoshop comp have rounded corners? If so do they need to appear rounded in all browsers? The whole point of the web is user control – not just of journeys but also of display. Photoshop panders to the need to control the “user experience”. But on the web user experience is up to the consumer, not the publisher. Or maybe just WYSIWYG is design as ego and the web isn’t?!? Either way the web has a design language and that language is css – not flat mockups. And any designer who doesn’t work with (and ideally in) markup and css is not, IMO, a web designer….

    I think people work in lots of different ways and everybody needs to play with ideas and sketch. Some people do that with code, some with whiteboards, some with omnigraffle, some with fag packets and some in photoshop. As a place to play with ideas photoshop is fine. But as a place to define / design a website it’s just the wrong tool for the job….

    Anyway, all just opinion and sorry for taking up so much comment space 🙂

    have a very good christmas


  2. Hi Mike

    Many thanks for your fascinating and insightful comment – I was really hoping the original post would get a response. As it was a bit naïve, I was worried I might get eaten alive – so thanks for the patient tone

    I’ll respond from the bottom up, and talk about Photoshop first – I’ve read about agencies where print designers hand over mock-ups to developers, but I’ve never actually met anyone who works that way; I’d say most people approach Photoshop with their CSS and HTML heads on as well. I agree totally that it isn’t the place to finalise things, especially since there is a cut off point to most designer’s knowledge, a grey area called the “backend”.

    I found your comments about wireframes very interesting – as I hinted in the “one thing about wireframes” bit of my post, the possibilities of the way pages are presented is increasing – for us it is still fairly predictable, but we will be making a mobile version of the site next year (Whether this will be full fat or semi-skimmed I don’t know). It will be a massive and very welcome learning curve for me as a designer; luckily I’ll be working with developers that know what they’re doing.

    One area we need to address before we start, is how we fit user testing into the cycle. Although we obviously consider the end user, I don’t think the way we work could be considered “User centred” – I liked your phrase “process mess” – when it comes to moodboards, I don’t know if I’ve done one that hasn’t been met with total indifference – very much a print design concept. Anyway back to the original point – we need to organise user testing with staff and students as part of the SCRUM process.

    As projects become more complex, I expect some of our more eccentric working practices will be reigned in and rationalised, but as a designer I hope to be involved all the way through.


Comments are closed.