ContextualInquiry-Group:Jigsaw
From CS160 User Interfaces Fa06
Group Member Contributions
Yen Pai - Two interviews, interview write-ups, UI design, final UI diagrams
Siu Pang Chu - Two interviews, interview write-ups, UI design, contextual analysis questions
Scott Friedheim - Two interviews, interview write-ups, UI design, problem overview, solution analysis
Patrick Rodriguez - Two interviews, interview write-ups, analysis of tasks, UI design
Target Users
Because our original group proposal dealt with visual prototyping, especially Web UI prototyping, we focused our interviewee search efforts on experienced Web UI and software GUI designers.
Interviewee Marvin Doe: Marvin Doe is an experienced Web/UI designer with a graphic design background and 7+ years of professional experience, currently working fulltime at a video game company as well as maintaining a freelance project designing an interface for an audio plug-in module. At his fulltime job, Marvin manages a Web site that serves as both a marketing site and an online community hub for gamers.
Interviewee John Doe: John Doe is an UI architect at a mobile entertainment company based in Southern California. He comes from a graphic design background with experience in online media applications and has been doing UI architecture for 5+ years. Because of his distance, we had to conduct this interview by phone.
Interviewee Jane Doe: Jane Doe is an HCI PhD student here at Berkeley. She has experience developing software interfaces and is currently working on a speech driven interface which controls office lighting. Because of her position, she works directly with end users on a design to solve a problem. Then, after cleaning up the design, presents the design to her superior for approval; this makes her an ideal interviewee for our group.
Interviewee Oliver Doe: Oliver Doe is an experienced UI designer with over 7 years experience, working for a professional services company that deals with large corporate clients. He has participated in a number of projects as a designer, information architect, and design team lead.
Interviewee Don Doe: Don Doe is a UI consultant who works with many large software companies on a wide variety of projects. He has worked in the field for more than 10 years.
Problem and Solution Overview
In light of the recent contextual interviews that our group conducted we found that the most common problems in UI prototyping were the following:
- Getting prototypes ready for presentations for design approval is a process requiring many steps.
- No quick method to improve upon the initial designs requiring the initial designs to be recreated elsewhere.
- A lack of methods to achieve clarity of the design between user and designer so that miscommunication does not occur.
- There needs to be a tool to specifically build what designers wish to accomplish, currently a myriad of applications or used to achieve an end result.
- A quick method of incorporating the initial design sketches into a digitally organized format.
- Allows rapid prototyping in the Jigsaw software that can be used to provide design feedback to users.
- Provides a tool for organizing UI sketches and flow charts them providing a convenient method in which to present the designs.
Our solution, Jigsaw, is aimed at providing a more rapid prototyping tool for GUI designers. Jigsaw is geared toward the beginning stages of designs and provides solutions to the above problems. Jigsaw provides:
Contextual Inquiry Interview Descriptions and Results
Interviewee Marvin Doe
We met Marvin Doe at his home office, after the regular workday. He had just been getting ready to work on his freelance contract, a remote project with a audio software company based in Canada. The project involved designing the interface for an application designed to play customize recordings for large public shows.
As we were more interested in the Web UI design process, we started off by discussing some previous Web-based projects, specifically projects that had some element of paper-based prototyping. Marvin described a project where paper was used in the initial conceptual stage but mostly for communication of ideas between members design team. By the time, the project reached a user test audience or external approval, the prototype had reached what would be considered high-fidelity: linked HTML mock-ups. Marvin felt that for many Web projects, the principles of interaction were pretty clear and the need to test low-fidelity prototypes was an extra step that did not hold enough utility for the given time commitment.
Next, Marvin walked us through his freelance project, giving us some background on the software functionality and showing us his current progress. Since he was in the middle of the project and we were primarily interested in the concept and low-fidelity prototyping stage, we asked him to take us through how he first approached the project.
Marvin said that when the project first started, he was shown the existing version in use and a set of required functionality. He began to research other interfaces in product realm, compiling a list of "plagiarized" ideas and interface elements as necessary. He then drew up a low-fidelity prototype, a layout, or what he called an "outline of boxes." Next he began to test elements within each box.
The prototypes would be sent to the Marvin's client in Canada, who would then share them with existing customers of the software application. And the interface would be refined through iterations of this review process.
Marvin uses Photoshop almost exclusively for prototyping. He finds it efficient because he is proficient in Photoshop but openly admits that he is digitically inclined and that many designers he has known will use paper to sketch out ideas. In the case of his freelance project, Marvin stated that he can only use Photoshop because his collaborators are in Canada and there is often a communication lag of several days; thus, being able to send relatively high-fidelity images back and forth is important to efficiently reaching consensus on designs.
An important point that Marvin brought up was that in many projects, one is rarely asked to design something completely new. Often times, a previous version exists or a set of required functionality has already been defined. And in such situations, it is important to be able to work within the confines while being able to "argue" or advocate for changes. A typical way to advocate one's own ideas, according to Marvin, was to suggest and illustrate a variety of options, comparing/contrasting: the important thing is the ability to rapidly edit a prototype.
Interviewee John Doe
We spoke with John Doe over the phone and asked him to give an overview of how he approaches a new project. John is an avid user pen/paper and immediately stated that he began any new project by sketching out a site map, flow diagrams, and what he called “an inventory of pages”- a set of wireframes for the Web site.
John shares an office with two graphic designers and when brainstorming new ideas, he will use the whiteboard to illustrate more complex interactions. The conclusions from these impromptu sessions will make it to the wireframes.
John uses Illustrator for wireframe work and takes a great deal of pride in his wireframes. Sometimes, the wireframes are in such a state that they can be easily used by the visual designers as a starting layout for the beginnings of the real design. He admits that the creation of wireframes is one of his most time-consuming tasks.
When John is ready to present his ideas to multidisciplinary stakeholders, he ports his Illustrator wireframes to Powerpoint. He finds that Powerpoint is an easier medium to present ideas because he can animate and storyboard better. In his experience, John finds that storyboarding is much more effective than a simply trying to describe functionality in a requirements document. He mentioned the possibility of linking his logic flowcharts to wireframes as a great help to the clear presentation of ideas.
Of all our interviewees, John was perhaps the most enthusiastic about our project. He could readily see the benefits of having his paper drawing being transmitted to a digital format.
Interviewee Jane Doe
Jane Doe is a PhD students at Berkeley studying HCI. The group met her at her place of work which is the Hearst Mining Building on campus. Currently she is designing an interface to control office/lab lighting by voice commands as well as with a GUI interface.
The group started with questions about her users and how she interacts with them to get the first stages of her design going. We then wanted to know about the design stages and what tools were used during each stage. The group also asked Jane to comment on what she believes is the most important steps in her design phase.
Jane explained that she currently meets with her users and constructs paper models and sketches where she usually prefers her users sketch out what they think would be a good design. From these models/sketches the implementation of the design goes forward. She noted that this is the only time sketches are used in the process; if later in the design cycle more clarification or elaboration on a particular design needed to be done, higher fidelity models would be used.
Jane mentioned that with the initial sketches as design maps, her next steps in her design process was to use a program such as Microsoft Visio to create a higher fidelity model. This is simply to get a cleaned up design to work from.
Jane emphasized the importance of developing a design that both she and the user understood. She explained that many times during the first prototyping session with users there tends to be misunderstandings between how certain aspects to a design are implemented.
Upon mentioning our groups proposal she felt strongly that the ability to enter the data from the Anoto pen into the computer and have an animated (linked pages) prototype right there on the spot would be valuable in terms of making sure that the animated prototype was what the user was anticipating. Clarity in the initial design stages seemed to be the most crucial step because it prevents difficult code changes later on.
After meeting with Jane we realize that a tool to rapidly prototype and animate an interface proves to serve a few purposes: (1)To clarify the design between user and designer at the time of meeting preventing any miscommunication that might occur otherwise; (2) to allow Jane to organize the initial sketches into a presentable format for showing her superior to get approval on the design. Her needs seem to fit the niche that our design is aiming to fill; that being, the initial design stage and presenting the idea so as to move forward with the design.
Interviewee Oliver Doe
We had lunch with Oliver near his office in San Francisco. He is generally pretty busy so we spoke briefly with him on the phone before the interview to give him some background on our project and to communicate the expectations for the conversation. As with all our interviewees, we emphasized our interest in the concept and initial prototype phase of a project.
As an example, Oliver took us through the initial phases of a Web site redesign. The first stage of the process is to compare the existing site against a set of heuristics in order what a Web site does well and what it does not do well. These thoughts are presented to the client for comments.
One interesting exercise that Oliver described, involved coming to a client meeting with small pieces of paper, each labeled with a significant component of the Web site, and then asking the client to create a site map using those pieces of paper. Oliver said that the exercise gave them some indication of the client’s priorities and expectations in the redesign. His team would then capture the resulting site map with a digital camera and work from that as a basis for thinking about the design.
From here, the design team creates a preliminary site map and wireframes. The tools for creating these diagrams are usually Visio and Illustrator, because of its ubiquity and team member familiarity. When presenting the wire frames to clients, Powerpoint is usually used, also because of their ubiquity and team member familiarity.
Oliver described the wireframe stage as the most time-consuming and difficult stage of the initial design phase. He cited the difficulty of getting agreement from client stakeholders as the main cause of difficulty. The actual work of creating the wireframes was secondary.
With the exception of the paper exercise described above, Oliver said that paper did not generally play a large role in his process. In larger meetings that require dynamic diagrams, a whiteboard is often more useful. And in professional services, the quality of presentation is especially important, so hand-drawn diagrams are generally not acceptable for formal presentations.
Interviewee Don Doe
Due to scheduling problems, we were not able to meet with Don in person. However, we were able to chat over the phone and exchange a few emails. Don is currently in the process of refining the UI design specifications of a new web application from a major software company.
Don told us that only uses paper or a whiteboard during the very early stages of a design. He doesn’t have a graphic design background and doesn’t find it very productive or satisfying to work on paper. His tools of choice are PowerPoint, Paint Shop Pro, and Fireworks. He likes these because they allow him to efficiently lay things out, add or remove items, and save different versions of a design. He has built up a library of widgets and icons to use for prototyping, which saves time and makes things look nicer. Also, he thinks animation can be important, which is why he uses PowerPoint.
Being able to easily iterate is a major issue for Don. Most of his designs have over 15-25 iterations before being finalized. Ease of editing is crucial.
Finally, Don is doubtful that better tools can help improve the design process. Most of his problems stem from structural flaws in the software development process. Too often developers see design as secondary, which detracts from the final process. Improving organization and the development process will do more to improve design than any tool.
Contextual Interview Conclusions
We were not surprised that Web and GUI designers had varying approaches. However, speaking from our small sample of interviewees, we were slightly surprised at the low number of interviewees who used paper extensively in the initial concept phase. Similarly, we were surprised that low fidelity prototypes were not used so much for testing but more for stakeholder approval, though in some respects, this iterative process of approval can be taken as a very basic form of user testing.
A common thread that we could trace through each interview was the need for an integrated tool that could organize, manage, and present GUI process flow and wireframes. The wireframes would have to be in a commonly-used vector format, like EPS, that can be read and written by popular applications like Illustrator and Photoshop. This would allow designers to quickly edit/iterate the wireframes in their favorite applications - a functionality that perhaps could be built into later versions of Jigsaw.
Though perhaps not the favorite medium of all the designers interviewed, they all exhibited a favorable disposition towards pen/paper and acknowledged (without prompting or suggestion) the benefits of pen/paper, especially if pen/paper input could be used as a starting point for their digital wireframes. Anoto technology provides an opportunity to provide exactly such an interface.
In conclusion, we felt that a specialized application like Jigsaw, which enables designers to quickly design, organize, and clearly present their ideas held the potential to be quite useful and fit in well with the varied work processes that we encountered.
Answers to Task Analysis Questions
1. Who is going to use system?
Any designers of GUI applications or software on many devices such as: Web, computer software, cellphones, etc.
2. What tasks do they now perform?
When designer begin the interface design process for applications and web sites, they first interview the customer/user. During the interview, they will try to assess the client’s priorities and expectations of the design. The designers will take notes, create interface maps, and sketch the prototype for a design using pen and paper. After the initial design process, designers will convert their initial sketches into digital versions in preperation for preentation to colleagues and manegerial staff for approval of the design.
3. What tasks are desired?
When designers sketch their initial designs in collaboration with the their users, they would ideally like a more automated process. There is time that needs to be spent in the initial design phases in translating their lo-fi sketches into a cleaner more presentable format. Then, they need software that provides the ability to rapidly edit a prototype, and to associate wireframes to vertices. Designers also would prefer a cleaner interface in which to present their designs which could be shown in a more logical manner (i.e. flowchar, sitemap method that would be interactively clickable)
4. How are the tasks learned?
The initial design process is mostly developed from their experience and education. Much of what they know is a direct result of the requirements that is required of them: fidelity of prototypes, styles of prototypes, presentation methods.
5. Where are the tasks performed?
Designers usually perform the initial design phase with their users/customers at their place of work to better understand their needs. Aside from that, offices, conferance rooms are also common places to collaborate.
6. What’s the relationship between user& data?
The data obtained during the initial design phase act as a design map for the remaining designing of the interface. But the ability to modify the data is also very important to the designers so as to rework their ideas. The designers also need to be able to communicate their designs to others for collaboration and presentation.
7. What other tools does the user have?
Designers currently use tools such as Microsoft Visio, Adobe Photoshop & Illustrator to create higher fidelity models from the initial design sketches. For presentations, Microsoft PowerPoint is a common application to use but lacks the site map feel during presention. If users need to create this kind of feel, they typically create short movies or animations running through the interface design.
8. How do users communicate with each other?
Users mostly communicate the ideas with design team members and their client. For example, one of our interviewees is working at a home office, the prototypes he designed would be sent to the client in Canada electronically. The interface would be refined through iterations of this review process. Clients are also in the communication loop during the design cycle and are usually presented to.
9. How often are tasks performed?
The initial design phase of an interface design usually only occurrs once; This goes for pen and paper as well. Subsequent models are designed and worked on using higher fidelity prototypes.
10. What are the time constraints on the tasks?
Couple days to months for each interface design. During the initial design phase, the time constraints are usually those of the clients/users time in working out the initial interface sketches.
11. What happens when thing go wrong?
When desigs are not communicated clearly and correctly between all parties involved then, depending on the stage of the design process, the design would need to be reworked or code would need to be redone. It was made very clear that all designs be corrected and be clear as early in the design cycle as possible because going back and reworking code and such is a very labor intensive and costly consequence.
Analysis of Tasks
Easy
Linking wireframes to workflows: From a list of imported workflows, users can choose a specific one to fill out. The workflow will be displayed on one half of the screen while a list of wireframes will be on the other side. Users can then drag a wireframe onto an item in the workflow to associate the two. This can repeated until each item in the workflow has an associated wireframe. However, workflows are not required to be associated with wireframes and vice versa.
Presenting: Users can choose to present their design projects in a number of ways. The simplest is just to display each wireframe one by one. The more useful way would be to display a workflow on one side and the current wireframe on the other. The presenter would then click on an object in the workflow to display the associated wireframe. The presenter can also drop back to the list of workflows and present a different one.
Moderate
Manage wireframes and workflows: All related wireframes and workflows will be stored in a single project file. Users will be able to create separate project files to better organize their work. All changes to individual wireframes and workflows will be reflected in the project file. Since everything is archived into one file, users can easily send projects to each other. All of this content will be displayed (with metadata) in an intuitive manner to allow users to quickly access what they need. The other important aspect is versioning, so users can reference older wireframes if necessary.
Create/Edit wireframes and workflows: The users will use their Anoto pens to draw wireframes and workflows in any way that they choose (with one page per item). Users can use either preprinted sheets of blank digital paper or they can print digital paper specially made for our program. The latter sheets of paper will have special OCR-enabled boxes that allow users to title a page. The users can continue to work on their designs until they are ready to import the pages into our software.
Hard
Export to other file formats: Designers may want to make their prototype available for others to view remotely. We will offer export to PowerPoint (and possibly Flash). When exporting, users can choose which workflows to include. Users may also want to export individual wireframes to bitmap or vector files, so we provide an option for that.
Remote control: This would be an alternative to presenting with a mouse. Using the streaming capabilities of the Anoto pens, presenters would be able to use the original workflow pages of paper to control what is being presented. Presenters would tap an item on any workflow and the wireframe appearing on the monitor would change.
Functionality Summary
Jigsaw will allow Web and GUI designers to create digital site maps/functionality groupings, wireframes, and flowcharts by sketching with Anoto pen and paper. Once designers have populated Jigsaw with a set of diagrams, they will be able to organize them in a way that makes sense for the particular application. When the data is organized, designers will be able to clearly present the functionality of a Web site or GUI, stepping through logical flows while the appropriate wireframe displays. Having both the application workflow and wireframe visible at the same time enables the designer to better convey his/her design ideas.
In future iterations, we hold open the possibility that Jigsaw may provide rudimentary vector editing capabilities suitable for basic Web and GUI diagramming. Additionally, it may be possible for designers to build up a library of hand-drawn widgets that may be accessed via Jigsaw, in order to quickly assemble digital versions of paper prototypes.
User Interface Descriptions and Sketches
The concept for the Jigsaw user interface is a large work area with three panes. Each of the three panes represents a primary data view: an overview of the project (sitemap or functionality groupings), an overview of workflows, and an overview of wireframes. The panes are arranged left to right in hierarchal order, high level detail to lower level detail: project view, workflow view, wireframe.
In the interest of conserving monitor viewing space, only two adjacent panes will be visible to the user at any one time. The visible interface will be either project(site map/functionality groupings)/workflows or workflows/wireframes, depending on which areas the user wants to focus on.
The project pane will consist of linked items representing a hierarchal tree. It is an organizing structure for the project and may be a site map or groupings of distinct functionality.
Each item in the workflow and wireframe views will be a thumbnail of the object it represents.
Users can switch between the relevant views by gesturing a mouse drag in an open area of a pane. To move from project/workflow view to workflow/wireframe view, the user gestures by dragging left on the pane. The wireframe pane will slide in and the project pane will slide out of the user's view, as depicted below:
To move from workflow/wireframe view back to project/workflow view, the user gestures by dragging right on the pane. The project pane will slide in and the wireframe pane will slide out of the user's view, as depicted below:
Workflow objects can be associated with items in the project view. Wireframe objects can be associated with items in the workflow view.
Double-clicking on an item in project view will show the workflows associated with the project item.
Double-clicking on an item in the workflow view will display the workflow. Once in this zoomed view, clicking on an element in the workflow will display its associated wireframe, if any.
Double-clicking on an item in the wireframe view will display the wireframe and its associated workflow element, if any.
Double clicking on a workflow expands that workflow to take up an entire half. This allows users to drag connections between wireframes onto elements in each workflow in order to an association. When the user is done associating, he can return to the workflows/wireframes view. Likewise, in the project/workflows view, the user can associate the workflows with the project graph.
The diagram below illustrates how a user associates a wireframe to a workflow element:
Clicking on an element in each workflow will display the associated wireframe. This is not only useful to the user to see what associations have been made, but will be used when presenting his/her UI design ideas: by stepping through each workflow, the user can essentially storyboard in detail every significant process in the project.
The diagram below illustrates how a user displays the associated wireframe for a given workflow element:
Example Tasks
Create Wireframe and/or Workflow Diagram
The user draws a wireframe or workflow diagram using Anoto pen/paper. The stroke data is streamed or batched to the Jigsaw application and it appears as a thumbnail in the users workflow/wireframe view.
Associate Wireframe to Workflow Element
The user selects the workflow to work on and drags a line from the wireframe to the workflow element. The wireframe is now associated with the workflow element.
Remote Control via Original Anoto Paper Diagrams
The user presents his/her ideas using the original diagrams (drawn on Anoto paper) as a guide. The user can display any workflow and step through each workflow element, displaying any associated wireframes, by touching the Anoto pen to the appropriate region on the Anoto paper.
Analysis of Solution Approach
As reinforced by the results of our Contextual Inquiry Interviews, the use of pen and paper are an important step in the first stages of the design process. Pen and paper tend to be a good choice at that point in the design phase because it affords collaboration among user(s) and designer(s); it also presents a more natural method to sketch out designs.
Our application utilizes the designs sketched using the Anoto system by importing the sketches into our application to be made into a higher fidelity prototypes. This method allows designers to be able to rapidly prototype and digitize their designs, organize them into flowcharts and wireframe models, and present the prototype to stakeholders.
Scanners or TabletPC's could be used to implement the application that we are proposing however, they would not afford the collaboration and fluidity that the Anoto system provides as outlined above. TabletPC does not allow for the kind of collaboration that is usually required in working to design an interface while a scanner is just much slower to use with our application than the Anoto system. Regardless, the Anoto system is a more direct way to implement our application, everything else is just a more round about method to achieve the same result.
Pros:
-Our interface is more direct because it is going straight from a more familiar interface by sketching to the computer. -Integration of several applications into one allowing users to animate and organize their initial prototypes and allows them to clearly present their designs on a computer. -Provides a more natural method of presentation by using the Anoto system as means of navigating the designs. -Adds redundancy to the application ensuring that the user and designer both have access and copies to the designs.
Cons:
-Editing with the Anoto system proves to be problematic because of the inability to go back and remove marks already made. Editing could be implemented by using special gestures requiring the application to be more complex and resulting in the Anoto paper becoming messy during the design process. -The Anoto system is not as widely adopted as compared to scanners and other devices.
