Remote IxD work

15 Nov 2006 - 6:12pm
7 years ago
3 replies
424 reads
Robert Hoekman, Jr.
2005

I have worked on a few small, remote IxD projects (involving primarily
expert reviews, wireframes, task flow diagrams, etc - not user research),
and have discovered it can either be a pretty tricky process to maneuver or
a complete cake-walk.

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?

-r-

Comments

15 Nov 2006 - 6:37pm
Steve Baty
2009

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

16 Nov 2006 - 8:24am
AlokJain
2006

We (http://www.satyam.com) have worked on many large end to end user
experience projects, where we have provided solutions using a "global
delivery model" which means part of the team is in client location and
part in other locations bringing the cost advantages to the clients in
the process.

The depth of business context decides the extent of our ability to do
it remotely. So for instance if one is building an events management
application, it requires comparatively much less business context to e
understood compared to a financial system specific to an organization.

The other aspect that affects is business requirement definition (not
including user research) on how clear the client is, if it is evolving
then we need much more one to one interaction, but if it is well
defined remote functioning is a greater possibility.

Depending on above we decide which activities are needed to be done at
client location and can be handled remotely. There are cases in which
90% of the solution is built remotely, and there cases in which most
of the work needs to be done at client location.

--
Best Regards
Alok Jain
----------------------------------------------------------
http://www.iPrincipia.com

On 11/15/06, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
> I have worked on a few small, remote IxD projects (involving primarily
> expert reviews, wireframes, task flow diagrams, etc - not user research),
> and have discovered it can either be a pretty tricky process to maneuver or
> a complete cake-walk.
>
> 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?
>
> -r-
> ________________________________________________________________
> 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
>

18 Nov 2006 - 5:25am
pabini
2004

I've done remote design work successfully for many years--sometimes with no
in-person client interaction; at other times, with some onsite meetings. The
work for which I'm primarily responsible may encompass interaction design,
visual interface design, information architecture, and expert reviews.

I always prefer to get involved at the product definition stage. That way, I
can ensure that the marketing requirements are clear; if it's a product
revision, that usability requirements are part of the product definition;
and that the software architecture doesn't preclude my pursuing an optimal
design solution.

I don't typically do wireframes. I write detailed specifications and provide
Photoshop or HTML/CSS prototypes. I think it's essential to provide detailed
documentation when working remotely. I always post specs and prototypes
online, so everyone has access to the current versions. To ensure that
people can easily refer to particular specifications during teleconferences
or online meetings, I number the sections, figures, and tables. I use tables
extensively, placing most detailed specifications within them and number
each row. By the time one gets through the spec review process, the specs
should be absolutely clear and as complete as possible. The specs also
include a detailed revision history, with links to revised sections.

I typically work collaboratively with the product manager and system
architect or lead engineer throughout a project. So, while I'm responsible
for design decisions, the team understands how I made them, I've taken
marketing requirements and technical constraints into account, and the
design has buy-in. And I work with them to determine what our process will
be. It's often necessary to adapt one's design process to a product team's
usual process, ensuring that key elements of the design process are
incorporated in that process.

To ensure your design gets built, it's important to sustain a relationship
with the development team throughout the development cycle. It's important
to do the following, as I mentioned in a recent talk:

* Act as a consultant to the development team and be available to answer
questions.
* Clarify your specifications so they cover the questions developers raise.
* Provide error messages as needed.
* Revise your specifications as necessary in light of technical constraints
developers encounter.
* Adjust the scope of your specifications as requirements change.

The key to working effectively from a distance is trust (doing what you say
you'll do) and frequent and effective communication (both verbal and
written). It's really important to build relationships with your colleagues,
just as you do when you work proximately.

Pabini Gabriel-Petit
Principal User Experience Architect
Spirit Softworks LLC
www.spiritsoftworks.com

Publisher & Editor in Chief
UXmatters
www.uxmatters.com

Robert Hoekman, Jr. wrote:

I have worked on a few small, remote IxD projects (involving primarily
expert reviews, wireframes, task flow diagrams, etc - not user research),
and have discovered it can either be a pretty tricky process to maneuver or
a complete cake-walk.

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?

Syndicate content Get the feed