An interactive discussion session presented at the "Enhancing Online User Experiences" conference in Melbourne, Australia. November 13th 2008.

1. Documenting for Interactive Websites
@ Enhancing Online User Experiences
14 November 2008

2. A bit about me
• Senior Experience Architect @ NDM
• Previously:
– Intranet and information management consultant
– Information Architect
– Team leader and ‘solutions architect’
– Front and back-end web developer
– Electrical and Computer Systems Engineer
• Wide variety of experience in designing and
building traditional websites as well as 2.0/RIA

4. Introduction
• Highly interactive websites/apps present new
challenges to web designers and UX pros
• “Web 2.0” and Rich Internet Applications (RIA)
– Higher levels of interactivity
– Breaking away from the “page model” web
– Built using Flash, Flex, AJAX, Air, Silverlight, Java etc
• Plus the new agile ways of development
• So, do we need all this documentation?
• Do we need more?
• Image credit: http://www.flickr.com/photos/frankjepsen/1355329357/

5. Compare this…

6. Web 1.0: the page model
• Click a link go to a page
• This is the basic model of the web
• Typical of most websites, even in the age of Web 2.0
• UX for this kind of interface is well understood
• We can design these and document those designs
• Image credit: http://en.wikipedia.org/wiki/Rich_Internet_application

7. …with this

8. Interactive web apps
• This is a new model of interaction
– Clickable, dragable, contextually aware UI
– Dynamic and active rather than passive
– More like a desktop software interface
• UX for this kind of interface is not yet well
understood
• Nor is how to document their design
• And this is a relatively tame example
• Image credit: www.moo.com/products/minicards.php

9. …or this

10. Interactive news website
• Many different types of interaction
– Drag’n’drop
– Expandable elements
– Animated transitions
– Conditional behaviour
– Active user feedback and interactive tour
• These are relatively simple examples, designers and
developers are building cooler, more complex apps and
sites all the time
• How do you document this design?
• Image/video credit: www.news.com.au (home page recently redesigned)

11. Key challenges
• Communicating highly interactive designs
• Evolving this along with the designs
• Iterating rapidly (in step with agile)
• Project management when the end
product is not precisely known

12. Site maps

13. Site maps
• Probably the most common form of
documentation for websites
• Capture the structural aspects of a website
• Easily become too complex for their own good
• They don’t handle dynamic aspects well
• Better for content sites with strict hierarchy
• Image credits:
– (left) www.treith.com/ia_presentation/16sitemap.html
– (right) Step Two Designs

14. Wireframes

15. Wireframes
• Along with site maps, almost ubiquitous
• Sadly, they are often mis-used
• Lack flexibility and can be very time consuming
• Not great for interactivity or small changes
• Better for ‘page model’ websites
• Of course, your mileage may vary
• Image credits:
– (left) Step Two Designs
– (right) www.gdoss.com/images/lmf_paper_prototype.gif

16. Other forms of documentation

17. Other forms of documentation
• Of course there are many other forms of
documentation that can (should?) be used in a
web site/app design project, eg:
– Personas (maybe use ‘design comics’)
– Scenarios / user stories
– Task matrices
– In fact any artifact from research
• I haven’t focused on these today because they
aren’t directly related to the design. Or are they?
• Image credits:
– (left) http://www.designcomics.org/
– (top right) http://toddwarfel.com/archives/the-task-analysis-grid/
– (bottom right) www.neuralmatters.com/Reference/Buzan/MindMap.gif

18. We are in need of an update

19. We are in need of an update
• “Traditional” methods may not work so well any more
• Particularly in terms of documentation
– New ways have surfaced and are entering the ‘mainstream’
– Types of documentation that
• Lend themselves to greater interactivity
• Faster and more easily produced and updated
• Rapid iterative prototyping; see it working then refine it
– Save time and effort on documentation
• Image credit: http://www.flickr.com/photos/nakedcharlton/72041049/

20. Hybrid documentation

21. Hybrid documentation
• Hybrids of existing forms of documentation
• Attempt to capture the higher interactivity
• Whilst maintaining familiar look and tools
• Image credits:
– Wireflow (top left) http://nform.ca/tradingcards/2008_19.jpg
– Wireframe storyboard (bottom left)
thinkingandmaking.com/entries/art/36/wireframe-storyboard.gif
– Task flow for an Ajax login component (right)
www.uxmatters.com/MT/archives/images/rias-figure%205.png

22. Storyboards

23. Storyboards
• Borrowed from movie and games
production
• Excellent for interfaces with complex
states and sequences of events
• Sketching is seeing a big revival
• Can be cheap, quick and info laden
• Image credit: http://fromthedogbox.files.wordpress.com/2008/05/landing_image.jpg

24. Paper prototyping

25. Paper prototyping
• Early (in the process) prototyping technique
• Typically using print-outs of wireframes or
storyboards
• Easy to produce and update
• Works well with task based usability testing
• Image credit: www.nngroup.com/reports/prototyping/prototype_tabs.jpg

26. Not just documents but methods

27. Not just documents but methods
• Not only are the websites more interactive but
also how we go about building them
• Agile development methodologies
– Design is shifted earlier in the project
– More iterative, deliberately less documentation
– Taken the tech world by storm
• Beyond documentation, our approach may need
to change also
• Image credit: http://www.flickr.com/photos/psd/1347700815/

28. Methodology affects documentation
• With paper prototyping you can see that there is a strong
connection between doco used and the way we work
• Going hand-in-hand with the agile approach and less
documentation is:
– More (and earlier) prototyping
– More usability testing
– Rapid iteration (fail faster and evolve quicker)
– More access to users
– Less inertia
– Lower cost techniques

29. Advanced paper prototyping

30. Advanced paper prototyping
• The technique can be extended into quite
a sophisticated testing methodology
• Still quicker and cheaper than hi-fi
• Video credit: Werner Puchert www.youtube.com/watch?v=oITeUEjrY3Q
• Related case study: http://fromthedogbox.sapaintball.info/2008/08/16/from-
humble-low-fi-prototype-to-live-online-campaign/

31. Low-fi prototyping

32. Low-fi prototyping
• Quick and dirty RIA prototypes
– Hand-drawn sketches
– Digitised via camera
– Imported into Flash for addition of animation
and interactivity
• Can be more convenient than paper
• A video such as this might in itself become
a design document
• Video credit: Werner Puchert www.youtube.com/watch?v=OT3yYXkafy8

33. More low-fi prototyping

34. More low-fi prototyping
• Explanation of method to be used, part of
a pitch to senior stakeholders
• Created before the ‘advanced paper
prototyping’ video
• Video credit: Werner Puchert www.youtube.com/watch?v=y4Wwnt9KIjg
• Related case study: http://fromthedogbox.sapaintball.info/2008/08/16/from-
humble-low-fi-prototype-to-live-online-campaign/

35. Interactive questions

36. Interactive questions
• Uservoice.com was used to collect and
prioritise today’s topics for discussion
• Initial suggestions were supplied by myself
and the conference chair
• But don’t let this stop you, suggest your
own questions as we go!

37. Firstly, a bit about you
• Who here is creating Web 2.0 or RIAs?
• Who’s a visual designer?
• Who’s a developer?
• Who’s a producer or project manager?
• Who’s a UX geek?

38. Taming scope creep
How do you deal with scope creep when
developing interactive websites and web
apps?
What documentation helps with this
problem?

39. Responding to the broad and
various client expectations
When developing interactive websites and
web apps, there is often an air of magic in
terms of client expectations regarding
what is possible and what the product
will be able to do (despite the
requirements that are actually recorded).

40. Challenges for design
documentation
What challenges do you face in terms of
documenting the design of interactive
websites and web apps?
(eg RIAs, web 2.0)

41. Evolving documentation to meet
the challenges
How has the documentation you use had to
change to better fit the types of
projects/products you do?

42. Challenges for project
documentation
What challenges do you face in terms of
documenting plans and progress for
projects that aim to develop interactive
websites and web apps?

43. Further reading
• Sketching User Experiences
by Bill Buxton ISBN: 0123740371
• Communicating Design
by Dan Brown ISBN: 0321392353
• Documenting the Design of Rich Internet
Applications: A Visual Language for State
by Richard F. Cecil
www.uxmatters.com/MT/archives/000251.php
• The Guided Wireframe Narrative for Rich
Internet Applications by Andres Zapata
www.boxesandarrows.com/view/the_guided_wire

44. Further questions?
• Patrick Kennedy
• Email: patrick.kennedy@newsdigitalmedia.com.au
• Blog: www.usit.com.au
(I’ll blog my thoughts on today, feel free to comment or
continue the discussion further)
• Slides: www.slideshare.net/PatrickKennedy

45. Case study: news.com.au
• Conceptual sketches
• Rough wireframes (part screengrab part Visio)
• “Proof of concept” prototype
• Collaboration between UX, design, dev
• Final wireframes
• For more information see post by Chris Khalil:
www.usit.com.au/2008/10/27/relaunch-of-new-newscomau/

46. A quick audience poll
• Who is using…
– Wireframes?
– Storyboards?
– Paper prototypes?
– Low-fi prototypes?
– Hi-fi protptypes?
– Long beta?
• Something else?

47. What decides the method you use?
• Cost?
• Skill in using various tools?
• Time taken to prototype?
• Comfort with prototypes in business?
• Culture of team?
• How agile the team is?