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 <
ambr...@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 <p...@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 agil...@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 ....... disc...@ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
