"Name" for product design document / deliverable

29 Sep 2005 - 1:15pm
9 years ago
11 replies
1231 reads
russwilson
2005

My team will be delivering a spec that includes the following sections:
-----------------------------------------------
Functional Description
Concept Map
Use Cases
Mockup / Prototype Screenshots
Taskflow
Interface Elements
Buttons
Icons
Color
Constraints
Performance
Consistency
Usability Best Practices
Standards Conformance
------------------------------------------------
The general idea being that marketing delivers an MRD to design;
design deliver "the above" to architecture/development, etc.

So, what should "the above" be called?

I've had the following suggestions:
1. Product Design Specification (or Description)
2. GUI Specification
3. FRS (Functional Requirements Specification)
4. PRD (Product Requirements Document)

Any suggestions for a standard name for a design doc that fits
between marketing and development? (disregard the *exact* labels
above as they may change slightly)

Thanks,
Russ

Comments

29 Sep 2005 - 1:28pm
Dave Malouf
2005

On 9/29/05 2:15 PM, "Wilson, Russell" <Russell.Wilson at netqos.com> wrote:

> I've had the following suggestions:
> 1. Product Design Specification (or Description)
> 2. GUI Specification
> 3. FRS (Functional Requirements Specification)
> 4. PRD (Product Requirements Document)

I'd go with Product Design Document
That's quite a comprehensive deck you hand in there. Good for you!

With that much in there, I would call it the product design bible, but
that's me. ;) Or the Product Testament. :)

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

29 Sep 2005 - 1:37pm
russwilson
2005

:-)
Thanks Dave.

Actually, several people have already referred to
it as "the bible". And that is actually what we're
after: to create a spec that can be used by QA, docs,
support, training, and development (in addition to
other complementary documents/specs as well of course).

On a side note, the hardest part is not creating the
document, it's keeping it current. But that's another
subject altogether.

Russ

Russell Wilson
Director of Product Design NetQoS, Inc.
6504 Bridgepoint Parkway, Suite 501
Austin, TX 78730
russell.wilson at netqos.com
tel: 512-334-3725

-----Original Message-----
From: David Heller [mailto:dave at ixdg.org]
Sent: Thursday, September 29, 2005 1:28 PM
To: Wilson, Russell; discuss at ixdg.org
Subject: Re: [ID Discuss] "Name" for product design document /
deliverable

On 9/29/05 2:15 PM, "Wilson, Russell" <Russell.Wilson at netqos.com> wrote:

> I've had the following suggestions:
> 1. Product Design Specification (or Description) 2. GUI
> Specification 3. FRS (Functional Requirements Specification) 4. PRD
> (Product Requirements Document)

I'd go with Product Design Document
That's quite a comprehensive deck you hand in there. Good for you!

With that much in there, I would call it the product design bible, but
that's me. ;) Or the Product Testament. :)

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

29 Sep 2005 - 2:22pm
Andrew Otwell
2004

> On a side note, the hardest part is not creating the
> document, it's keeping it current. But that's another
> subject altogether.

Actually, I'm totally indifferent to the naming issue, but this question
of currency is a huge challenge. As a consultant in the past, I've used
huge comprehensive docs like this, with sign-offs at every turn, as
cover-my-ass work: when I'm only around for a couple of months on a much
longer project, it was critical to hand in something in a Known Good
State at the end, signed, sealed, and delivered.

The last couple of years, I've been an in-house interaction designer
working closely with a development group. Those huge docs became useless
after our first release, precisely because they were impossible to
keep current. It's ridiculous to expect your audience to pour over
documentation reading closely for minor changes, and the bulk of the
thing gets out of date rapidly anyway.

Over time, and as the developers and I have gotten to know each other,
it's been more effective to maintain a set of constantly-changing
HTML-based specs, one web page per screen wireframe (or component or
widget). I write as little text as posssible on these pages, since no
one reads them after the first time, and try to keep the wireframes up
to date.

There are a couple of things that help: first, since this spec site's
all checked into CVS, developers get email (or RSS) notifications of
which pages change, and how, minutes after I make them. Second, I
actively *remove print copies of wireframes from developers' desks* when
I find them, and always bring up the spec site web page when we have
discussions. That keeps me and them honest.

29 Sep 2005 - 2:28pm
Marci Ikeler
2003

I'd like to share how I've handled design specifications in the past;
the purpose is just to share my experiences, as I don't believe that
there is an absolutely "right" way to do this. As with most design
tasks, the correct format of specifications will vary according to your
company structure, client, and product.

My team (design/ business analysis/ data analysis) typically releases
three specifications to the development team:
1) Functional Specification - Includes concept maps, wireframes with all
user-interface elements described, business logic, and functional
behavior.
2) Data Specification - Includes specific values and parameters for
objects/attributes detailed in the functional specification. For
example, the funcitonal spec might state that two parameters affect the
display of a third; the actual resulting values for each condition are
included in the data spec. The purpose of this document is not to
provide an actual "database" table, but to list all business conditions
and potential values. I don't think this type of specification is
necessary for all projects, but in those that are heavy on data
parameters and business logic, it can be helpful to maintain this
separately from the functional spec.
3) Visual Design Specification - This includes fully formatted visual
designs of each screen with detailed specifications regarding font size,
color, etc. Visual resources (icons, images, etc.) are included.

I've found it helpful to keep these three types of specifications
separate because they tend to change at different rates and at different
phases of the project. The mechanical process of managing and releasing
a specifications (because specifications are only as valuable as they
are up-to-date) can be quite difficult when these different types of
information are contained in one place. Additionally, splitting these
types of information from one another is helpful in terms of scheduling:
in my team at least, we usually try to have the functional
specifications done first, followed by the data specs, then the visual
design specs. That way the development team can first start on the
essential tasks of building the application's funcitonality and screens
before seeing details about the database content and font sizes.

On another, even more mechanical note, different tools are valuable for
creating each of these specs -- Visio for the Functional Spec, Excel for
the Data Spec, and Photoshop for the Visual Design Spec. Keeping this
information all in one place can be tricky (although tool restricitons
alone obviously aren't enough to argue for this approach).

I hope this feedback is helpful. It is always interesting to hear how
different design teams approach the same problems. Thanks,

Marci

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Wilson, Russell
Sent: Thursday, September 29, 2005 2:15 PM
To: discuss at ixdg.org
Subject: [ID Discuss] "Name" for product design document / deliverable

[Please voluntarily trim replies to include only relevant quoted
material.]

My team will be delivering a spec that includes the following sections:
-----------------------------------------------
Functional Description
Concept Map
Use Cases
Mockup / Prototype Screenshots
Taskflow
Interface Elements
Buttons
Icons
Color
Constraints
Performance
Consistency
Usability Best Practices
Standards Conformance
------------------------------------------------
The general idea being that marketing delivers an MRD to design; design
deliver "the above" to architecture/development, etc.

So, what should "the above" be called?

I've had the following suggestions:
1. Product Design Specification (or Description)
2. GUI Specification
3. FRS (Functional Requirements Specification)
4. PRD (Product Requirements Document)

Any suggestions for a standard name for a design doc that fits between
marketing and development? (disregard the *exact* labels above as they
may change slightly)

Thanks,
Russ

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/ Announcements List
......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

29 Sep 2005 - 2:29pm
Dave Malouf
2005

Andrew, I lean in your direction as well, but I find that well maybe
developers can work this way, Quality Assurance folks can't. They do read
every letter and look at every pixel I give them and when I miss something,
they tell me so and in an embarrassing type way. W/o the type of details
that were invoked in this sort of Testament to product we would be lost.

Now to be honest, we don't do everything and definitely don't deliver
everything.

Things like task analysis are for my purposes only and don't really hold a
lot of value to the developer, business, or QC folks.

What we do do is have a single per function (we are always in update mode)
UI Specification that is based on screen shots and zoomed elments w/ lots of
annotations. These are used by Dev pretty well. Then the technical writer
comes in and edits the living functional specification (we incorrectly call
these use cases) based on these UI Specs.

QC uses a combination of the UI Spec and use cases to create their test
scripts. Oh! And detailed level changes that happen during the dev cycle are
not put into the UI spec. That document "dies" at kickoff to development,
and we document "changes" in our defect management system. At the end of
development during the first stages of QA the tech writer combs over
everything and integrates them into his use cases.

A tad convoluted but in some weird way it works.

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

29 Sep 2005 - 2:43pm
Todd Warfel
2003

Which is exactly why we've started including a version history and
document index at the front of our decks.

I'll be talking about this at the IA Retreat (Methods for Improving
Your IA Deliverables)

On Sep 29, 2005, at 3:22 PM, Andrew Otwell wrote:

> It's ridiculous to expect your audience to pour over documentation
> reading closely for minor changes, and the bulk of the thing gets
> out of date rapidly anyway.

Cheers!

Todd R. Warfel
Design & Usability Specialist
--------------------------------------
Contact Info
Email: twarfel at mac.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------

29 Sep 2005 - 2:42pm
Todd Warfel
2003

So, why not call it "The Design Bible"?

On Sep 29, 2005, at 2:37 PM, Wilson, Russell wrote:

> Actually, several people have already referred to
> it as "the bible".

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com

--------------------------------------
Problems are just opportunities for success.

29 Sep 2005 - 3:09pm
russwilson
2005

Andrew, I lean in your direction as well, but I find that well maybe
developers can work this way, Quality Assurance folks can't. They do
read every letter and look at every pixel I give them and when I miss
something, they tell me so and in an embarrassing type way. W/o the type
of details that were invoked in this sort of Testament to product we
would be lost.
--------------------------------
This is right in line with our experience as well. We have much
more flexibility working with developers than with the other
stakeholders
(QA, docs, support, training)

29 Sep 2005 - 2:08pm
Gwen Marsh
2005

Since you mentioned it, how do you keep the bible current -- both during
development and after launch?

I've been musing about using a wiki to do. Has anyone tried this?

Gwen Marsh
Bridges Transitions Inc.
www.bridges.com

[Please voluntarily trim replies to include only relevant quoted
material.]

On a side note, the hardest part is not creating the
document, it's keeping it current. But that's another
subject altogether.

Russ

Russell Wilson
Director of Product Design NetQoS, Inc.
6504 Bridgepoint Parkway, Suite 501
Austin, TX 78730
russell.wilson at netqos.com
tel: 512-334-3725

-----Original Message-----
From: David Heller [mailto:dave at ixdg.org]
Sent: Thursday, September 29, 2005 1:28 PM
To: Wilson, Russell; discuss at ixdg.org
Subject: Re: [ID Discuss] "Name" for product design document /
deliverable

On 9/29/05 2:15 PM, "Wilson, Russell" <Russell.Wilson at netqos.com> wrote:

> I've had the following suggestions:
> 1. Product Design Specification (or Description) 2. GUI
> Specification 3. FRS (Functional Requirements Specification) 4. PRD
> (Product Requirements Document)

I'd go with Product Design Document
That's quite a comprehensive deck you hand in there. Good for you!

With that much in there, I would call it the product design bible, but
that's me. ;) Or the Product Testament. :)

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

30 Sep 2005 - 1:16pm
russwilson
2005

Unfortunately, we use a very unsophisticated approach at
the moment -- basically, we have weekly reviews of development
progress. The developers post new builds to an internal site
allowing us to test them out. Any changes are discussed and
added to the design doc.

The specific problem we encounter is that sometimes a developer
will make a subtle change that escapes out attention.

We also have another problem where QA (and other teams) suggest
"changes" that the developers respond to without first clearing
the change with design.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Gwen Marsh
Sent: Thursday, September 29, 2005 2:09 PM
To: discuss at ixdg.org
Subject: RE: [ID Discuss] "Name" for product design document /
deliverable

[Please voluntarily trim replies to include only relevant quoted
material.]

Since you mentioned it, how do you keep the bible current -- both during
development and after launch?

I've been musing about using a wiki to do. Has anyone tried this?

Gwen Marsh
Bridges Transitions Inc.
www.bridges.com

[Please voluntarily trim replies to include only relevant quoted
material.]

On a side note, the hardest part is not creating the document, it's
keeping it current. But that's another subject altogether.

Russ

Russell Wilson
Director of Product Design NetQoS, Inc.
6504 Bridgepoint Parkway, Suite 501
Austin, TX 78730
russell.wilson at netqos.com
tel: 512-334-3725

-----Original Message-----
From: David Heller [mailto:dave at ixdg.org]
Sent: Thursday, September 29, 2005 1:28 PM
To: Wilson, Russell; discuss at ixdg.org
Subject: Re: [ID Discuss] "Name" for product design document /
deliverable

On 9/29/05 2:15 PM, "Wilson, Russell" <Russell.Wilson at netqos.com> wrote:

> I've had the following suggestions:
> 1. Product Design Specification (or Description) 2. GUI
> Specification 3. FRS (Functional Requirements Specification) 4. PRD
> (Product Requirements Document)

I'd go with Product Design Document
That's quite a comprehensive deck you hand in there. Good for you!

With that much in there, I would call it the product design bible, but
that's me. ;) Or the Product Testament. :)

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/
_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

30 Sep 2005 - 1:23pm
russwilson
2005

Unfortunately, we use a very unsophisticated approach at
the moment -- basically, we have weekly reviews of development
progress. The developers post new builds to an internal site
allowing us to test them out. Any changes are discussed and
added to the design doc.

The specific problem we encounter is that sometimes a developer
will make a subtle change that escapes out attention.

We also have another problem where QA (and other teams) suggest
"changes" that the developers respond to without first clearing
the change with design.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Gwen Marsh
Sent: Thursday, September 29, 2005 2:09 PM
To: discuss at ixdg.org
Subject: RE: [ID Discuss] "Name" for product design document /
deliverable

[Please voluntarily trim replies to include only relevant quoted
material.]

Since you mentioned it, how do you keep the bible current -- both during
development and after launch?

I've been musing about using a wiki to do. Has anyone tried this?

Gwen Marsh
Bridges Transitions Inc.
www.bridges.com

[Please voluntarily trim replies to include only relevant quoted
material.]

On a side note, the hardest part is not creating the document, it's
keeping it current. But that's another subject altogether.

Russ

Russell Wilson
Director of Product Design NetQoS, Inc.
6504 Bridgepoint Parkway, Suite 501
Austin, TX 78730
russell.wilson at netqos.com
tel: 512-334-3725

-----Original Message-----
From: David Heller [mailto:dave at ixdg.org]
Sent: Thursday, September 29, 2005 1:28 PM
To: Wilson, Russell; discuss at ixdg.org
Subject: Re: [ID Discuss] "Name" for product design document /
deliverable

On 9/29/05 2:15 PM, "Wilson, Russell" <Russell.Wilson at netqos.com> wrote:

> I've had the following suggestions:
> 1. Product Design Specification (or Description) 2. GUI
> Specification 3. FRS (Functional Requirements Specification) 4. PRD
> (Product Requirements Document)

I'd go with Product Design Document
That's quite a comprehensive deck you hand in there. Good for you!

With that much in there, I would call it the product design bible, but
that's me. ;) Or the Product Testament. :)

-- dave

David Heller
http://synapticburn.com/
http://ixdg.org/
Dave (at) ixdg (dot) org
Dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk at hotmail.com

_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/
_______________________________________________
Welcome to the Interaction Design Group!
To post to this list ....... discuss at ixdg.org
(Un)Subscription Options ... http://discuss.ixdg.org/
Announcements List ......... http://subscribe-announce.ixdg.org/
Questions .................. lists at ixdg.org
Home ....................... http://ixdg.org/

Syndicate content Get the feed