[IxDA Discuss] Remote IxD work

Doc stevebaty at gmail.com
Wed Nov 15 15:37:45 PST 2006


Robert,

Over the past 12 months we've worked on five large IxD projects: one with a
client in the same city block; one with a client in the same city; two with
clients in different states; one with a client in another country. The key
difference between the first two projects and the three remote projects was
the ease with which we could sit down with the client and work through
questions against a set of wireframes, diagrams, process flows or some other
artefact.

To counter that in the remote projects we provided the clients with a steady
stream of draft documentation and engaged in regular conference calls to
work through and discuss ideas, issues and next steps. For the two
inter-state projects we supplemented this ongoing dialogue with regular (but
less frequent) face-to-face meetings around major milestones.

In looking back on each of these projects the main difficulties seemed to
revolve around the level of sophistication each client had with respect to
reading and understanding the different types of documentation, and the
project process in general. For future projects I will be spending more time
up-front educating the client in those areas where their understanding might
be lacking, so that the review and discussion can proceed more smoothly
during the project. This was particularly highlighted in discussions of
wireframes, where there is a general misconception about the purpose of this
style of document - we get a lot of comments about the 'lack of design'.

I've also found that the client's general level of trust in you is
important. I wouldn't understand the importance of this aspect of the client
relationship when working with remote clients.

As a related point, having the documentation set up in such a way that you
can easily direct the client towards particular elements or notes on
particular pages "you can see on page 17 we have this interaction widget
illustrated by element 2.1" facilitates remote discussion, since it removes
ambiguity. This is useful anyway as a means of tracking changes through the
project, but becomes more so when you're not able to sit down and point
things out on the page.

Finally, the use of an extranet or some central repository for project
documentation is also useful. It alleviates issues around email attachments,
versioning of deliverables, and the like. Everyone in the project has access
to a clear history of the project's documents so you don't have to worry
about whether someone is looking at the latest version during a conference
call.

Best Regards,

Steve Baty

On 16/11/06, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
>
> I'm wondering what experiences others on this list have had. Are there
> particular issues you've come across over and over, specific to remote
> projects, or has it changed every time according to the client and the
> client's process?
>
>
----------------------------------------------
Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
Director, User Experience Strategy
Red Square
P: +612 8289 4930
M: +61 417 061 292

Member, UPA - www.upassoc.org
Member, IxDA - www.ixda.org
Member, Web Standards Group - www.webstandardsgroup.org

Columnist - www.uxmatters.com



More information about the discuss mailing list