Mobile 2.0 Documentation Strategy

listapp-imageAt the Euro IA Summit in Amsterdam this year I presented a talk on Mobile 2.0 Documentation Strategy. Fundamentally, it’s a 5-step process:

1. Mock-ups
2. Flow charts
3. Component Drawings
4. Tables
5. Further Descriptions (clarifying issues)

Beyond that, it’s nice to have some examples and instructions, which you can find in the attached PDF.

Presentation: mobile-20-ui-documentation-strategy-weiss

Advertisements

2 Responses to “Mobile 2.0 Documentation Strategy”

  1. Bryan Rieger Says:

    Hey Scott, thanks for sharing!

    I’ve got one question about the ‘Component Drawings’. I think these are vitally important in order to provide the development team some idea as to how the designer envisions the components fitting together, but I’m a bit confused as to how vague (or detailed) to make these.

    The example you’ve provided shows very high-level container components (title and list containers). Do you feel there would there be any benefit in providing more detail as to how the individual list elements (including states) might break-down? I’d like to avoid dictating how an engineer might implement a given component, but I’d often like to provide a little more detail about how I’d like to see a component work.

    Lately, I’m starting to lean towards breaking them down a little further – but I’m not 100% sure if that’s a really good idea.

    Cheers,

    Bryan

    • handheldusability Says:

      Bryan, thanks for your comment and question. I try to keep the components to fewer than ten items, but that said, there’s no reason why you can’t have multiple levels of component drawings, going into greater and greater detail. For example, breaking down the B component into B1, B2, B3, B4, etc. in a subsequent box. Further, within a component drawing, if you want to show greater detail, you can show the outlines of the sub-components in faint, light-bordered boxes.

      The whole idea is to simplify the documentation process both for the documenter and the developer. And the guidelines are meant to be just that–guidelines and not rules. The only really important thing to remember about the components is to keep them to one or two letters/digits. If you name the components, the tables become unruly to manage, with the left-most column getting eaten up by component labels.

      Happy documenting!
      -scott

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: