The Documentation Dilemma

I don't think you can keep designers and developers in sync for mobile platforms.<p>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.<p>Maybe eventually the tools will improve, but iPhone and Android are not web enough to be so rapid.

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 <i>see, feel and interact</i> and they won't be "done" until they can do that.<p>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.<p>Here are a few reasons why:<p>- Clients will try the prototype in configurations/devices that you don't have and can't test without employing an army of testers.<p>- Clients see conflicts with their business logic and your understanding of their needs before the roots are too deep.<p>- You can actually write articulated unit tests, framework and data structure based on something you know inheritably works.<p>- 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.<p>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.

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.

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.<p>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.

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

Documentation isn't the issue.<p>Learning the correct amount, type, and depth of documentation that is fruitful is key.<p>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.<p>Documentation exists in two forms:<p>- for those operationally familiar with a system.<p>- for those not familiar with a system.<p>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.<p>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.

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.<p>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.