Hi Andrei,
What you expressed is very important(to me), that is what's the
deliverable for, but peter seems already expresses similiar thinking
in his article
Of course, compiling a list is only the first step. For each project,
we must strive for the optimal mix. Since our deliverables resist a
Good Work on the Icons and Images! I think they do a great job in
graphically representing the deliverables in a simple yet effective
manner.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=37799
...@lists.interactiondesigners.com] On Behalf Of Yohan
Creemers
Sent: Thursday, January 29, 2009 6:32 AM
To: disc...@ixda.org
Subject: Re: [IxDA Discuss] User Experience Deliverables
Here is a more exhaustive overview of methods and deliverables which can be
used throughout a design process:
http://project.cmd.hro.nl/cmi
I guess it's a matter of definitions. If by 'sketch' you mean something
(anything) that is drawn on paper using a pencil, then of course, it can be
a deliverable. If it communicates a solution, like you say here, yes, it's a
deliverable.
If by 'sketch' you refer more to the activity of sketching
Ok, so by 'deliverable' you mean anything that can be shown to the client,
at any point. I guess I was thinking more in terms of something that
describes a part of the final solution (or some solution).
Sebi
On Thu, Jan 29, 2009 at 3:12 AM, Andrei Herasimchuk
aherasimc...@involutionstudios.com
On Jan 29, 2009, at 1:10 PM, Sebi Tauciuc wrote:
Ok, so by 'deliverable' you mean anything that can be shown to the
client,
at any point.
Not just the client. It could be something that is only shown to the
developers, like a detailed specification of layout, type, color,
etc., or a
Thanks for posting. Debating how we should manifest our work in a
deliverable is a favorite past time of my team. To 'get over ourselves', so
to speak, we're going to drink our own kool aid and are proposing to do some
contextual inquiry with the people who use our documents. We want to see how
First off, I think it's great, and thanks for doing this.
On the feedback side, I agree with Andrei on the pixel-perfect mockups
needing to be in there.
As a compliment to this I would like to see how these deliverables
interact with the deliverables of other departments. I think our
Hi Michaeal,
Yup, fully agree.
Design team (process) is a blackbox, for other part of whole product
team. There's input to it and output (deliverbals) from it. The
stakeholders may not (most of the time) care what's in the team or
process ( some none-final skeches, or similiar stuff), they care
Jeffery Callender and I collaborated on this article...
http://semanticstudios.com/publications/semantics/000228.php
...and on a collection of icons and images...
http://flickr.com/photos/morville/sets/72157612907604234/
...and we'd love feedback and suggestions. Thanks!
Peter Morville
I think this is a very potent introduction and reminder of what user
experience people do.
I think it's also useful as a rough sketch and not as a formal
framework, since there's usually not a one-size fits all approach.
It's on my list of important bookmarks.
Good job!
On Jan 28, 2009, at 6:24 AM, Peter Morville wrote:
Jeffery Callender and I collaborated on this article...
http://semanticstudios.com/publications/semantics/000228.php
...and on a collection of icons and images...
http://flickr.com/photos/morville/sets/72157612907604234/
...and we'd love
On Thu, Jan 29, 2009 at 12:35 AM, Andrei Herasimchuk
aherasimc...@involutionstudios.com wrote:
On Jan 28, 2009, at 6:24 AM, Peter Morville wrote:
Jeffery Callender and I collaborated on this article...
http://semanticstudios.com/publications/semantics/000228.php
...and on a collection of
http://semanticstudios.com/publications/semantics/000228.php
For clarification's sake, are you simply presenting these as deliverables
you've seen, or are you advocating their use?
-r-
Welcome to the Interaction Design
Thanks for the positive feedback, the constructive criticism, and the
questions. The map is intended as a tool to help folks (myself included)
think about the mix of deliverables they might use in any given project.
It's not intended to be comprehensive (or prescriptive) but rather to
reflect the
I see the pixel-perfect design comps as serving one of two purposes:
i) As a conceptual exploration of the visual design. That is, a stage of
visual design iteration; and
ii) As a final pre-production stage in the overall process.
So in one sense I'd happily include these into the broader
On Jan 28, 2009, at 7:08 PM, Sebi Tauciuc wrote:
Depends on what you mean by deliverable. I would see pen, paper
sketching as tools, not deliverables. Of course, you can still show
sketches to people, but just to ask questions and promote
discussion, not as a final result.
Guiding
On Jan 28, 2009, at 4:08 PM, Sebi Tauciuc wrote:
Depends on what you mean by deliverable. I would see pen, paper
sketching
as tools, not deliverables. Of course, you can still show sketches to
people, but just to ask questions and promote discussion, not as a
final
result.
As a design
On Jan 28, 2009, at 4:40 PM, Peter Morville wrote:
I lumped pixel-perfect mockups or design comps under the broader
category of
concept designs, but I recognize that's a (big) stretch. That leads
me to a
question: what is a good broader category that could include design
comps
AND their
On Wed, Jan 28, 2009 at 4:40 PM, Peter Morville
morvi...@semanticstudios.com wrote:
what is a good broader category that could include design comps
AND their equivalents in domains beyond web/print design (e.g., physical
buildings and spaces and products)?
prototypes?
-x-
--
Christian
All design professions -- from fashion to industrial to architecture to
graphic -- have some functional equivalent of a blueprint.
Yes, this is fotal important, especially for demo design ideas to
stakeholders as well as communicate with the engineering team. it
sketches the affordable
On Jan 28, 2009, at 8:14 PM, Andrew Boyd wrote:
I'm not sure where you pulled these absolutes from, and I'm not sure
that I care - as someone who has used pixel-perfect mockups in
conceptual design on multiple occasions to good effect I can say
that you are not making a lot of sense to me
I've been creating complete implementable specs (along with
implementable resources) for software of many types since the 1980s.
Many projects exist at increasingly higher and higher fidelity
thumbnails until complete pixel-perfect (or whatever format the
deliverable will be in) specs are
To clarify my own post:
On Jan 28, 2009, at 6:32 PM, Andrei Herasimchuk wrote:
It's not a big stretch. It's apples and oranges. Concept design and
pixel-perfect screen mockups simply cannot be clumped together.
Add to the end: ...cannot be clumped together to be used for the exact
same
24 matches
Mail list logo
