How to cope with missing process deliverables andscope creep

13 Nov 2006 - 12:26pm
7 years ago
3 replies
453 reads
jbellis
2005

Rein,
You ask a very concise 393-word question, one that many of us ask often. It
borders on a very lengthy prior thread (see "Functional Specs" at
http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2006-March/subject.html )
about the tug-of-war between timelines, modern projects, and prescriptive
design.

But I'm going to focus on your statement... "the lack of a good ... user
flow descriptions." You might be able to survive and recover from crude
graphics, low fidelity to Win/Mac expectations, poor fault tolerance, and
even missing functions, but if there's not a clearly shared vision about the
usage scenarios you're doomed, right? So the answer is, focus on that?

www.jackbellis.com

----- Original Message -----
From: "R. Groot" <rein.groot at gmail.com>

> Because of these findings I decided to go a step back in the process.
> Because of the (also very classic) constraints I didn't have that much
time
> so I decided not to produce the functional specs document and user flows
but
> just do a redesign of the screen organization and flow by means of
> wireframes. Taking the original functional design as a functional
reference
> since this seemed to contain all aspects, although in a very condensed an
> interwoven form of 1 document (instead of several specific).
>
> Well I could not have been more wrong. Because of the lack of a good
> functional specification, and user flow descriptions we are using the
> wireframes as functional reference and user flow description. Which pretty
> much means that there is no signed of document of reference to decide on
> wether the wireframes are complete or not causing almost unstoppable scope
> creep and unclear interface design.
>
> I am guessing this is pretty much a classical (lowbudget) project so I
hope
> some of you have any experience to share on how to, at least, control the
> situation more. Would it be wise to still make the user flows and
functional
> specs? Taking some time now, but avoiding more time beeing taken later on.
>
> With regards,
> Rein Groot
>
>
>
> --
> So it works.
> But can people work WITH it?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

Comments

13 Nov 2006 - 6:06pm
Kimberly Paluch
2006

Hello Rein,

To add to Jack's comment, I agree that you need to take a step back, and
try to solidify the requirements of this project or you can end up with
something months overdue and much frustration on both the client side
and your end. Having been a project manager for some time, I would
advise that you be open with the client and begin to revisit the goals.
Even if you do not write a lengthy functional requirements document,
having a thorough bullet-point list of the important points, features
and usage goals will help to redirect your development. You can then use
this new understanding to solidify your scenarios and wireframes, and
use these as the official documents for avoiding scope creep.

As Jack said, if your usage scenarios are out of alignment, it's highly
improbable that you will end up with a good user interaction or an
on-time project.

Best of luck!

-Kimmy
http://www.paradymesolutions.com/

jackbellis.com wrote:
> Rein,
> You ask a very concise 393-word question, one that many of us ask often. It
> borders on a very lengthy prior thread (see "Functional Specs" at
> http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/2006-March/subject.html )
> about the tug-of-war between timelines, modern projects, and prescriptive
> design.
>
> But I'm going to focus on your statement... "the lack of a good ... user
> flow descriptions." You might be able to survive and recover from crude
> graphics, low fidelity to Win/Mac expectations, poor fault tolerance, and
> even missing functions, but if there's not a clearly shared vision about the
> usage scenarios you're doomed, right? So the answer is, focus on that?
>
> www.jackbellis.com
>
> ----- Original Message -----
> From: "R. Groot" <rein.groot at gmail.com>
>
>
>> Because of these findings I decided to go a step back in the process.
>> Because of the (also very classic) constraints I didn't have that much
>>
> time
>
>> so I decided not to produce the functional specs document and user flows
>>
> but
>
>> just do a redesign of the screen organization and flow by means of
>> wireframes. Taking the original functional design as a functional
>>
> reference
>
>> since this seemed to contain all aspects, although in a very condensed an
>> interwoven form of 1 document (instead of several specific).
>>
>> Well I could not have been more wrong. Because of the lack of a good
>> functional specification, and user flow descriptions we are using the
>> wireframes as functional reference and user flow description. Which pretty
>> much means that there is no signed of document of reference to decide on
>> wether the wireframes are complete or not causing almost unstoppable scope
>> creep and unclear interface design.
>>
>> I am guessing this is pretty much a classical (lowbudget) project so I
>>
> hope
>
>> some of you have any experience to share on how to, at least, control the
>> situation more. Would it be wise to still make the user flows and
>>
> functional
>
>> specs? Taking some time now, but avoiding more time beeing taken later on.
>>
>> With regards,
>> Rein Groot
>>
>>
>>
>> --
>> So it works.
>> But can people work WITH it?
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> List Guidelines ............ http://listguide.ixda.org/
>> List Help .................. http://listhelp.ixda.org/
>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>> Announcements List ......... http://subscribe-announce.ixda.org/
>> Questions .................. lists at ixda.org
>> Home ....................... http://ixda.org/
>> Resource Library ........... http://resources.ixda.org
>>
>>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>

14 Nov 2006 - 5:41am
R. Groot
2006

First I'd like to thank averybody for replying so fast and helpful.

I've done some more reading of articles and former discussions according and
came to the following realization:
we are using our client as the functional specs/userflow document. Scary
thought.
I guess I will indeed sit down with him and bulletpoint the specs with him.

Thanks again.

--
So it works.
But can people work WITH it?
Interaction Design will set your users free (and so will make you a s@#$%t
load of money in the process)

14 Nov 2006 - 11:29am
.pauric
2006

I do not have much to add to the expert replies on good practice that you
have received so far. However, here's a little anecdotal example of a
similar situation (aka 'mess') I found myself in.

I was recently involved in a program that started as concept, a good one,
but without much in the way of functional requirements at the beginning
Part of the issue was a disparate team in terms of location and culture. The
presentation layer and OS were being developed by an eager team in India,
the hardware and an api by an apprehensive team in China, both taking
'orders' from 'westerners' (o; Issues further compounded by this program
being beyond bleeding edge tech and everyone had their own vision for the
exact feature set we needed on the initial release.

I helped program management garner consensus and flesh out the functional
requirements by rapidly generating iterative candidate designs. I've always
found buy-in easier with a visual reference. Another advantage specific to
this case was that I was able to insert a scalable ui structure on version
1. Nothing worse than trying to convince a project to take two steps
backward for one step forward at a later date.

So, in some circumstances the team/client needs to visualise what the stake
looks like in the ground before they will agree to hammer iint to the
ground. This is especially true where you have a language barrier and
cross-disciplinary teams, pictures speaking a thousand words and all that.
I have a simple .doc format that allows easy conversion of the wireframe in
to a functional spec if you want to contact me I'll send you an example
(although it may not suit your style/project).

regards - pauric

Syndicate content Get the feed