Write the manual first.

1. Aron Grinshtein 1.5.09 / 3pm

   Great idea. Simple and too the put. Your manual for “using the manual” is a good manual. :-)
2. Alexander Khodyrev 1.5.09 / 5pm

   Why people buy digital watches is beyond me.
3. David Bolton 1.5.09 / 5pm

   I bug digital watches because analog clocks are difficult to read. The prominence of the minute hand over the hour hand is practical but confusing and illogical. The need to multiple by 5 to get the exact minutes is an additional mental strain for the user.

   Since I read the time far more than I set the time, digital wins out. That doesn’t mean I enjoy setting the time on my digital watch.
4. Aza Raskin 1.5.09 / 7pm

   @David Agreed fully. In terms of efficiency, digital watches win on output interface; analog watches win on input interface. T’were only there a mix between the two.
5. Jimmy 1.5.09 / 9pm

   Why doesn’t some just stick a crown on a digit watch just like an analog watch. When you turn it it changes the time on the digit watch. Is this really that hard? Then you would have the best of both worlds.
6. Aza Raskin 1.5.09 / 9pm

   @Jimmy Timex did a watch just like that for a short period of time. Then, when I went to look for it again, it seems to have been discontinued.
7. Alex Iskold 1.6.09 / 12am

   Aza,

   So true! I think teaching software engineering at NYU for 5 years really made me understand its intricacies.

   What is common between teaching and manuals is that in both cases you need to systematize your thoughts and create complete description of the class or a product.

   Alex
8. Jesse Andrews 1.6.09 / 2am

   Great Post! But is “Write the manual first” always possible?

   When creating something new, the process of building can inform the interactions when doing exploratory programming. Your ubiquity for mice prototypes being a great example where you might not know the “how” for the interactions even when you know the “what”.

   Perhaps I’m interpreting the title of your post incorrectly since the body doesn’t imply an ordering, but that you think through how to teach users while you are building/designing.
9. Jan-Christoph Borchardt 1.6.09 / 4am

   There is a problem though: the features differ.

   On an analog watch, you just set hours and minutes. For the digital one, the extra instructions which fill the page are for timezone, second, year, month, day, and even the time format.
   You cannot accomplish that with one (or two) crowns while maintaining ease of use.

   But regarding manuals: the best product is that which does not need one. No one likes to read long instructions, even if they are beautifully information designed. (Although I admit that it is often insightful.)
10. Henrik N 1.6.09 / 4am

    I agree digital watches read better. When I look at an analog watch, I find myself translating it to digital anyway. Though analog makes it easier to visualize at least short passes of time, like when you have to leave in ten minutes.

    While turning the crown is really simple, intuitive and easy to describe on an analog watch, on a digital watch the mapping isn’t as direct, so presumably the user would mostly understand it through their experience with analog watches.

    Also, the worst-case scenario (changing by 6 hours if it turns both ways, or 12 hours if it only turns one way) can be a bit time-consuming.

    A digital interface can be made pretty simple and intuitive (hour plus and minus buttons, minute plus and minus) but it’s a tradeoff against watch real estate and simplicity/elegance.
11. Henrik N 1.6.09 / 4am

    I’ve read about an alarm clock that is voice-controlled, so you can do something like “set the time”, “eight forty-five”. That’s an interesting interface, too.
12. Havvy 1.6.09 / 11am

    Great article. You have a typo though: “Remember, though, it’s not the their fault.” The “the” is not needed.

    I’ve been trying to write a manual (wiki type) for a Web IRC client, and it does get tough to write something that you think newbies will understand, acts as a reference for more experienced users, and it does get difficult. Still, it increases my knowledge of it.
13. Robby Macdonell 1.6.09 / 9pm

    Writing a manual totally feels right as a part of the design and exploration process, both as a sanity-check for complexity and a way to make sure a feature is relevant to a real human need. I can see having a coherent man page as a requirement before any production-code is written (or whatever the equivalent is for non-software products).

    But I’d agree with what Jesse said above, I’m not so sure about the “write first” part implied by the title. Writing an end-user document as a way to define features seems a bit problematic.
14. Kevin 1.8.09 / 9am

    I commented on my own blog, I don’t think it has its place here, but you can read it if you want :

    http://kevinbongart.net/blog/2009/01/08/write-the-manual-first/
15. Pavol Vaskovic 1.23.09 / 3am

    Aza, I’m interested in your response to Jesse Andrews.

    It is also my experience, that writing software documentation is an excellent way to discover all the conceptual inconsistencies and cognitive hard edges of the program. If you can’t explain it easily, that its definitely not easy to use in practice.

    But I was also in position described by Jesse, designing a new UI for a product. Whiteboard concepts and paper prototypes got me only so far… Sometimes it is necessary to build the real thing and iterate few versions, to get excellent results. I’m not sure how the “manual first” rule applies there.

All material copyright Aza Raskin. But you can have the color magenta.

Entries RSS Comments RSS