To spec or not to spec?

16 Oct 2009 - 3:42pm
4 years ago
19 replies
1220 reads
Siegy Adler
2009

I’m an advocate for writing functional specs. Here are 3 reasons why I
believe specs facilitate development of Websites and applications:

1) Specs serve as the blueprint for the developer, which enables them
to review the project and start coding without delay. Would you build
a house without a written plan?
2) Specs that are reviewed/approved by project stakeholders help
ensure that the finished product meets expectations. Isn’t it easier
to update a spec than to rewrite lines of code?
3) Specs also serve as the starting point for the development of use
cases, which streamline the QA process. How else are the testers
supposed to know what to expect when a button is pressed, etc.?

I can’t think of a good reason not to spec. Can you?

Comments

16 Oct 2009 - 3:59pm
AlokJain
2006

Siegy,

I think there are definite advantages of writing functional specs, the
question would be more of how detailed do you go. I have seen specs
written the degree of a pseudo code (almost). The biggest concern with
going too detailed upfront is that it's not very change friendly. I
remember reading Austin's blog/tweet - What you call "scope creep" I
call "scope fix". Requirements, understanding of customers behavior
and design, technology everything evolves.

Some minimal documentation, with lots of collaboration would work out
better in terms of quality, and with smaller 3-4 week sprints you &
customer would see progress fast enough. You might want to experiment
with the idea in your team with a smaller part of solution, to see the
advantages and challenges involved.

Alok Jain (AJ)
UX/Product Manager - Insightify.com

On Oct 16, 2009, at 1:42 PM, siegy adler wrote:

> I’m an advocate for writing functional specs. Here are 3 reasons why I
> believe specs facilitate development of Websites and applications:
>
> 1) Specs serve as the blueprint for the developer, which enables them
> to review the project and start coding without delay. Would you build
> a house without a written plan?
> 2) Specs that are reviewed/approved by project stakeholders help
> ensure that the finished product meets expectations. Isn’t it easier
> to update a spec than to rewrite lines of code?
> 3) Specs also serve as the starting point for the development of use
> cases, which streamline the QA process. How else are the testers
> supposed to know what to expect when a button is pressed, etc.?
>
> I can’t think of a good reason not to spec. Can you?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

16 Oct 2009 - 4:04pm
jpb
2009

> I can’t think of a good reason not to spec. Can you?

Its important to plan ahead, but specs are artifacts which can easily
diverge from reality as code gets written. Agile processes eschew
specs, instead favoring the following:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

Agile isn't for everyone, but its treated me well so far.

On Fri, Oct 16, 2009 at 9:42 AM, siegy adler <siegy at scadler.com> wrote:
> I’m an advocate for writing functional specs. Here are 3 reasons why I
> believe specs facilitate development of Websites and applications:
>
> 1) Specs serve as the blueprint for the developer, which enables them
> to review the project and start coding without delay. Would you build
> a house without a written plan?
> 2) Specs that are reviewed/approved by project stakeholders help
> ensure that the finished product meets expectations. Isn’t it easier
> to update a spec than to rewrite lines of code?
> 3) Specs also serve as the starting point for the development of use
> cases, which streamline the QA process. How else are the testers
> supposed to know what to expect when a button is pressed, etc.?
>
> I can’t think of a good reason not to spec. Can you?
>
>
> ________________________________________________________________
> Reply to this thread at ixda.org
> http://www.ixda.org/discuss?post=46833
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
_________________________
@jonathanpberger
http://www.marketpublique.com
http://www.jonathanpberger.com
718.930.2165
This email is: [*] bloggable [ ] ask first [ ] private

16 Oct 2009 - 4:18pm
usabilitycounts
2008

I agree with jonathan. Nice specs are wonderful, but with the house
approach, does someone have a nicely framed copy of the blueprints in
their bedroom?

In the end, all that matters is an effective product. Sometimes we
forget that.

On Oct 16, 2009, at 2:04 PM, jonathan berger wrote:

>> I can’t think of a good reason not to spec. Can you?
>
> Its important to plan ahead, but specs are artifacts which can easily
> diverge from reality as code gets written. Agile processes eschew
> specs, instead favoring the following:
>
> - Individuals and interactions over processes and tools
> - Working software over comprehensive documentation
> - Customer collaboration over contract negotiation
> - Responding to change over following a plan
>
> Agile isn't for everyone, but its treated me well so far.
>

Patrick

twitter: usabilitycounts | uxlosangeles | cooltechjobs
email: pat at usabilitycounts.com | blog: http://www.usabilitycounts.com
cell: (562) 508-1750 | office: (562) 612-3346

The last UX books you'll ever need.

16 Oct 2009 - 5:22pm
ambroselittle
2008

Forgive me. I seem to be feeling particularly ornery right now, but this
stuff touches a nerve..

On Fri, Oct 16, 2009 at 9:42 AM, siegy adler <siegy at scadler.com> wrote:

> I’m an advocate for writing functional specs. Here are 3 reasons why I
> believe specs facilitate development of Websites and applications:
>
> 1) Specs serve as the blueprint for the developer, which enables them
> to review the project and start coding without delay. Would you build
> a house without a written plan?
>

Seriously, the mapping of software creation to building construction needs
to stop. If I could find the person who first suggested this metaphor, I'd
shove them into a wormhole.

> 2) Specs that are reviewed/approved by project stakeholders help
> ensure that the finished product meets expectations.

If you mean functional spec as you said above, then no, absolutely not. I'm
sure there are exceptions and people who are using a soft tissue lens on
their memory, but stakeholders--normal people in general--will rarely be
able to imagine a system based on a functional spec, and even if they do,
chances are it will be different from what you and the others on the
implementation team have in mind. This means it will be a total crap shoot
in terms of whether or not building to a functional spec "meets
expectations." This is a widely shared sentiment in the software community
based on tons of bad experiences relying on functional specs for shared
understanding.

If you have a fully functional prototype that simulates the end product as a
spec, then maybe your statement comes close to be tentatively true.
Otherwise, no way.

> Isn’t it easier
> to update a spec than to rewrite lines of code?
>

Not if your spec is code. ;) Not if you go through endless spec revisions
because people can't use functional specs to come to a shared imagination of
what they envision the system to mean. Not if you bother writing the spec,
revising it several times, and then have to change the code anyways (and
then probably have to update the spec again to match) and then repeat this
many times throughout the project.

> 3) Specs also serve as the starting point for the development of use
> cases, which streamline the QA process.

Wha wha wha??? I'm in shock.. give me a moment.. did you say a functional
spec is the starting point for the development of use cases? Oh dear...

Even if you do write a functional spec, it should be the *product* (i.e.,
comes out of/after) the understanding of (and, if necessary, documentation
of) use cases. The *stories* come first. End of story.

> How else are the testers
> supposed to know what to expect when a button is pressed, etc.?
>

If the interface doesn't make this clear, you failed. If you're starting
from a functional spec, I'm not surprised this is a problem.

Think about it this way. If someone who is, theoretically, as computer and
system savvy as a QA tester can't understand from your interface what is
supposed to happen when a button is pushed, how in tarnation are your users
supposed to figure it out? Are you going to make your users read the
functional specs in order to interact with the system?

> I can’t think of a good reason not to spec. Can you?
>

Because it is a waste of valuable time for everyone involved that makes
people 1) falsely believe they have a shared understanding, 2) forces you
into a function-centric thinking rather than a human and experience-centric
way of thinking, and 3) ultimately causes this wrong thinking to seep into
the interface and results in stereotypically bad software from a human
perspective that not only does not meet expectations but actually is worse
than the worst they could have imagined had they tried to imagine a system
as far away from their expectations as humanly possible and still resemble
in some wraith-like form the functional specs they thought they read three
years ago when the project was six months into planning and long delayed due
to repeated revisions to the three hundred page functional spec matrixed
across sixteen documents. [For the record, that was hyperbole.]

Now, having said all that, there are things that can be decent specs, and
lots of things that can help waay better than functional specs in
establishing a shared understanding. Some examples are stories, scenarios,
sketches, and more or less functional prototypes. The stories and scenarios
are a much better source for QA and usability testing to start from than a
functional spec, and they can feed into other disciplines related to full
product creation.

Don't do a whole lot of specking--just enough to get folks pointed in the
right direction and working within a holistic interaction design framework.
Specking should be looked at as a necessary evil that should be minimized
when possible in favor of iterative collaboration over a designed solution.

-a

16 Oct 2009 - 5:41pm
Oleh Kovalchuke
2006

Sure.

This is from very recent experience: necessity of spec revisions
prevents innovation. People invest too much time, effort and more
importantly get attached to ideas in the specs.

Oleh Kovalchuke

On Oct 16, 2009, at 1:42 PM, siegy adler <siegy at scadler.com> wrote:

> I’m an advocate for writing functional specs. Here are 3 reasons why
> I
> believe specs facilitate development of Websites and applications:
>
> 1) Specs serve as the blueprint for the developer, which enables them
> to review the project and start coding without delay. Would you build
> a house without a written plan?
> 2) Specs that are reviewed/approved by project stakeholders help
> ensure that the finished product meets expectations. Isn’t it easier
> to update a spec than to rewrite lines of code?
> 3) Specs also serve as the starting point for the development of use
> cases, which streamline the QA process. How else are the testers
> supposed to know what to expect when a button is pressed, etc.?
>
> I can’t think of a good reason not to spec. Can you?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

17 Oct 2009 - 2:19pm
Jim Leftwich
2004

I've had fantastic success with highly detailed design and
interaction specs for 26 years. Across an incredibly wide range of
products, devices, platforms, and systems.

The specs I'm familiar with have spanned a wide range of fidelity,
from ongoing iterative and minimal specs co-evolved with coding to
high-fidelity detailed specs documenting every last detail and
resource which were then handed off to development teams and built to
exact spec. Successfully.

There are no hard and fast rights or wrongs in this field. I would
discount strident opinions disparaging the use of design specs.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

16 Oct 2009 - 4:46pm
Andy Pearson
2009

If you don't spec something then the developer has to guess what to
do.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

17 Oct 2009 - 10:41am
r32soul
2009

functional specs are important to all stakeholders. i can't imagine
a ux/interaction designer not provide functional specs with a
finished wireframe.

Especially if you are not the actual front-end developer, functional
specs is the communication medium between the designer, prototyper,
engineers, and QA.

Without it, everyone will interpret the interactions, scenarios in
different ways.

I think the better question is when to provide functional specs. If
you are just doing concept designs/sketches, I think it's better to
keep it high-level and allow stakeholders to review the design
without specs so the use cases are open to interpretation.

However, once you start to work on a UI design/wireframe where it
will resembles the finish product, you should also spec it out so
engineers/prototypers can develop the application based on the spec
and the design, and QA can use the spec to test scenarios and use
cases.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

16 Oct 2009 - 4:47pm
Anonymous

I think a more appropriate question is, "what sort of spec to you use
for a given audience?" Different stakeholders can prefer their specs
to be delivered in different formats (not that they always get to
have it their way, of course).

Some might like specs in the form of wireframes for easy lo-fi
visualization, some might like large printed documents for legal or
contractual reasons, some might like pseudocode (or skeleton code),
and some might think anything but working program is an unecessary
waste-of-effort. The problem comes when you try to please them all
with a single format. One size does not fit all (very well).

I think Siegy's assertions would be better stated in a less absolute
format.

1) Specs _can_ help a developer, but they can also confound them if
not written correctly.

2) It _can_ be easier to update a spec than to rewrite code, but it
can also be easier to rewrite the code than it is to update the
spec.

3) Specs _can_ serve as a starting point but they can also get out of
date and do more harm than good if not cared for throughout the
project.

The trick is to know what works best for the project you're working
on and the environment in which you're working.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

19 Oct 2009 - 4:09am
Eirik Midttun
2009

Of course you should spec! The interesting question is: Do have to
write a document called "functional specification".

I could have written a whole lot about it, but I see most of my
points are already found in Ambrose's reply. Cheers!

- Eirik

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

19 Oct 2009 - 8:58am
Brooke Baldwin
2008

siegy
usually i will meet with the development team at the beginning of a
project and decide together what kind of documentation they're going
to get.
generally that means everyone brings samples of previous work and we
negotiate using those artifacts to focus the discussion.
and i've just discovered that agile's way of little to no
documentation doesn't seem to work for the team i'm with right now.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

19 Oct 2009 - 10:12am
Paul Bryan
2008

I%u2019m trying to imagine the work scenes that are the context for
the widely disparate views expressed in replies above. I think the
dimension that segments the responders is the degree to which the
people writing the code are separated from decisions about design, in
a physical distance, process, or organizational sense.

Where there is no separation, then specs are viewed as unnecessary
palabra that require time and energy to produce, and more time to be
maintained. Where there is a significant separation, perhaps even
different companies doing design and development, or on-shore design
and off-shore development, then specs are part of the on-going
contract of what needs to be done.

Our team always produces functional spec docs for e-commerce sites we
design because another company uses them as a starting point for their
work, and it%u2019s not at all obvious to them what will happen, from
a data modeling and product affiliate logic table perspective, when a
given button is clicked. They would have to discover that all over
again for themselves, and we prefer to spare them that waste of
resources.

I think your answer, Siegy, should be based on how much guidance you
will be able to give once the ink is dry on your specs.

Paul Bryan
Usography (http://www.usography.com)
Blog: Virtual Floorspace (http://www.virtualfloorspace.com)
Linked In: http://www.linkedin.com/in/uxexperts

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

19 Oct 2009 - 3:52pm
ambroselittle
2008

Despite protestations to the contrary, nobody--certainly not I--would
advocate that you don't need to communicate what needs to be implemented.
It's a question of how it is done, and traditional func specs are but one,
very poor (IMO) way to do so.

On Mon, Oct 19, 2009 at 4:12 AM, paul bryan <paul at usography.com> wrote:

> I think the
> dimension that segments the responders is the degree to which the
> people writing the code are separated from decisions about design, in
> a physical distance, process, or organizational sense.
>

This can be true, but Scott
Ambler<http://www.ambysoft.com/onlineWritings.html>has been
researching, thinking about, and writing about the different
contexts in which Agile plays, and specifically distributed and large teams
via his agility at scale
blog<https://www.ibm.com/developerworks/mydeveloperworks/blogs/roller-ui/rendering/feed/ambler/entries/atom>.
His thinking on docs in
general<http://www.agilemodeling.com/essays/agileDocumentation.htm#CriticalPoints>is
good, and he specifically cautions
against hand-offs<http://www.agilemodeling.com/essays/agileDocumentation.htm#EffectiveDocumentationHandoffs>.
I'm not saying he's the end all authority or best guy for software process
in general, but he's probably the most prolific, well-researched, and
balanced speaker and writer on the subject of Agile. Point is that not
wanting to do func specs doesn't have to be related to the elements you
mention.

Nor would I hold up Agile as the end all in terms of the way to make
software, either, but there can be a lot of synergy in terms of aspirations
between it and UX/XD/IxD. In the last few years, it seems that the
UX/XD/IxD world has crossed a threshold where Agile is now more assumed than
less; I think people are seeing <http://www.agileexperiencedesign.org/> the
synergy and, if nothing else, the reality that Agile (broadly speaking) is
where most of software dev is these days. I suspect as in-house/FTE
UX/XD/IxD competency becomes more and more common, this trend will only
continue because hand offs necessitated by consultancy will decline.

Anyways, I think the difference between doing traditional func specs and
other docs lies more in familiarity and comfort zones. We have quite a
heritage of functional specs in software, and people are loath to change,
even though the software industry at large has been going that way for over
a decade.

I should maybe be clearer that I'm talking about "functional specifications"
in the traditional sense of function-centric, often componentized,
functional descriptions of what the *system shall do*. I think even
traditional use case diagrams and use case scenarios are not ideal, even
though they're at least trying to focus on use rather than just system
functions. The problem is that usually they're still
function/system-centric and the user is this amorphous "actor" who is
basically just there to serve as an external entity that is acting on the
system--the centricity is still systemic and functional when it should be on
the people and purpose of the software. And they are only marginally better
at helping normal people grasp what the end product will be like.

When I think, talk, and write about how to do software, I'm pretty
passionate about it and am concerned, in a forum like this, about the
*best*way to do software. That means in some ideal world somewhere,
but best
practices always have to be contextualized. The thing is, there are better
alternatives to func specs even in the most distributed and diverse teams; I
can't imagine a scenario where they're better than alternatives except in
the case that people just don't want to change or just don't know any
better. That's why I was rather hyperbolic in my previous reply--to make a
point.

-a

20 Oct 2009 - 12:30am
cfmdesigns
2004

On Oct 16, 2009, at 3:22 PM, ambrose little wrote:

>> How else are the testers
>> supposed to know what to expect when a button is pressed, etc.?
>>
>
> If the interface doesn't make this clear, you failed. If you're
> starting
> from a functional spec, I'm not surprised this is a problem.
>
> Think about it this way. If someone who is, theoretically, as
> computer and
> system savvy as a QA tester can't understand from your interface
> what is
> supposed to happen when a button is pushed, how in tarnation are
> your users
> supposed to figure it out? Are you going to make your users read the
> functional specs in order to interact with the system?

There are two levels here to be considered:

* At a gross level, this is completely true. As a tester, I had
better not need an additional document to figure out what that button
will do (in general), or where to find the Save command.

* But that's only at the gross level. If there are any subtleties,
any enhanced behaviors, anything special to the controls or the
behaviors or the application, then they had better be detailed if you
expect me to test them. (And if you expect the developer to code
them.) They can't read your mind, and QA can't read either of your
minds. If you don't document it in some form, you can be sure that it
won't get implemented right/completely and it won't get tested right/
completely/maybe at all.

I have tested a feature from a "spec" which consisted of five words on
a list of features, nothing more even when I asked for details. (Heck
if I can remember what the feature was. Needless to say, I don't
think it got tested very well. But neither did that team's project
management particularly care about QA feedback or test results in
their version of "Agile". Whole 'nother thread there.)

I've been on my current project for 4 years, and I just discovered
some behaviors this past week which have probably never worked
correctly because no one realized they were supposed to be tested, no
one on the team realized they even existed. Well, we knew they
theoretically existed, but they were never part of test suites.
Because there were no "artifacts" discussing them.

-- Jim

21 Oct 2009 - 12:52am
Anonymous

I can't believe some of the commentary on this thread. The overwhelming
problems of software in the modern world are as a result of whats going on
in this thread! Specifically the problems are

1) *There are many people (product managers) writing functional specs where
the contents are disconnected pieces of "abstract feature stuff."* For
example, the user says "I need to do xyz so that i can meet this goal" and
the product manager says ok "let's add a button that let's the user do xyz."
XYZ is never really designed, with more than a casual thought. Whether
XYZ is the best way to meet the users goal is only mildly considered, maybe
there was a UVW way to do it which wasnt a button at all. Neither XYZ nor
UVW are really drawn out visually, nor tied together in an end to end
scenario, and without that even nobody internally really knows how XYZ will
behave in the milliseconds after you click it, nor think through how xyz and
abc - an older feature- or zyx another new feature - may conflict. If a
user was consulted ("is that what you said? you wanted a button for xyz?")
they will nod their head, because at no point in time is the experience
actually illustrated to the user! So they are imagining something that
doesn't even exist, which ding ding ding, they can't do and neither can
anyone else! This is the most dangerous product design process known to
man! There is no design! Just features! We all march along in
agreement, but we all are almost 100% imaging different physical
implementations!

2) *There aren't actual trained interaction designers researching,
prototyping and detailing the interaction design of the product! * Without
people who can do this, and yes these people must understand how to help
dovetail with dev constraints, many projects fail to deliver an experience.
They may make the check on the functional spec, but they aren't designed
for all of the soft qualities of experience - learnability, findability,
discoverability, usability, pleasure, beauty!

If the world is going to see that design means something - and that there
are people who do it and have skill in it - we have to deconstruct the
mythology around this.

*> In the end, all that matters is an effective product. *

True but this seems to suggest there is no connection between the process
and the result. How many bad mp3 player companies after their functional
spec was written and dev started rolling forward were suddenly going to push
out an iPod? What if all that matters is having a design that people love
and then going to the ends of the earth executing on it. Ya of course we
will have to make hard decisions along the way because of technology and
schedule.

*- Responding to change over following a plan*

Absolutely worthless statement. If you had an abstract non specific plan
then it is going to change because it isn't a fleshed out plan (only a rough
suggestion), and the statement is tautological. But if your plan was
something marvelous and very tangible, then changes are just what you have
to do to achieve that marvelous outcome.

*I just discovered some behaviors this past week...there were no "artifacts"
discussing them.*

That is normal for most companies. Things get built haphazard and you hope
for the best. Some of what gets built is useful but is impossible for users
to find it, so those code paths never get tested and of course in the
abstract functional spec its not there. I assure you interaction designers
do need to exist to focus on the behaviors across the feature set, across
all the buttons, across all of the user paths.

Finally, I know this is a big leap of faith because many have not seen a
good interaction design process in action, so you're used to walking along a
vague set of inputs and then waiting for unknown outputs of the process.
Inevitably though, these people are all in agreement that if* they were
funding* the project out of pocket they would expect to see a specific plan
on what the product is going to look like and how users will use it *before
*the development started.

Navid

On Mon, Oct 19, 2009 at 4:52 PM, ambrose little <
ambrose at goodexperiencedesign.com> wrote:

> Despite protestations to the contrary, nobody--certainly not I--would
> advocate that you don't need to communicate what needs to be implemented.
> It's a question of how it is done, and traditional func specs are but one,
> very poor (IMO) way to do so.
>
> On Mon, Oct 19, 2009 at 4:12 AM, paul bryan <paul at usography.com> wrote:
>
> > I think the
> > dimension that segments the responders is the degree to which the
> > people writing the code are separated from decisions about design, in
> > a physical distance, process, or organizational sense.
> >
>
> This can be true, but Scott
> Ambler<http://www.ambysoft.com/onlineWritings.html>has been
> researching, thinking about, and writing about the different
> contexts in which Agile plays, and specifically distributed and large teams
> via his agility at scale
> blog<
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/roller-ui/rendering/feed/ambler/entries/atom
> >.
> His thinking on docs in
> general<
> http://www.agilemodeling.com/essays/agileDocumentation.htm#CriticalPoints
> >is
> good, and he specifically cautions
> against hand-offs<
> http://www.agilemodeling.com/essays/agileDocumentation.htm#EffectiveDocumentationHandoffs
> >.
> I'm not saying he's the end all authority or best guy for software process
> in general, but he's probably the most prolific, well-researched, and
> balanced speaker and writer on the subject of Agile. Point is that not
> wanting to do func specs doesn't have to be related to the elements you
> mention.
>
> Nor would I hold up Agile as the end all in terms of the way to make
> software, either, but there can be a lot of synergy in terms of aspirations
> between it and UX/XD/IxD. In the last few years, it seems that the
> UX/XD/IxD world has crossed a threshold where Agile is now more assumed
> than
> less; I think people are seeing <http://www.agileexperiencedesign.org/>
> the
> synergy and, if nothing else, the reality that Agile (broadly speaking) is
> where most of software dev is these days. I suspect as in-house/FTE
> UX/XD/IxD competency becomes more and more common, this trend will only
> continue because hand offs necessitated by consultancy will decline.
>
> Anyways, I think the difference between doing traditional func specs and
> other docs lies more in familiarity and comfort zones. We have quite a
> heritage of functional specs in software, and people are loath to change,
> even though the software industry at large has been going that way for over
> a decade.
>
>
> I should maybe be clearer that I'm talking about "functional
> specifications"
> in the traditional sense of function-centric, often componentized,
> functional descriptions of what the *system shall do*. I think even
> traditional use case diagrams and use case scenarios are not ideal, even
> though they're at least trying to focus on use rather than just system
> functions. The problem is that usually they're still
> function/system-centric and the user is this amorphous "actor" who is
> basically just there to serve as an external entity that is acting on the
> system--the centricity is still systemic and functional when it should be
> on
> the people and purpose of the software. And they are only marginally
> better
> at helping normal people grasp what the end product will be like.
>
> When I think, talk, and write about how to do software, I'm pretty
> passionate about it and am concerned, in a forum like this, about the
> *best*way to do software. That means in some ideal world somewhere,
> but best
> practices always have to be contextualized. The thing is, there are better
> alternatives to func specs even in the most distributed and diverse teams;
> I
> can't imagine a scenario where they're better than alternatives except in
> the case that people just don't want to change or just don't know any
> better. That's why I was rather hyperbolic in my previous reply--to make a
> point.
>
> -a
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

19 Oct 2009 - 10:34am
Mary Connor
2009

Agile. Specs have no place in our Scrum environment.
1. Stories (and daily discussions with product owners) drive the plan.
2. Stakeholders (and invited customers) approve/criticize/reject the work done every other week, at our reviews -- they don't approve descriptions about what to code, they approve functionality as demonstrated.
3. Testers use their product knowledge to help shape the development decisions throughout the sprint, so they're not passively waiting for direction.

I'm very grateful our days of coding by specs are over. We just jump in and do it, and fix it if we get it wrong.
Mary Connor

PS: For environments where specifications work, I feel strongly that they belong in a wiki or web CMS (like Drupal) for collaboration, rather than standalone Office documents. Takes a while to wean folks from that.

-----Original Message-----
From: new-bounces at ixda.org [mailto:new-bounces at ixda.org] On Behalf Of siegy adler

<snip>

I can't think of a good reason not to spec. Can you?

20 Oct 2009 - 2:46pm
Daniel Reneer
2009

Not sure if anyone else has run into this but a culture of exhaustive
specifications for me is usually the result of a very unhealthy
relationship between product management, design, and engineering.
I've seen PM's try to out-document each other in order to impress
management, as well as engineering resources demand more and more
granularity to design specifications as a way to buy time. In the
end, Design ends up dealing with a 120 page document that no one
really ends up reading, other than as a CYA action. Documentation as
a weapon, I kid you not.

The solution? First, hire people that use technology, that love
technology. You don't know how many times I've asked someone in an
interview what websites, apps or designs inspire them and I get a
blank stare in return (or even better, the "I really don't mess
with technology outside of work" response!). Many design efforts
could be streamlined if there was common awareness of ubiquitous
solutions.

Second, hire folks that can think visually. I've learned that a
picture is NOT worth a thousand words. If a picture was worth a
thousand words, why do I always have to pair visuals with thousands
of words for anyone to understand the design? No amount of spec
writing can compensate for staffing an abundance of non-visual
engineers and product managers (or God forbid, non-visual designers).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

21 Oct 2009 - 4:16pm
robert.gomes@vi...
2009

I just came out of the Agile World Conference here in Toronto.
There is a push to reduce documentation in the Agile Philosophy, BUT
documentation when it is available, the developers appreciate it,
they make comments like, I don't have to guess, thank you, keep it
up, we found that there is less rework.

I investigate the problems, (interview users and subject matter
experts) create mid quality wire frames for all to review, (static
prototypes) and when all agree to move forward we need to at least
define the interactions by creating a (Blue Print).

There has to be a middle ground, 0 docs I can't agree with. Small
deliverable (docs) along side each component, OK

But there is something we seem to be forgetting, when you loose a
developer that has the knowledge, they take that knowledge with them,
and when you hire someone new, it's always the same story, the ramp
up takes to long, new mistakes and new ideas are introduced that WILL
prolong the projects ability to deliver on time.

Documentation is a great way to pass on knowledge.

I am guessing non of you are actually suggesting to go and develop a
(Trading system) (Online Banking System) (Reporting System) with no
recs.

All I can say is Good luck, Agile methodology and core principles,
are communication. And some companies may need more docs than others.
It all depends.

This is starting to sound like the old argument about Design VS
usability, Interesting :-)
Good luck

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

22 Oct 2009 - 5:08pm
Paul Bryan
2008

I read some of the Scott Ambler entries Ambrose listed above. This
confirmed rather than contradicted my assertion that the need for
specifications is inversely proportional to the degree to which the
people writing the code are separated from decisions about design, in
a physical distance, process, or organizational sense.

Scott says that when you are "specifying work for another group..."
that this is a situation "...where AM likely isn't appropriate." I
can't think of a web project that I've worked on since my first web
design job in 1995 in Barcelona that there haven't been multiple
parties focused on design. There can easily be 3 or 4 large companies
involved, perhaps a half dozen smaller companies each with some role
in the design. The complete team can be over 100 people, perhaps on
multiple continents. I'm not trying to say this scenario is superior
or more valuable than the one Scott describes. I'm just saying that
this list includes people from different worlds, but the arguments
are passionately pretending that there is one right answer and the
other people are idiots. No, it's simply that the conditions in
which interaction designers find themselves are extremely different
and there are multiple right answers.

Elsewhere Scott says: "I ask the individual(s) requesting the
documents if they also want to be seen as responsible for the
project's failure because the development team was too busy focusing
on needless documentation and not on building software." This clearly
describes a situation where a small team of 10 or 20 people are
sitting in a room "doin' software." It doesn't remotely describe
the situations I typically find myself in, where developers rarely
have any channel of communication back to people who make decisions
on the client side. The communications with the client are handled by
people who have that as their sole job responsibility. These people,
typically client partners or program managers, would certainly throw
Scott's backside into the street the next day if he talked that way
to a client. But since they are "people people," they would
probably be aware that Scott is very talented at what he does, and
simply keep him many layers removed from the "design decision
dance" that large agencies do with clients.

In large web projects, that dance is done primarily on one platform:
design documentation. Often long before there is a prototype,
depending on the complexity of the architecture and the skills of the
team. There will be changes during development, but those changes will
be extremely expensive and will have to escalate up through multiple
chains of command. Recently I was in a meeting where the whole
internal web team was assembled to discuss the progress of an
e-commerce project. There were about 60 people in the room from the
client side alone. This didn't include business strategy consultants
or offshore development resources. We went through the design
documentation page by page to be sure everyone knew what they had to
produce. That was the first and only "all hands" meeting to my
knowledge. It probably cost in the neighborhood of $50,000 to conduct
that one set of meetings. The team members didn't later decide on the
fly how they were going to shape the product as they went along. They
followed the blueprint.

Inefficient? Perhaps. But the reason for this separation of labor is
that each interactive element in the final product has a direct
impact on what millions of people will do when they get to that page.
The people informing the decision on that element have a lot of data,
quantitative and qualitative, that tells them which element will have
the most positive impact, or they know what they need to do to get
that data. It's their full-time job.

Again, I'm not saying this is in any way superior to small teams
doing great things using Agile methodology or creating breakthrough
product designs. Being a developer or engineer and having that kind
of control over a product is probably very satisfying and efficient.
But that is only one of many work contexts populated by interaction
designers.

About all the Agile references that eschew documentation: I don't
have any doubt that top-tier agencies like Sapient, Razorfish,
Critical Mass, LBi, Macquarium, or Resource Interactive can make
Agile work for the user experience design of large web sites. I'm
all for the focus on efficiency, particularly where data gathering
and design rationale can occur a cycle or two ahead. But I also think
the wholesale adoption of Agile in 2008 and 2009 simply for cost
considerations without thinking through the details of user
experience impact will lead to many, many exploding cigars in 2010
and 2011, after a few quarters of analytics have a chance to tell the
full story.

/pb

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46833

Syndicate content Get the feed