

The Documentation Dilemma - lifo
http://37signals.com/svn/posts/3073-the-documentation-dilemma

======
jes5199
I don't think you can keep designers and developers in sync for mobile
platforms.

I work with some amazing designers and some amazing iphone hackers, and it
still takes a team of four programmers a whole month to implement something
that a designer comes up with in a week.

Maybe eventually the tools will improve, but iPhone and Android are not web
enough to be so rapid.

~~~
rsinger9
IMO that presents an opportunity: If 1:1 throughput isn't possible given the
platform, what are the different ways we could approximate it? If we have to
do design in advance, how much should we do, and which parts? All of these
become useful challenges that can increase the role of feedback in your design
when you take them on as such.

------
tomkin
Great article. The company I work for recently decided to ditch the IAs and go
straight to prototyping. At first, I thought the decision was crazy. But the
truth is, people want to _see, feel and interact_ and they won't be "done"
until they can do that.

When we talk about responsive design, it's usually to mean something about
fluid width / device happiness. Going straight to prototyping with the actual
application is just an extension of this mentality.

Here are a few reasons why:

\- Clients will try the prototype in configurations/devices that you don't
have and can't test without employing an army of testers.

\- Clients see conflicts with their business logic and your understanding of
their needs before the roots are too deep.

\- You can actually write articulated unit tests, framework and data structure
based on something you know inheritably works.

\- No one gets left out of the process. Nothing can turn a project sour more
than a member of your team that feels alienated and parachuted into a half-
baked creation.

Of course, with any approach, you need boundaries and a defined scope. When
your client understands specifically what scope is, and that you're watching
for it, the results are predictable.

~~~
wisty
Note, there's also a well-established way to convince non-enlightened clients
not to use a prototype - make it report scary errors (depending on the
sophistication of the client), and warn them that it will take a long time to
debug.

------
vannevar
Design documents are really no different than code that's been written but not
tested. Just as with any other code, you want to test the assumptions made in
the documentation early and often. You don't want to build up a large mass of
documentation that hasn't been at least prototyped, just as you don't want to
write reams of code that you haven't yet run.

------
mikeocool
Interesting points, particularly about clients only caring about the
deliverable. Some agency-type companies I've worked for have seemingly added
documentation-generating steps, just because it added on hours that could
billed.

If you need a UX person to do wire frames before a designer does the visual
design, you get a whole bunch of extra billable hours on a project. The funny
part was that clients rarely got what they were looking at it when presented
with wireframes. They constantly thought they were visual design mockups, so
the feedback they gave on them was never particularly helpful.

------
kyt
I don't understand how this works at scale. This seems to be a strategy for a
one or two person team.

~~~
rsinger9
You scale it by identifying which scopes of work are dependent on others and
which scopes are independent. Any independent scopes can be designed,
developed, and reviewed by small teams working at pace together, parallel to
other teams. They key is how you break the work down into scopes, and how you
see their interdependencies at a given moment and over time.

------
j45
Documentation isn't the issue.

Learning the correct amount, type, and depth of documentation that is fruitful
is key.

In this case, prototyping seems obvious to do when you know how it should be,
or a starting trajectory. When you don't, and/or there is management/design by
committee, I'm sure there's other large problems besides IA documents.

Documentation exists in two forms:

\- for those operationally familiar with a system.

\- for those not familiar with a system.

I almost like having two sets of documentation, a high level quick-guide and a
deep down exploration in the same document. Part of it is as much design as is
necessary to explain things. Simple things don't need oodles of diagrams. You
better believe complex things, once figured out benefit from them.

Documentation also exists to capture the intellectual capital of your
organization. It may not be referenced or used, but as an organization matures
past 5 years of being in it's current way of business, or grows larger than
10-15 people; true, impactful turnover becomes a real issue.

------
dos1
Some time ago I was on a very large project where the hired design firm
refused to create any art assets until the IA was completely finalized. I had
never heard of an IA at the time, and in retrospect I have nothing but disdain
for the concept. I agree with the article that the true value comes from
actual design prototypes. Things people can look at, touch, play with and
ultimately determine if they like or don't like.

The design firm ended up being fired. They put two "UX" experts on our project
and they billed an amazing number of hours. After a few weeks of trying to get
a real visual prototype from them, they said we still needed to answer more
questions for their documentation. They would only let a designer work on the
project an hour or two a week, and even once they were satisfied, the art
assets were almost impossible to wriggle out of them.

