Peapod Architecture and Design Process

Posted on April 25, 2010 by Alistair Morton 
Filed Under Design, Interface, Marketing, Nerd Alert, Open Source, The Web, User Experience

When Peapod Studios begins creating a website, we’re not just simply collecting a few key pieces of information and moving directly into the build process.

There is a great deal of discovery and strategy that goes into creating the final products we deliver. We start with several sessions of discovery, where we set the basic goals and criteria we’d like the clients site to meet.

Then we develop several individualized personas of who the key users and stakeholders of the site will be. Personalizing a users experience dealing with a website is a key part of ensuring success. We develop several pathways throughout the site, for them to easily obtain the information they desire or have come for while navigating the site.

Architecture and Strategy Documentation

Architecture Document

We take all of this information and use it to develop our Architecture and Strategy document. This will serve as a resource for both our developers and the client to refer to as we move forward to the point where we can begin the preliminary site mapping and wire-framing of the eventual site build.

WireFrames

wireframe

Once we have established the web sites core functionality and layout only then can we move into creating the initial rounds of designs, a process we call skinning. Initially we like to provide the client with three distinct rounds of creative, allowing the client to have several choices in the future direction of the design.

Design Begins

first mocks

Taking the clients feedback from the intial three mockups we can begin to build out more honed designs based on their feedback. This is not a perfect science, sometimes a client will go through more than one round of creative, although sometimes we nail it from the get go.

Design Sign Off

Final Design

WIth all the elements in place, we finally have the basis for build.

The documentation we have from the preliminary steps allows the developers to work knowing the ins and outs of the final structure, and gives them an extensive library to refer to. Art direction is minimized as most of the design lives within the styles created in the skinning stage.

Asigra.com

Comments

3 Responses to “Peapod Architecture and Design Process”

  1. Gerry Kirk on April 25th, 2010 11:39 pm

    As a process junkie, I always enjoy reading and learning what works (and doesn’t) about the way a business works to deliver the highest possible value to clients.

    The process described here is a gated approach, one that seems most common in the web site design world.

    Given your vast experience in the web design world, what do you find is most challenging with delivering value using this process?

    I’ve worked with small teams to try a similar process to yours, but do so in an iterative fashion, so that the client (and hopefully some *real* users) can try out working software (prototype or real deal) and give feedback to direct the next round. In my experience people don’t fully understand what they need or what they’ve asked for, nor does the development team know if they’ve truly delivered the right thing in the right way until the design becomes “real”.

    The main challenge with this iterative approach is, well, figuring out how to chunk the work into smaller pieces.



  2. Alistair Morton on April 25th, 2010 11:51 pm

    We do soft launches to allow the client to do extensive testing ( and if affordable ) focus group testing to nail down lots of this functionality pre-launch. For the most part this process is quite simplified for this article.

    Depending on the clients needs, if we do have to develop several custom nodes, modules or applications that require initial input and feedback before design is done, we do that too.

    So in that respect we do some “chunking” work in our initial sprints. It really depends on the clients needs, and our timeline.



  3. Wit Peiser on June 23rd, 2010 8:23 pm

    I’ve worked with small teams to try a similar process to yours, but do so in an iterative fashion, so that the client (and hopefully some *real* users) can try out working software (prototype or real deal) and give feedback to direct the next round. In my experience people don’t fully understand what they need or what they’ve asked for, nor does the development team know if they’ve truly delivered the right thing in the right way until the design becomes “real”.
    +1



Leave a Reply