Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Audi Relaunch Case Study 2002

by Jim Kalbach on Jul 22, 2012

917 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

Statistics

Likes: 0
Downloads: 1
Comments: 0
Embed Views: 0
Views on SlideShare: 917
Total Views: 917

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 Audi.com, their global brand portal, and Audi.de, 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: http://www.audi.com/de/de/erlebniswelt/unterhaltung/audi_bildschirmschoner/audi_bildschirmschoner.jsp 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 Relaunch Case Study 2002 Presentation Transcript

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

Audi Relaunch Case Study 2002

by Jim Kalbach on Jul 22, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Audi Relaunch Case Study 2002 Presentation Transcript