Chapter 4: Designing the Hilo User Experience

The Hilo Browser application was designed to provide a compelling, touch-enabled user experience (Ux). It is a fast, responsive, and intuitive Windows 7-based application. This article explains how the application’s user experience was designed, the overall design process, the personnel who were involved, and the key design decisions that were taken.

The Design Goals

The first step of the design process was to define the overall design goals for Hilo. While these goals were not completely immutable they helped to focus decisions as the design process progressed. At key points throughout the process the design team referred back to these goals and they helped to keep the process on track. These goals are deliberately high level and broad, to allow the design team some flexibility.

Hilo’s purpose is to allow the user to browse, edit and share photos. Using a touch interface on a computer with a touch-sensitive screen, the user should be able to use natural gestures to browse for photos, annotate and edit them, and then share them via an online photo sharing service.

The general design goal for Hilo was to develop one or more small applications that work ed seamlessly together, developed using Native C++ and the native Windows 7 libraries. Windows 7 was chosen as the operating system of choice because of the wealth of features that offer a modern, compelling, and integrated user experience. Native C++ was chosen as the language that offers maximum speed and efficiency and a close-to-the-metal access to Windows features. The theme of efficiency was further expounded by eschewing a large monolithic application in favor of several small efficient applications that work together to create a seamless user experience.

Bringing Together the Design Team

The design team was multi-disciplinary, made up of Ux designers, Ux managers, developers, and development project managers. The broad experience of the team allowed ideas to gestate and develop, it also allowed the ideas to be examined for viability from the perspective of the technology used to implement them and the development team skills and resources.

The design process was iterative, involving brainstorming sessions interspersed with periods for refinement and introspection. At key points in the process the team stepped back to examine the design according to the goals and to ensure that the team had not been distracted and deflected along a pathway that would lead away from the original goals.

Initial Brainstorming

The purpose of the early sessions was for the team to look at the application through a task-oriented lens from the user’s perspective. Through these tasks the team could evaluate alternate designs, and then refine the designs that are chosen to make sure that they work across the various tasks and workflows that the user will undertake.

The first brainstorming session brought out four generic modules, collections of related features and functionality. These modules were: organize, share, edit and acquire. From the modules, a bubble diagram was drawn to identify the interconnectivity and importance of the necessary tasks. Figure 1 shows the initial bubble diagram. The four modules are connected by arrows showing the workflow and these arrows are annotated with the task name and how many items are affected by the task.

Figure 1 Initial Bubble Diagram

This was the first iteration of the design process and helped to focus the designers on the main features of the application. By focusing on the user’s tasks and workflow, the actual application features started to become apparent. These features were not designed in isolation, but were designed in the context of user tasks which can have a subtle but important influence on the overall user experience.

The diagram shows that the application should be able to acquire items from different types of devices: cameras, USB thumb drives, or local drives like DVDs or hard disks; the user should also be able to acquire items from the internet. Once the items are obtained the bubble diagram shows that the user will be able to organize these items into collections, attach metadata to the collection, and add collections to the application item library. All items in the library can be shared with other users either through posting on an online photo sharing site or through a locally viewed slideshow. The final module on the bubble diagram shows that the user may edit individual items and add metadata, and then the edited file can either be saved, or shared, or the user can revert the changes.

This bubble diagram was just a first iteration, and as you will see the feature set changed as the design process progressed.

Creating Storyboards

The initial bubble diagram gave the overall range of potential features, how they relate to other features, and the workflow of the data. The next step was to use this information to create storyboards. Storyboards are very quick and rough drawings used to mock up key layouts and transitions, and to find potential issues with the design early on. This technique has been used in the film industry and is now becoming more common in user interface design.

One of the purposes of drawing everything out on a storyboard is to make sure that all the features and user interface items are represented. As the design goes through its numerous iterations, the features become more tightly integrated into the overall design and new relationships and dependencies are discovered.

Figure 2 is a storyboard showing the actions to create a new collection of items. On this storyboard items are first acquired from a source (like a camera or a hard disk) and are displayed in the top half of the window. The user can then drag one or more items using the Touch interface of the computer screen to the collection tray in the lower half of the window. Once a collection has been created it can be organized by sorting or by manually moving items. You can see in this storyboard that the designer has thought of each option at each stage in the story and annotated the storyboard to show these options.

Figure 2 Storyboard showing the creation of a new collection of items

Another example of a storyboard is Figure 3 which shows the actions used to edit an item. This shows that the user can use the Touch interface to crop items, annotate collections and items, and organize the collections into folders by dragging items around the window.

Figure 3 Storyboard showing the actions to edit an item

Creating Mockups

The storyboards helped the design team to bring out details of how the user interacts with the application. The design team decided to produce a Silverlight prototype using Microsoft Expression Blend 3. Expression Blend is a great designer’s tool since it allows designers to iterate and deliver on designer’s ideas faster. By using Blend, a designer can demonstrate a vision for an application and bring an application to life, adding interactivity, animation and transitions without writing code.

The mockup allowed the team to test out the user interface design in a running environment to gauge the overall experience. The value of using a rapid prototyping environment like Blend to do this is that there is little development cost required to get to something that the user can see and touch. This means that the design team could receive feedback from the usability testers with a short turnaround.

The Silverlight mockup of the user interface was created to test the interaction between the various modules in the application. One of the principal goals was to gauge the tactile response of the application – how it behaves dynamically – which is something that cannot be done in paper sketches. Figure 4 shows screenshots from this prototype. The mockup only included the user interface; there was no code behind the controls.

Figure 4 Silverlight prototype

Figure 4 shows that the mockup has a tabbed layout to give access to the main modules and then a RibbonUI control to give access to the features of the selected module. The majority of the window contains the items and collections of items. Again, this mockup is just one iteration and several mockups may be created throughout a design process as new features are developed and tested.

Performing Usability Tests

Now that the substantial part of the user interface had been designed, the design team commissioned usability tests to see if the design was natural and useable by ordinary users. The usability panel was chosen to be representative of a range of ages and experience. The panel was given a series of tasks to perform using the application. The usability test team monitored each member of the panel as they performed the tasks through videoing them and asking them to complete surveys. The panel was asked to express their views about how they used the application and suggestions to make the application easier and more intuitive to use.

Refining the Model

The results from the usability tests and the storyboarding helped to rationalize the design from the perspective of the user tasks and workflow. The next iteration was to redesign the model with these changes in mind. The design team decided to concentrate on the task of organization rather than treating all four modes equally and this lead to a refinement of the workflow. Figure 5 shows the storyboard drawn for this iteration with the use of a breadcrumb bar, a variation of the toolbar at the top, as well as icons representing "duplicate item," "delete item," and "new folder."

Figure 5 Further storyboard interaction showing the addition of the breadcrumb bar

This second model showed a much cleaner workflow, however, a few issues arose concerning redundancy of buttons and tools. Discussions over these issues led to the variation of a ribbon-based user interface (UI).

Applying Introspection

At this point the design team took a step back to get a better overall view of the project. The storyboards showed that the design had progressed into quite a complex application and that there were so many features that it would increase time dramatically to get to the application into production. Since this complexity was moving the project away from the primary design goal, that is, to create a less complex application that would excite developers, the design team decided that some simplification was necessary.

Using the lessons learned in the previous storyboards and mockups, two brainstorming sessions were scheduled on consecutive days to approve a new design. For the first session the design team decided to focus solely on the browsing experience, that is, collecting items to be edited, uploaded, and so on. Four different browser designs were sketched up for discussion in the first meeting and one design is shown in Figure 6.

Figure 6 Revised design for the browser

As a group, the design team did some storyboarding on the whiteboard and worked through some interaction examples. After discussing the pros and cons of each design, it was decided that the hierarchical carousel (right hand side, Figure 6) had the most potential. This concept was discussed and defined further, and many helpful suggestions were provided for the next iteration, such as switching from a stacking carousel into an orbital display model. After this meeting, numerous mockups were created to be shown the following day.

During the follow up meeting the design team worked through some more variations of the design, and ultimately decided on a dual orbital design with a results pane below. Items that were selected through this browser would be stored in a collection to be accessed through the other Hilo applications later on. The next step was to storyboard an example of a browsing experience to further refine the design, as shown in Figure 7.

Figure 7 Orbital browser

The orbital display represents the file structure as it is viewed in Windows Explorer. Folders in the inner orbit are selected, causing that orbit to expand to take the place of the outer ring, which disappears. The selected folder is rotated to the bottom center of the outer orbit, and any subfolders of the selected folder appear in a new orbit in the center. The bottom pane displays the non-folder contents of the active directory, and updates anytime the current location changes. The storyboard shows the animation that occurs as the user interacts with the interface.

Continuing the Refinement

At this point the main design features have emerged. The design team created some mockups to figure out the layouts of the icons, hit and swipe zones for Touch interaction, as well as other important UI elements. Figure 8 is an example of the orbital model design, and Figure 9 has an overlay showing the touch zones.

Figure 8 Mockup of the orbital model

Figure 9 Mockup with an overlay of the touch zones

The touch and swipe zones highlighted in Figure 9 show that the user can spin the orbits with a finger or mouse gesture to bring another folder to the front, and then select this folder by touching it. In this version of the model in the upper left are icons for the Home folder and for the previously selected folder. If there are more items in the current folder than can be shown in the lower pane the user can use a finger drag gesture to bring more items into view.

These mockups led to a discussion with one of the user researchers on the team on how to best maximize the usable space for the aspect ratio and the most commonly used functions. Another storyboard was created to flesh out this revised design and further mockups were created.

Figure 10 shows the revised orbital model. The model shows two orbits as before, the orbit for the current folder and the orbit for the current folder’s subfolder. The refinement in this model is that the current folder is docked on the upper left and although the orbit for the current folder is present, it is only shown at the top. This still gives the impression of the current folder being in an orbit, but by leaving out the redundant lower half of the orbit there is more space for the inner orbit, which also allows for larger icons and more room for the thumbnail pane. Additional prototyping and testing led to the addition of a back arrow for quick navigation to the previous directory. While monitoring actual usage scenarios it was found to be used more often than the history stack.

Figure 10 Orbital model refined

As the user drills down into the folder structure the bread crumb trail of folders is stacked up and docked at the upper left. By clicking on the stack the user can expand the bread crumb trail as shown in Figure 11, where each folder is shown as being in an orbit. The user can select any folder in the bread crumb trail to navigate to that folder.

Figure 11 Expanded bread crumb trail

If a user drills down to a folder without subfolders then the only orbit that can be show is the current folder. Figure 12 shows this situation, and shows that additional screen real estate is freed up and the thumbnail display panel in the lower half of the screen maximizes upwards to fill the available space.

Figure 12 Collapsed bread crumb trail with no subfolder orbit present

At this point the bulk of the design work had been completed.

Producing The Final Design

The final design is shown in Figure 13. This design is complete and shows where the user can interact with the UI and the effects of those interactions. This means that the design can now be handed over to the C++ development team.

This design presents a hierarchy of folders in a much cleaner way than previously seen in Windows Explorer. The designers have concentrated on the features that users focus on the most, the contents of the current selected folder, while still giving access to other folders by expanding the bread crumb trail.

Figure 13 The final orbital model

The iterative design process of brainstorming, storyboards, and mockups allowed the design team to test various scenarios and to optimize the user experience through efficient use of screen real estate and utilizing the natural mouse and finger gestures offered by the Windows 7 Touch interface.

Conclusion

This article discussed the process by which the user experience for the Hilo Browser application was designed. The user interface for the Hilo Browser evolved through an iterative process that involved brainstorming, storyboarding, mockups, usability studies, and incremental refinement. The next article discusses the design and implementation of the Hilo Common Library, which is used as the foundation for the development of the Hilo applications.

Next | Previous | Home