Audi casestudy jameskalbach (1)


Published on

Published in: Technology, Design
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hello My name is Jim Kalbach. I‘m an IA with Razorfish, Germany in the Hamburg office. I‘d like to talk to you today about the project we delivered for Audi, the German car manufacturer. The project encompasses, their global brand portal, and, the regional site for Germany.
  • I don‘t want to tell about the whole project from beginning to end. It was a large project that took over a year and had many ups and downs. Instead I want to focus on three aspects of the projects that are of interest to this community. Our approach to creating schematics Jumping boxes, or an automated layout technique that fits pages into various browser window sizes The results of a study conducted during the project that directly compared a right-hand navigation with a left-hand navigation.
  • We‘ve identified a problem with project work that I call Traceability . By this I mean the ability to trace a concept, idea, element, or artifact across a set of documents. We don‘t work with any all-encompassing document management tools (e-documentation) such as Rational or something similar. Documents and deliverables end up being separate and independent from one another: There are owned by different people, reside in different physical locations, and are in different formats. Often by the end of a project, updating something as simple as a navigation label requires updating half a dozen documents or more. From talking to many of you, I already know this is a typical problem common to the industry. This is in efficient and leads to version control problems .
  • We looked to Adobe GoLive to help us address this problem. Our ultimate goal was to achieve a true convergence of deliverables. The initial plan was to integrate IA, content, and design deliverables in one common format. We even wanted to write the page specifications directly in GoLive in HTML format . GoLive offers several advantages Sitemap and schematics are linked one to one Global updates are possible using components Working with a WebDAV server I A s could check schematics in and out, thus offering version control. The client was also able to see the schematics „live“ online through the project extranet GoLive is available for the PC and the MAC, and the output is simple HTML. No conversion to PDF, for example, is necessary – all you need a web browser to view the documents.
  • Here a screen shot of GoLive. You can see the sitemap and schematics are created in the same environment . Clicking on the „A4“ page in the site map opens the schematic for that page. Some information is shared between the sitemap and schematic: Page name File name Page number Updating one updates the other. [ Live demonstration ]
  • There were, of course, some disadvantages to GoLive : This .site file that controls the site got really big, really quick, which was hard to handle We experienced s ome crashes and loss of work The sitemap tool is simple and doesn't allow a great deal of control concerning the appearance of the sitemap. GoLive didn‘t get the buy-in from the whole team and was used primarly by IAs only. A key feature missing from GoLive 5 is a database to manage content and terns. From the IA perspective, however, GoLive worked well and met our expectations, but still isn‘t the right tool. Though no one software will solve our problems, an appropriate IA tool would help. Unfortunately this doesn't exist.
  • We needed to address the common web problem that users have different browser window sizes. There were two reasons for this: Developing pages for one fixed size is fundamentally inappropriate for web design that ignores the basic flexibility of the medium. Our pages have a right hand navigation that must be visible without horizontal scrolling. Therefore the layout had to expand and contract to fit variable browser sizes.
  • There are many ways to achieve flexible page layouts, but we went for what can be called an automated layout . Essentially we build „smart“ pages that are able to detect the size of the browser window and serve up the right layout size automatically. We essentially had three sizes – small, medium and large. This solution fulfilled CI constraints . The page designs have a grid that aligns all page elements horizontally and vertically. With an automated layout solution we were better able to control the alignment of page elements. The solution is highly technical and speaks to the Audi slogan „Vorsprung durch Technik“ or Advancement Through Technology. So, we were branding with layout and with this technical solution.
  • Three sizes: 640x480 800x600 1024x768 Show: and other pages...
  • 1. This proved to be more challenging to implement than initially thought. 2. It is unknown if there are any usability implications. We don‘t believe so, but have no proof. 3. The automated layout solution is not needed for all pages and page types. With an increase of alternative browsing devises on the horizon, the continuum of viewable browsing sizes will only expand. Never before has the demand for flexibility been greater. This was a valiant attempt to address this issue and we learned a great deal from it. However, it was very complex to implement and I would caution anyone considering such a technique.
  • We wanted to set Audi apart from its competitors, who general have conservative page layouts with the navigation on the left of top. The idea was to place the navigation the right side of the page. Again, we saw this as part of the Audi brand – that they are innovative While rationalizing this to ourselves and to Audi, we noticed that there are many (theoretical) advantages to a right navigation Fitts‘ Law suggests a better interaction between the navigation and the scrollbar In western cultures we read left to right . Therefore there should be a greater focus on content with a right navigation Finally, we simply believed that visitors to the Audi sites would not be annoyed or disturbed by a right-hand navigation in any way.
  • We tested extensively with our external testing partner Two clickable prototypes of about 10 pages each were constructed – one with a left navigation, the other with a right navigation 64 users were broken down into two groups of 32 each. This was a very large sample and not a sample of convenience: participants were recruited to fit our user scenarios and fit Audi‘s target group to a T. The test was divided into three parts : In a human performance test, completion time for six tasks were timed with a stopwatch. We also analyzed the eye movement of the participants to see where the tend to look on the page. Finally, we simply asked users directly what they thought about the right-hand navigation
  • Our hypothesis for Part 1 was that there would be a significant difference in task completion time for the first task; However by the last task there would be no significant difference. We expected that users would need to use the site a couple of times to learn the pattern of interaction. We were OK with this as well as Audi. If we could prove this to be true, we‘d go ahead and launch a site with a right-hand navigation.
  • What we observed was surprising : There was no significant difference in completion time between the two navigation types for ANY task! In fact, the right hand navigation started to perform faster than the left in later tasks. Note that the graphs shows actual times
  • Then we looked an the eye movement patterns of users. Instead of relying on the traditional method that makes use of expensive equipment and headgear, we used a method developed by a small start up in Hamburg. This method asks users to rapidly coordinate clicks with where they look. We expected that there would be more clicks – and therefore more attention – in the content portion of the screen with the right-hand test condition.
  • We found just that: people tended to focus more on the content side of the page with the right navigation than with the left navigation. The above screenshot shows the clicks of one test participant. You can also generate a „ heatmap “, which shows patterns across users.
  • At the end of the test we asked a series of questions that addressed the central question „do you like the right-hand navigation?“ Overall, users are apathetic towards the navigation position . Most didn‘t notice that the navigation was on the right and we directly asked, they didn‘t care. Seven people even preferred the right navigation, while only 2 disliked it. _________________________________________ From this test with the Audi site, users didn‘t show any problems using the site objectively and there were no major subjective problems as well. This does not mean that everyone should run out and a get a right-hand navigation. But it does show that we care more about such design details than our users. Using a navigation other than on the left is not a taboo, as we are lead to believe.
  • I should also mention that we conducted a usability test later in the project with a full, functional prototype. We saw no problems using the right-hand navigation and people responded positively to the visual design. Only 1 from 25 noticed the right-hand navigation and commented on it.
  • Here are some thoughts as to why we saw what we saw : Though there is research about expectations of the location of page elements in a layout, these researchers don‘t correlate breaking these expectations with actual usability (see: Michael Bernard and Jakob Nieslen). Don Norman‘s concept of affordance – the perceived properties of a thing that determine how it is to be used – seems to be more important in web layout than conforming to standards. With the Audi site it is clear what is navigation and what is not. Users can build a pattern of interaction with the site immediately. By „immediately“ I mean at the pre-attentive level or within a fraction of second. There is a large body of visual perception theory that supports this argument. Our findings clearly show users have no problem to distinguish the navigation and make generalizations about ist function. They then had no difficulties using the site.
  • Questions?
  • Audi casestudy jameskalbach (1)

    1. 1. Case Study: Audi
    2. 2. <ul><li>1. Schematics (wireframes) </li></ul><ul><li>2. „Jumping Boxes“ </li></ul><ul><li>3. Right vs. Left Navigation </li></ul>
    3. 3. Schematics <ul><li>D ocuments separate & independent </li></ul>Problem: Traceability <ul><li>Changes & updates inefficient </li></ul><ul><li>Version control problemati c </li></ul>
    4. 4. Schematics Solution: Adobe GoLive <ul><li>Sitemap and schematics linked 1:1 </li></ul><ul><li>Components = modular construction </li></ul><ul><li>WebDAV server </li></ul><ul><ul><li>concurrent work on schematics </li></ul></ul><ul><ul><li>remote access by client </li></ul></ul><ul><li>Cross Platform: PC and Mac; HTML </li></ul>Convergence of deliverables
    5. 5. Schematics
    6. 6. Schematics Disadvantages <ul><li>Site file grew to 30+ mb </li></ul><ul><li>Unstable, crashed </li></ul><ul><li>Sitemap tool is suboptimal </li></ul><ul><li>Didn‘t get team buy-in </li></ul>Overall GoLive met our expectations, but is the wrong tool for the job Underscores need for an IA tool
    7. 7. <ul><li>1. Schematics (wireframes) </li></ul><ul><li>2. „Jumping Boxes“ </li></ul><ul><li>3. Right vs. Left Navigation </li></ul>
    8. 8. Jumping Boxes Users surf with different window sizes Problem: Variable Browser Sizes <ul><li>On e screen size  W eb design </li></ul><ul><li>Right navigation must be visible </li></ul>
    9. 9. Jumping Boxes Three page layouts offered – S, M, L from 640x480 to 1024x768 Automated Layout <ul><li>Fulfilled CI constraints </li></ul><ul><li>Brand: “Vorsprung durch Technik” </li></ul>
    10. 11. Jumping Boxes Disadvantages <ul><li>Technically difficult to implement </li></ul><ul><li>Usability problems? </li></ul><ul><li>Not needed for all page types </li></ul>A complex solution for a simple problem
    11. 12. <ul><li>1. Schematics (wireframes) </li></ul><ul><li>2. „Jumping Boxes“ </li></ul><ul><li>3. Right vs. Left Navigation </li></ul>
    12. 13. Right vs. Left Navigation Right navigation = Audi as innovator Challenge: Competitive Difference <ul><li>Sm oother interaction with scrollbar </li></ul><ul><li>Greater focus on content </li></ul><ul><li>Subjectively accepted by users </li></ul>
    13. 14. Right vs. Left Navigation 2 prototypes: 1 left & 1 right navigation 64 users: 2 groups External Test: <ul><li>Part 1 – Six tasks were timed </li></ul><ul><li>Part 2 - Eye movement analysis </li></ul><ul><li>Part 3 - Interviews </li></ul>
    14. 15. Right vs. Left Navigation Time Tasks 1 2 3 4 5 6 R L Significant Part 1 - Hypothesis
    15. 16. Right vs. Left Navigation Time Tasks 1 2 3 4 5 6 R L No Significance Part 1 - Results
    16. 17. Right vs. Left Navigation Method: User rapidly coordinate clicks with where they look Part 2 – Eye movement <ul><li>Hypothesis: </li></ul><ul><li>right navigation > focus on content </li></ul>
    17. 18. Right vs. Left Navigation Results: Stronger focus on content
    18. 19. Right vs. Left Navigation Do you like the right navigation? Part 3 – Interview : | : ) : ( 7 23 2
    19. 20. Right vs. Left Navigation „ Normal” methods with 25 participants Subsequent Usability Test <ul><li>Corroborated findings of first test </li></ul><ul><li>No difficulties with a right navigation </li></ul><ul><li>Positive subjective response </li></ul><ul><li>Only 1 commented on right navigation </li></ul>
    20. 21. Right vs. Left Navigation Conclusions <ul><li>Users are ambidextrous in terms of navigation position </li></ul><ul><li>Consistency and learnability </li></ul><ul><li>People expect that websites vary </li></ul><ul><li>Interaction given by design and layout, not prior expectations (Affordance) </li></ul>
    21. 22. Thank You