Wireframes first

Here’s a pattern I’ve observed. Many website design clients, especially those who have never been responsible for a website project before, expect to a process that goes roughly like this:

1) Talk about requirements

2) Do a complete graphic design

3) Fully implement the design in the site

4) Then move on to building out the functional elements of the site and the content.

Unfortunately, modern web development processes don’t usually work that way.

The process usually needs to go more like this:

1) Identify requirements

2) Do sitemaps and wireframe mockups to get the functional elements and information architecture right

3) Implement the technical bits

4) Do a design to make it pretty

Lots of missed expectations can easily ensue. Educating clients to the point where they can understand a wireframe can be a big — and costly — challenge.

12 thoughts on “Wireframes first”

  1. Sometimes if we can get their head around it we go one step further.
    1) Identify requirements
    2) Implement a “live wireframe” by mocking up IA in plone itself
    3) Migrate content into “live wireframe”
    4) Implement the technical bits
    5) Do a design to make it pretty (and then implement the theme).

  2. I’ve seen the response “That looks great, but isn’t the design kinda…. minimal?” to wireframes. πŸ™‚

  3. Nicely put. Don’t underestimate the effort required to keep wireframes or mockups up to date, though. Development normally starts on some parts of the site before the wireframes have outlived their usefulness. Sometimes, updating a wireframe version of the site can be a full-time job. At some point, you need to manage the transition from discussing wireframes to discussing the real site, which will have (different) rough edges still. Setting the expectation about when the “final” design will be evident (i.e. when brand people should get involved) can be difficult.

  4. my experience with most first time website design clients the process goes more like
    1) talk about requirements
    2) negotiate the price
    3) now when will it be done so I can make endless amounts of changes

    I feel that each project is more like an educational process.
    Recently I was given a “site map” for a project that was a bullet points of the pages of the website. Meanwhile when I created a wireframe there was an additional 20 something pages more than what was expected.

    I love how clients try and make the new project sound like its “simple” when its time for quoting but when the project is activated, it grows 3 fold.

    Its crucial that we protect ourselves through this creative process.

    Thanks and Regards

    Noel for Nopun.com
    a graphic design studio

  5. only one things i would add, then you problem lennart is solved.
    Mockup must look like a mockup. Like you draw it by hand. then client will know from the start this is a mockup not a design thing. but most of the time designer want to produce “nice” mockups. stop them. mockup should be “ugly” πŸ™‚

  6. @Dylan — we sometimes make “live” wireframes in an unstyled Plone site, and run into the same problems — many people can’t offer feedback on the “clickable prototype” because it “doesn’t look right.”

  7. In fact you can put visual design and wireframes design in parallel. At some point in time they will “meet” and the merge work will start.
    Funcionnalities, UX, branding, copywriting, … each one shall go along with each other, and they cannot be considere separate issues.
    If the project is complex enough you will then have to keep the wireframes updated and refactor them as you do with the code. Visual design, once the main elements are in place will follow.
    Note: if you do wireframes on paper the client will probably understand them better πŸ™‚

  8. Jon (and Dylan), you’ve nailed this process on the head. While there are variations, the important aspect is that websites are much more interactive and complicated than they used to be. People and companies are more Internet savvy and need to comprehend complex site maps and advanced interactions that will accomplish their site’s goals – this is why wireframes and prototypes are important.

    But you (and Lennart and Martin) also bring up a key point of client education. First, they need to understand that wireframes are just site skeletons to understand relationships and interactions. Then they must understand that it is may be an iterative process, but it’s not a never-ending process. There comes a point where you need to discuss sign off and transition to programming – as well as what fits in their budget.

    Thanks for sharing your experiences on this topic!

    Cheers,
    Andrea
    @ProtoShare

  9. Great thoughts, all! What I’m really realizing is that “modern” web projects — even apparently “simple” projects — have become far more demanding of the client than ever before. (To say nothing of the skills the consultant is asked to bring to bear.) It’s an interesting conundrum.

  10. Absolutely agree.

    I hoped the US market was more educated and trained to the user eXperience design and the information architecture than the Italian one but I wonder it’s not always the case.

    Actually to get properly to the step 2 a lot of analysis should be done first and that’s still much harder to get paid for πŸ™‚

  11. In 1979 Tom De Marco published a book called “Structured Analysis and System Design” on software engineering methodology.

    The fundemental premise then was “work out what it is you want to do, before you decide how to do it”.

    Seems to me this is just as true today, even for website deign, and is often lost sight of, especially where the implementation method is decided upon before the user requirements are understood/documented.

    Regards,

    Regards,

  12. He he, yes, that’s right Lennart, I’ve heard it more than once. Anyway, a kind of opposite situation happens as well. Some of our customer’s experiences tell us that if you start with a too “high fidelity” wireframe, it becomes harder to include their feedback properly. If you present your client something too polished they feel like most of the decisions have been already taken and they tend to resign to your proposals.
    The solution, as mentioned, goes through an accuracte expectation managements and also introducing gradually higher fidelity levels while iterating.

    Cheers,
    Dan
    @Justinmind

Comments are closed.