It’s kinda weird at first but you soon get used to it.

What do you think?

Now (confession time) not being an Apple aficionado I can’t really pass comment, however his general points seem quite valid. One of the founding principles of Interaction Design is to create solutions that are eminently understandable by the novice, but grow as the user become more competent then expert.

So, we aim to make the initial state as simple and as closely aligned to the user’s mental model as possible. Simplicity does not mean lack of functionality (which I think could be the issue with Apple), it means a fast initial learning curve and consideration of the number of concepts a user needs to understand.

However, the product should have a built in path to higher proficiency, facilitating enhanced functionality, high speed interaction and minimal application feedback as the user requires it.

Tognazzini seems to be implying that Apple software products are well suited to ‘Leading the novice’ but fall short on ‘empowering the expert’ . Certainly, in the past, Apple have not really carried out much in the way of design research. Could this be at the heart of some of these issues?

Do any of you Apple users out there think Tog’s argument is justified?

As promised I have put down my thoughts from the session. The slides I presented are shown below:

(View SlideShare presentation or check out the buzz on Twitter)

These might be a tad generalised, but here are some rough notes I took immediately after the session:

• The first point of discussion was around ‘scope creep’. We discussed the use of the MoSCoW (Must, Should, Could, Would) method of requirements gathering and getting developer estimates based on ‘story cards’. But the consensus seemed to be that scope creep is more a project management issue than a documentation issue, and that it’s taken care of early in the project during requirements gathering.
• I was glad to hear that those using MoSCoW weren’t just creating huge requirements specifications documents, but rather using lightweight methods to capture the output of “butcher’s paper sessions” and workshops, rather than “death by Word”. Similarly, workshops are being used to output actionable user stories.
• In terms of process, most of the audience seemed to be writing a brief and giving that to an agency to do creative “concepts” (or “mocks” or “flats”) then moving into production.
• In terms of the forms of documentation used, most of the audience said they do wireframes and sitemaps, few are doing prototyping (paper or otherwise).

• One of the most interesting points of discussion was around the level of fidelity required for design documentation. If it’s sketchy and doesn’t look finished (or right) then clients and stakeholders won’t accept it. They’re “very visual”. But at the same time, if it’s more finished or realistic looking, you run the risk of them thinking it’s the real thing, and it’s probably not going to be right.
• I think that sketching can help with this, because it’s difficult to mistake a sketch for the finished product. But someone commented that that would require the reader (or the documentation) to use some imagination, which can be tricky. Perhaps a big factor here is the level of maturity of the organisation in terms of web design?
• Another factor in determining what documentation is used is the available skills and resources. For example, Powerpoint is used for prototyping and wireframes because it’s familiar and available, but not well suited to either job (you have to “grapple with Powerpoint”). Axure too hard to learn, only two had tried. Similarly need skills to use Dreamweaver etc for prototyping.
• I thought it was interesting that some people didn’t want to be involved in group sketching or participatory design sessions. They’re hiring consultants or specialists to come up with “concepts” and designs, so they don’t want to restrict or narrow them too much. I had suggested such sketching sessions might be a way of ensuring requirements are being included early on, and getting buy-in from stakeholders.
• The choice of documentation depends not only on your skills but on those of the reader. For example, using Flash to convey user personas (as had been mentioned in a previous session) won’t work if people don’t have Flash player and don’t have admin rights to install it.
• In terms of conclusions, some of the things I took away from the session were:
  1. Multiple types of documentation is usually the be best
  2. One size doesn’t fit all, knowing your audience (for the doco) is key

The audience seemed to be predominantly business and marketing folks, based on some questions I asked but also from various comments throughout the day. Only one or two people said they were designers, a few more for ‘UX geeks’ (mostly people presenting at the conference) and none for developers. This might explain the fact that there wasn’t a lot of talk about design documentation, and a greater focus on requirements gathering and stakeholder communication.

Furthermore, only a few (ie 4) said they were currently developing web 2.0 style websites or Rich Interactive Applications (RIA). So again, this topic probably wasn’t as suitable for this audience as it could have been. Not that their focus or concerns are not valid, but what I headed into the session to discuss would probably have been more suited to UX and design practitioners.

Special thanks to Werner Puchert for letting me refer to his low-fi doco case study, which contains some excellent examples. Similarly, thanks also to Chris Khalil for letting me discuss the work he did on redesigning the News.com.au home page.

Please do leave a comment below, whether or not you were at the conference.