Design Artefacts Part 1: Introduction | February 21, 2008

I’ve decided to start a quick series of posts on design artefacts. Basically all the documents, diagrams, designs and other outputs you create during the design process. These artefacts include the following items, although I’m sure you can think of more. As the series progresses I’ll link all the items up for ease of navigation.

These artefacts are often called ‘deliverables’ as they tend to get sent to clients for formal sign-off. Sadly I think we’ve got so fixated with the project management value of these ‘deliverables’ we’ve started to overlook their real value.

During this series I’m going to argue that the benefit of these documents is formative rather than summative. That, rather than being a milestone for checking the validity and progress of your designs, they are actually critical to the formation of the design itself.

If this is the case, which I believe it is, I’m also going to suggest that we stop treating them as traditional ‘deliverables’ and handing them over to clients for approval. Instead I’m going to suggest that we work with our clients in a more collaborative and iterative manner, using a process of passive approval instead.

Posted at February 21, 2008 3:54 PM

Comments

Colin said on February 21, 2008 4:45 PM

I work at a place that budgets about 16 hours to design (for real) per project, so I usually only hit about 3 of these artifacts, of which maybe 2 are “deliverables” on most occasions.

Looking forward to the rest of your “series.”

Rob Goodlatte said on February 21, 2008 4:46 PM

I completely agree. You can’t have good design without effective problem-solving — all those “process” artifacts are essential if the end product is good design.

Could this post be a hint to the function of Silverback? Hmmm..

Keith said on February 21, 2008 4:51 PM

Hey Andy, can’t wait to see what you’ve got to say. This is a topic I’ve spent my whole career thinking about in some form or another. As have many designers I’m guessing.

I’m actually doing a talk in March about this kind of thing: http://www.uie.com/events/web_app_summit/2008/day3/#robinson

Two of my main points are:

I’m really interested in what you’re thinking about this stuff!

Ian said on February 21, 2008 4:58 PM

Absolutely. Helpful steps in the design process often become a burden when placed onto the project timeline as deliverables.

As a freelance following a less formal process I find I always complete several of the above steps to some degree as I feel they are necessary to complete the project itself even though they are not stated as deliverables and don’t need to be signed off. They provide a useful structure and process to any project.

And as Hicks mentioned earlier, I’d also be keen to learn more about your “Rabid Design Iterations”. Is the Gorilla involved? ;)

Jay Jones said on February 21, 2008 5:00 PM

Andy,

I agree with your premise that these “deliverables” are, in actuality, integral parts of the process and “formative” rather than simply client-driven approval checkpoints.

I think, though, that these items can serve both purposes… the formative process to the design and development cycle, as well as milestone-based expectations for clients.

In the enterprise-level world of website development, milestones are qualitative pieces to which both expectations and monetary payouts can be linked. Especially with projects dealing with hundreds of thousands of dollars, this level of checks and balances is (in my mind) integral to the success of a project.

This is not to say that each of these “deliverables” cannot be broken down into iterative milestones and spread out over a project’s life-cycle, though. In fact, this is the way the company I work for handles it, to allow for the collaborative process with our clients to be more fluid.

Larger clients and larger projects will demand the qualitative cycle of milestones and “deliverables” to ensure that their project will come in on-time and on-budget.

So, while I agree with you about the importance of these Artifacts, I’m interested in hearing how you would describe a successful project that treats them as fluid pieces rather than time-sensitive deliverables?

At any rate, this is going to make for a great series. Thanks for setting out to write it.

Jay

Scott said on February 21, 2008 5:14 PM

Hi Andy
I couldn’t agree more and I’m looking forward to hearing what you’ll have to say about this in the future. Apologies for the plug, but the iterative and collaborative process between designer and client is exactly what I’ve been trying to accomplish with WriteMaps . So far it has proven to be very efficient in site planning and structure throughout a design/development process.
The site map becomes less of a deliverable and more of a reference tool that can adapt to changes as they happen.

James Box said on February 21, 2008 5:24 PM

Here here. I guess you already know that I agree with this.

Surely the first step is to shed the term ‘deliverable’. I’m definitely guilty of using it without considering the message it sends to the client.

Andy Budd said on February 21, 2008 5:29 PM

btw, this is absolutely not a clue to what Silverback does.

Christian Watson said on February 21, 2008 6:17 PM

Depending on the context of use for the application or web site, field studies can be a useful tool.

For example, if you are designing something to be used on a mobile device your should look at where it is likely to be used, or if you are building a site about recipes, perhaps it should be designed to be used on that spare laptop the user has in the kitchen.

Howie said on February 21, 2008 8:35 PM

Rabid Design Iterations?
Sounds like viral marketing!

Looking forward to hearing about passive approval. Collaboration - yes, iteration - yes. Passive approval? Nice idea. Well, I develop web application, and it never works like that. Signing off of milestones, more than producing deliverables.

Andy Budd said on February 22, 2008 9:30 AM

Oops, should obviously have been rapid :-)

Darren G said on February 25, 2008 8:39 PM

Interesting Andy, very interesting. I’m keen to read more.

Although ultimately, I would expect success of this approach would depend on how comfortable / accommodating your client is with “passively approving” somehing as potentially important to their business as their website design?

Would this afford the client the knowledge and security that decisions on key factors are recorded accurately and responsibility for doing so can be accorded at a later date?

And would this approach allow clients to formulate measurable objectives in order to gauge progress?

Carry on Andy, let’s see the rest! I’m dying to put your theories to the test….

Bernardo Doré said on February 29, 2008 6:54 PM

Great topic! I suppose you will explain what a “process of passive aproval” is in the upcoming articles. I’m very curious. Keep going!

Justin Carmony said on March 7, 2008 7:11 PM

I totally agree and I look forward to reading more. :)

Milwaukee, WI said on March 13, 2008 6:04 PM

You forgot “Empty mountain dew cans”.

Gregg Turnbull said on March 14, 2008 4:14 AM

Hello Andy,
I really like the flow of your artifacts and especially the key point that they don’t exist in a vacuum, but instead feed the ongoing process. I suppose it is like any assembly line item, such as a car. You wouldn’t hand the customer the bits and pieces of as the were assembled at each station, but rather build upon it until the product is completed (sum of it’s parts). btw, if you wouldn’t have set the record I would have totally thought that this is exactly what Silverback did. Just will remain on pins and needles with the rest.
Cheers.

Lee said on March 28, 2008 4:51 PM

Hi Andy,

I don’t think the two are mutually exclusive. If you use a UCD process within a project then these documents should become “deliverables” through an iterative process of review and change with the client. They’re mostly the outcomes of particular methods, rather than documents you just produce out of thin air.

Unfortunately I think that’s what a lot of people / companies are doing nowadays - “I do UCD / usability because I sat down for 10 minutes and made up a “persona”.

Looking forward to the series anyway!