BLAKELYInteractive

WHAT IS IT?

Contextual Inquiry (CI) is a User Centered Design approach that is one of the best methods for understanding the context in which users work. It is basically a structured field interviewing technique, based on a few core principles that differentiate it from plain journalistic interviewing. CI is a discovery process that is more like learning than testing and is best used early in the discovery phase of most software development lifecycles.

CI is used to gain an understanding into how people feel about their jobs or tasks they are performing, how they complete they're work, how they use information and how information flows through their organization. It is performed on-site on location where the user would normally use the system. This allows the interviewer to observe user behavior, ask follow-up questions and gain insights into user’s reasoning in context of their work environment.

WHO USES IT?

Contextual Inquiry is used by Information Architects and Interaction Designers to better understand users goals and needs. They use it to gain insights into user behavior, clarify assumptions and understand real world application. They also use it to inform design decisions by grounding them in real user needs and behavior.

HOW ARE THEY MADE?

Contextual inquiry typically requires the following steps:

 1. Define the user segments to be targeted for the inquiry. The goal is to hit a cross functional slice of all your users.

2. Create hypothesis’s to be tested and assumptions to be validated.

3. Create a list of demographic questions and ice breakers to start with the CI sessions.

 4. Create a list of general questions for traditional interview portion of the inquiry.

5. Create categories of information you want to make sure you learn about as you observe users doing their work or tasks.
6. Create wrap up questions or reminders.

PROS

• Provides insights into users that is not available via any other medium.
• Allows interviewers to discover behavior patterns that are similar amongst all their users.

CONS

• Can be an expensive undertaking, especially for large user communities.
• If questions are not structured appropriately, can lead users to respond according to preconceived ideas.
• Interpretation of data is subjective and can be sabotaged by stakeholders interpreting findings to support hidden agendas.

WALT DISNEY WORLD - WHO ARE WE?

In the fall of 2008 Walt Disney World Resort was in the early stages of their website redesign. Part of this effort was a massive requirements gathering effort from the business teams. It became abundantly clear that we did not have detailed understanding of who our user community was. So I sold them on the idea of going into the field performing contextual inquiries into their user homes. Thus began a 3-week whirlwind tour of 3 cities interviewing 15 families in their homes.

WHAT IS IT?

Personas are hypothetical archetypes, or 'stand-ins' for actual users that drive the decision making for interface design projects. They are not real people, but they represent real people throughout the design process. It is important to realize that they are not concocted. They are discovered as a by-product of the investigative process and although imagineery, they are defined with significant rigor and precision.

To make them more realistic, names and personal details are made up and defined by the persona's needs and goals. A persona specification often contains a users emotional goals, usage goals and needs, barriers, pain points and opportunities. Though a persona specification is an important deliverable for disseminating information about users the greater value of personas lies in allowing designers to think as our users would. To quote Andrew Hilton, in his Boxes and Arrows Article, Personas and the Role of Design Documentation “Personas are actually the designer’s focused act of emphatic imagination, grounded in first-hand user knowledge.” Source: (1) Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Indianapolis: Sams, 1999, pp. 123-24. (Wording condensed and modified.)

WHO USES IT?

Information Architects Use them in design to focus their solutions on our user needs and goals.
Tech Teams Use them to understand their users so that they can code solutions that help them achieve their goals.
QA Teams Use them to write test scripts which reflect the ways that users realistically user their products.

HOW ARE THEY MADE?

There are 4 basic phases in a persona lifecycle:

1. Planning & Conception – Consists of understanding market segments and current user research in order to formulate assumptions to be tested during Contextual Inquiry Sessions.
2. Contextual Inquiry – Consists of a series of real world interviews of users in their actual environments to gain an insights into their behaviors, needs and goals.
3. Analysis – The analysis phase is used to cluster user feedback, discover behavior patterns and to triangulate qualitative, quantitative and existing market research in rder to draw conclusions and define the personas.
4. Assimilation – The assimilation phase is where the personas are introduced to the design and development teams, and are championed as real user with real needs.

PROS

• Allows all members of the design and development teams to focus their design efforts on solutions that meet their user goals and needs.
• Provides insights into user behaviors and motivations.

CONS

• Inaccurate, poorly created personas lead to inferior design, following the old axiom 'garbage in, garbage out'.
• Can be an expensive undertaking, especially if it involves contextual inquiry.
• Using Personas successfully requires buy-in from all members of the team, including project managers, developers, business units, content strategists, copy writers and visual designers.

MEET EMMA WHITE

Emma was the first of the three personas created for Walt Disney World using contextual inquiries. Fifteen families were visited in 3 different states over a period of 2 weeks.

MEET RACHEL BRENNER

Rachel was the second of the three personas created for Walt Disney World using contextual inquiries. Fifteen families were visited in 3 different states over a period of 2 weeks.

MEET LIZETTE PEYTON

Lizette was the third of the three personas created for Walt Disney World using contextual inquiries. Fifteen families were visited in 3 different states over a period of 2 weeks.

WHAT IS IT?

Scenarios are narrative stories that provide detailed information about any given process in context of its use. They are used to understand the breadth of interactions, rather than the detailed steps in a process. They will cover all the variations of how users interact with the system providing a holistic view of the design.

WHO USES IT?

Scenarios are used to understand how users intend to interact with the design. Therefore, scenarios are very effective at communicating to development and business teams how users are expected to interact with the systems.

HOW ARE THEY MADE?

Scenarios are used in conjunction with Personas and tell the story of how the persona interacts with the system. Consequently, creating a scenario is similar to method acting, in which you place yourself in the role of the persona and write the story of how that persona interacts with the design. The goal is to cover as much breadth as possible in the scenario so that you can understand the scope of the design without getting bogged down in the details of individual steps. Remember the goal is to tell the story of User Experience through the eyes of the persona.

PROS

• Scenarios are very effective at selling designs and communicating the user experience.
• They can be easy to understand and read.
• They allow the readers to gain insights in to their user.

CONS

• The true effectiveness of the scenario often relies on the abilities of the creator.
• Writing for breadth often precludes understanding the depth of an interaction.

THEME PARK MERCHANDISING

I created this scenarios to tell the user experience story for the Theme Park Merchandising project. They were used to pitch the design concept to the business units and communicate the design intent to the vendor commissioned to develop it.

WHAT IS IT?

According to Dan Brown, in his book Communicating Design "Concept models are highly flexible documents that you can use to show a variety of ideas at play in a given website. At their simplest, concept models illustrate how different ideas relate to each other, representing the building blocks of the idea...".

The key to Concept Modeling is in the process of getting to the deliverable. It provides you an opportunity to understand what are often complex ideas and relationships in an abstract view. It affords the opportunity to look at the bigger picture at a level that separates the 'forest from the trees' while still remaining fluid. Thus, you can iterate through many versions of the model before settling on a model that accurately reflects the complexity of the design.

WHO USES IT?

Concept models are used to document underlying structures of a site, and communicate these structures to various members of the design team and stakeholders. This helps them understand the relationships between ideas and structures that are often abstract.

HOW ARE THEY MADE?

Creating concept models can be either simple or complex depending upon the ideas and structures being represented.

 1. Begin by defining nodes and connection points between the nodes. These connection points describe the relationship the nodes have with each other and can be directional or neutral.


 2. Elaborate on the model by adding detail by adding or reducing nodes and their relationships. You can also start to cluster the nodes and define parameters in which the model or design operates.


 3. Elaborate on relationships by embellishing connection points representing various types of communication or relationships.


 4. This is probably the most important step in the process. At this point your concept model should evolve into something more than just a group of circles and arrows.Visually represent nodes and connection points as objects that more accurately reflect their meaning. One can choose to remain abstract and represent the concept model using colors directionalflows. At this point the variations on the concept models are endless. Bear in mind that the concept model needs to clearly communicate the design ideas.

PROS

• Can quickly communicate abstract concepts to varied audiences.
• The process of creating concept models helps the designer quickly understand the complexities of the domain.

CONS

• They can become unwieldy and confusing.
• Are only as good as the designer's understanding of the domain.

UNDERSTANDING DISNEY PARKS

I created this concept model to communicate how Disney's 2009 marketing campaign related to Disney Parks.

VACATION PLANNING CYCLE - DISNEY PARKS

I created this concept model to describe how the proposed Celebration Experience mini-site fits into Disney Parks vacation planning cycle.

WHAT IS IT?

User Journeys is a method of conceptualizing and structuring a website's content in a manner that reflects the thoughts, considerations, and experiences of the user. They identify the various paths various user take through the website and helps to identify paths they will take to accomplish their goals.

User Journeys are often used with personas by merging scenarios with user flows. However, unlike user flows, User Journeys explore a user's mental processes and translates these into paths that depict the user’s journey through the website.

WHO USES IT?

User journeys are used by infromation architects to understand how users navigate through the website identifying their entry and exist points thus helping inform design decisions.

HOW ARE THEY MADE?

Creating User Journeys is a simple four step process:

1. Identify your user needs. These are broad, top-level needs or goals.
2. Brainstorm content and functionality that will most effectively answer the user needs and goals. This can be anything from wizards to checklists, games, forums, or peer reviews. In the case of a redesign, you want to assess how well the current content and functionality is answering and addressing the primary needs.
This can be anything from wizards to checklists, games, forums, or peer reviews. In the case of a redesign, you want to assess how well the current content and functionality is answering and addressing the primary needs and need states.
3.I Identify the entry and exit points for each of the features.
4. Map the users paths through the website identifying their entry and exit points.

PROS

• You can communicate multiple user stories very quickly identifying their path through the site.
• Allows you to view a bigger picture of the website and gain insight into the overall site structure.

CONS

• User Journeys can become visually busy and difficult to interpret.
• Not often used or understood and therefore requires explanations.

CELEBRATION EXPERIENCE

I created this User Journey to understand all the entry and exit points, and paths a user might take when entering the Celebration Experience mini-site.

FREE ON YOUR BIRTHDAY

This User Journey explored the paths taken by the users to register for Free On Your Birthday celebration at Disney Parks.

WHAT IS IT?

A Storyboard is a series of illustrations or sketches depicting a sequence of events or processes performed by users interacting with websites, computers or other devices. They typically consist of a series of panels with illustrated representations of users and their experiences interacting with other users or the system.

Storyboards allow design teams to convey their concepts and designs in a visual format that is easily updated and adapted to changing requirements. They are very effective in selling concepts to internal and executive teams because they visually tell the story of an intended experience in a focused manner. Though typically used in Pre-Discovery and Discovery phase of development to conceptualize ideas they can also be used in Pre-Design and Design phases of a project to explore various features.

WHO USES IT?

Storyboards typically consist of a series of panels containing a visual representation of the experience and textual description of each panel. The textual descriptions describe the action(s) taking place within the panel as well as describing any interactions performed by users interacting with a user interface.

HOW ARE THEY MADE?

Storyboards typically consist of a series of panels containing a visual representation of the experience and textual description of each panel. The textual descriptions describe the action(s) taking place within the panel as well as describing any interactions performed by users interacting with a user interface.

The level of fidelity required by a storyboard depends largely on its target audience and purpose. If the target audience is an executive team then illustrating the key panels at a high level of fidelity is recommended. If the purpose is for internal team reviews and ideation then low fidelity panels can be used.

PROS

• Storyboards are widely accepted as a work in progress and therefore help prevent rabbit hole conversations about color schemes, diversity and “what if” discussions.
• Storyboards help focus discussions and explore ideas while still being easy to make changes.
• Creates a cohesive story that can tie wireframes and comps into a single presentation.

CONS

• Storyboard artists are not always accessible.
• Can be an expensive undertaking for pre-discovery exercises.

ITINERARY PLANNING TOOL

This storyboard was created to explore how an itinerary planning tool could work for Walt Disney World. Storyboard art created by Anna-Marie White.

CELEBRATION CENTRAL

This storyboard was used to successfully pitch a concept to Disneyland Resort executives about a proposed Celebration Central application. Storyboard art created by Anna-Marie White.

THEME PARK MERCHANDISE

This storyboard was used to tell the Theme Park Merchandise story to a third party vendor commissioned to build the shopping site. Storyboard art created by Anna-Marie White.

WHAT IS IT?

Wireframes outline the what, where, and how of a website or application. They set the functional foundation upon which user interaction is built. Annotated wireframes may include a business / workflow process as well as descriptions about the elements on the wireframes themselves. Also known as schematics and blueprints.

WHO USES IT?

Design teams use wireframes to iterate through designs establishing layouts positioning and functionality of pages and page elements. Development teams use them to understand structure and business rules. QA uses them to write test scripts and understand functionality.

HOW ARE THEY MADE?

Step 1: Identify content areas, content descriptions, and content priorities. Provide identifying information (project name, page/state, audience) and administrative information (author, date created/modified)

Step 2: Tell how the screens function by using scenarios to explain their purpose. Show how users interact with a site with links and form elements, etc. Detail annotations to show functionality and rationale of screen elements as well as give direction for copy.

 Step 3 (Optional):Identify important layout or design elements. Give context in the overall design with a mini-site map or flow chart. Use sample content or give description of content.

PROS

• They ensure accurate planning for functional specifications.
• They ensure all project team members are well briefed.
• They enable developers to start work on new functionality before the visual design begins, helping to minimize development costs.
• They track changes in the design process as decisions are made to the interface, this minimizes project creep.

CONS

• Can get complex and down into the details where it requires more expertise to know what is being represented.
• Can be difficult to interpret business rules especially when dealing with complex transactional systems.
• Maintaining wireframes and annotations through product lifecycles can be difficult and time consuming.

FREE ON YOUR BIRTHDAY

This wireframe was created for a submissions forms. I used numbered annotations because I needed to describe complex field rules and behaviours.

THEME PARK MERCHANDISE

This wireframe was created for Disney's Theme Park Merchandising. I used pointer annotations because there were few business rules and the annotations were used to describe page and element behaviors only.

DISNEY PARKS

This wireframe was created to describe changes to an existing page on DisneyParks.com. I used highlight annotations from a screenshot because I needed to describe changes without recreating wireframes.

WHAT IS IT?

Rumbaugh, Booth and Jacobson first defined use Case Modeling, also known as Use Case Diagramming, in 1996 as part of the Unified Modeling Language (UML). Use Case Modeling is simply a visual representation of users, (Actors) in UML using a system to achieve a goal. Its purpose is to allow designers to view user interactions with a system from an object oriented point of view by diagramming their interactions using scenarios.

In it’s basic form a use case model consists of an Actor, a Use Case, System Boundaries and Actor Intentions. To help facilitate the communication of Use Case Diagrams UML has specific notations for modeling these use cases. There are a stick figure to represent Actors, ellipses to represent a Use Case, a dotted boxed outline to represent system boundaries and lines or arrows between Actors and Use Cases to represent user intentions.

WHO USES IT?

Information Architects use Use Case Models to understand user intentions with the system and to define user interactions based on requirements. They communicate user behavior to Development and QA teams. Design and Development teams use Use Case Models to understand system scope, user goals and behaviors. They use them for estimations, prioritization and defining technical designs. QA uses them to write test scripts, create test plans and understand system feature designs.

HOW ARE THEY MADE?

Use Case Models are generally defined by performing a Use Case analysis based on requirements. This typically derives a set of features where the realization of them is a set of Use Cases. Creating the UML notation of these Use Cases consists of drawing an Actor (stick figure), an ellipse containing the name of the Use Case and a line drawn between the Actor and the Use Case. Optionally, you can draw a box around a set of Use Cases to represent a system boundary. UML as a language has several notations that extend this Actor Use Case relationship by utilizing such notations as includes and extends relationships.

PROS

• Use Case Modeling is well-understood communication tool between development and QA teams.
• Provides a holistic view of the system early on in design allowing early discussions with development.
• Has clear traceability to requirements and test cases.

CONS

• Critics of Use Cases claim that they ignore user requirements.
• Their level of abstraction is not high enough to truly understand guest intentions and behaviors.
• The learning curve can be high for Information Architects, especially thinking from Object Oriented point of view.

HR BANNER SYSTEM

I created this use case model to understand how users interacted with Banner and identified the various roles that they played.

UCSF Admissions

UCSF Admissions was a portal application so I created this view of the use case model to understand how user would interact with various components of the application.

DISNEYLAND CELEBRATION CENTRAL

Disney wanted their stakeholders to connect with the roles that their users would perform when using this minisite so we created characters to represent the roles. Creating the actors in this way allowed us to communicate the roles the users perfromed via the characters.

WHAT IS IT?

Essential Use Cases refers to essential models that “are intended to capture the essence of problems through technology-free, idealized, and abstract descriptions”. Constantine and Lockwood [1999]. These descriptions are narrative dialogs between users requests and system responsibilities. They are intended to describe the interaction between the users and the system or website at an abstract enough level that it addresses requirements without describing interface designs.

WHO USES IT?

Information Architects use Essential Use Cases to describe user interactions based on requirements and communicate those interactions to Development and QA teams. Development teams use them to understand system scope and user goals and behavior for estimations, prioritization and technical design purposes. Business Analysts will use them write detail Use Cases and QA teams use them to write test scripts, create test plans and understand system features and designs.

HOW ARE THEY MADE?

Once you understand your Use Case Model creating Essential Use Cases is as simple as detailing the interactions of each Essential Use Case in the model. The easiest way to detail these Essential Use Cases is to divide a 3 x 5 note card in half, label the left column User Requests and the right column System Responsibilities. Next role-play the user interacting with the system making requests and capturing the systems responsibility to those requests.

PROS

• Allow designers to explore design decisions without committing to an interface design too quickly.
• Facilitates brainstorming solutions by chunking discussions around specific features.

CONS

• Critics of essential use cases claim that they ignore user focusing on system.
• Their level of abstraction is too high enough to truly understand guest intentions and behaviors.
• The learning curve can be high for Information Architects not familiar with Object Oriented designing.

CELEBRATION CENTRAL

These are a few narritive descriptions I created from the use case model I created for Disneyland Celebration Central.

WHAT IS IT?

According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful." Each use case describes how the Actor will interact with the system to achieve a specific goal. One or more may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Use cases typically avoid technical jargon, preferring instead to use plain english.

WHO USES IT?

Information Architects/UI, UX Designers use Use Cases to detail user interactions with the system based on the requirements and interactions defined by Essential Use Cases. This allows Development and QA teams to understand the steps in the process and what the system responses are to the user inputs. QA then translates these into test scripts and test cases to validate the design against.

HOW ARE THEY MADE?

Dependng upon the design approach used Use Cases are either created from Use Case Models, Essential Use Case, Scenarios and/or Activity Diagrams. Perhaps the easiest way to write Use Cases is from Essential Use Cases since they are high level iteration of the Use Case that provide the framework for writing the detailed steps of the Use Case. At it's core Use Cases describe the step-by-step processes performed by the user accompanied by the system responses to those steps. Typically, a Use Case consists of a left hand column containing the User Actions and a right hand column containing the System Responses.

PROS

• Use cases can put requirements in context, describing them in clear relationship to business tasks.
• Use cases prompt the consideration and discussion of alternative paths, thus capturing less frequent behaviour and so improving system robustness.
• Uniquely identified use cases can be traced back to business requirements or stakeholder needs.
• Use cases can serve as a basis for the estimating, scheduling, and validating efforts.
• Well written Use cases have proven to be easily understandable by business users, and thus to act as a bridge between them and software developers.

CONS

• Use cases do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
• There is a learning curve involved in interpreting use cases correctly, for both end users and developers.
• Proponents of Extreme Programing and Agile methodlogy often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.

MANAGE GROUP INBOXES

This use case was used to describe the steps a user performed to create and manage group inboxes for a transaction based system.

MANAGE NODES

This use case was used to describe how users manage nodes in a content managemet system, designed for Blooomberg Law.

WHAT IS IT?

Card Sorting is a quick, inexpensive, user-centered classification activity in which a participant sorts labeled cards into similar groups. There are two types of Card Sorts: Open and Closed Piles. Open Piles are based on the perceived similarity of the cards (what makes sense to the participant). It allows participant to organize and label content intuitively, providing insight on the preferred vocabulary of representative users.

Closed Piles are grouped according to categories already provided for participant. By providing participant with existing navigation, participant focuses on re-organizing and labeling content under these headings. Discussion around why the cards are placed in particular piles provides further insight into user expectations for content. This method serves as input into the navigation design process by informing the overall structure of the universe of information, including menus and taxonomies.

WHO USES IT?

Information Architects use them to gain a better understanding of the users and their thought processes. Card sorting provides a guide in building navigation systems, organizing Web content, and what labels to consider using. User Researchers may observe or help facilitate card sorting, as the IA purposes of the activity overlap with user research objectives.

HOW ARE THEY MADE?

1. On index cards, write the name and/or a short description for each main item to be categorized.
2. Provide participant(s) the shuffled deck along with clear, sorting objectives. (These participants are recruited based on how they reflect the target audience.
3. Ask the participant(s) to sort the piles based on similarity of items (what they feel belong together). As many or as few piles can be created, and can be in various sizes.
4. Optional: Have the participant(s) arrange the resulting piles into bigger ones, and to name those different groupings. This provides additional ideas for potential words/synonyms to use for navigation labels, links, headlines, and search engine optimization.

PROS

• Provides insight into users’ thought processes.
• Improves findability factor in design.
• Inexpensive testing/research.

CONS

• Favors one perspective and is not comprehensive.
• Drawn data is more quantitative than qualitative.
• Preparation and actual activity can be time-consuming.
• Requires recruiting and scheduling participants.

CARD SORT EXAMPLE

This is the card sort that I performed during contextual inquiry sessions for Walt Disney World.

CARD SORTING RESULTS

I created this spreadsheet to help understand the results of the card sorting. It allowed me to gain insights into the organizational structures provided by our users.

WHAT IS IT?

A site map is a collection of web pages with their connections highlighted. It is a diagram to show overall site structure and hierarchy of a system. For large sites, it may document patterns of organization that are applied across similar sections, instead of accounting for every single page. Site maps also document site structure to ensure that all content is accounted for. They are used as guides for navigation design, site index, and content migration.

WHO USES IT?

Information Architects use them to gain a high-level view of site and to determine site structure, hierarchy and navigational structures. They are also used to determine scope and scale based on identifiable templates. Development uses them to understand scope and site structure. QA uses them to develop test plans and understand navigational structure.

HOW ARE THEY MADE?

Generally speaking, a site map is a paper document consisting of boxes representing different areas of the site, connected by lines. The lines show semantic relationships between the areas of the site, may also represent navigation, and show hierarchical levels. In creating the site structure, it is never final after a first draft. You may need several revisions to make sure the user priorities are adequately represented and every piece of content is sufficiently categorized.

PROS

• Provides a visual representation of the site.
• Shows overall structure and hierarchy.
• Provides framework for basing site navigation.

CONS

• Takes a high effort to create and maintain.
• Doesn't answer all site and navigational questions.

HI LEVEL SITEMAP

This Hi Level sitemap allowed the design team to view the existing site structure with proposed modifications for a new site structure.

DETAILED SITEMAP

This is a detailed sitemap for Disney Parks and the new Celebration Experience Minisite.

WHAT IS IT?

Activity diagrams describe the workflow behavior of a system. They are similar to process flows in that they represent a sequence of steps and represent alternative paths through a system. They represent activities performed by a user interacting with a system including system responses. Activity diagrams can also show activities that are conditional or parallel as well as representing alternative and exception flows.

WHO USES IT?

Information Architects create activity diagrams to understand a users interactions with a system. They help inform use case flows and details. Development teams use them to create sequence diagrams and to understand users interactions.

HOW ARE THEY MADE?

Activity diagrams show the flow of activities through the system. Diagrams contain a number of standard notations that reprent activities, actions, synchronization bars, decision points, nested activities, transitions and swimlanes. Much like process flows activity diagrams always have a start and stop. They contain a series of activities connected directional arrow and represent a users steps and paths in a system.

PROS

• Allows the creator to visualize the steps and activities a user needs to take to complete a process.
• Provides visual method of looking at Use Cases and interactions between Use Cases.

CONS

• Has a learning curve associated with understanding them.
• Can quickly become overly complex if not created with the right level of detail.

WHAT IS IT?

Sketches are disposable, unfinished hand drawn illustrations that ask questions and demostrate possible solutions. Instead of focusing on small details, sketching should concern things like proposition (Does the overall idea seem useful?), concept (How does it deliver it’s value?) and context (Would it fit in with the other things the user is doing, e.g. before and after using it?) Sketching is about exploration, throwing things out, and making mistakes. Harry Brignull

WHO USES IT?

Information Architects use sketches to explore ideas, think out loud, understand processes and flows. These can then be used to communicate concepts to designer, storyboard artists and other design team members.

HOW ARE THEY MADE?

1. Grab paper and drawing instrument.
2. Do many sketches.
3. Narrow down.

PROS

• Quick to make and easy to change
• Encourages exploration
• It doesn’t give the impression of being more done than reality

CONS

• Does not suggest a concrete design.
• Lightweight, not a formal document

Rough Sketching

This is a rough sketch used in when initially concepting an idea for a planning tool.

Refined Sketch

This is a refined concept sketch, it starts to identify the details and behavior of the UI.

Independent Consultant - Walt Disney World Parks & Resorts Online

Creative Lead/Sr. Information Architect. (6/2007 - Present)

Lead design teams to define and create Disney’s 2009 online marketing campaign. Aligned the marketing campaign branding and strategy with Global Marketing effort. Designed concepts and won pitch off against third party design agencies.

Worked with design teams to define and create the next generation website (Web 2.0) for Walt Disney World Parks and Resorts Online and other features and enhancements. Performed contextual inquiries to understand user goals and inform personas creation. Recommended best practices for incorporating personas into design and development lifecycles. Created all necessary specifications to communicate designs to visual designers, tech teams and executive committees.

Responsibilities

• Led creative teams to conceptualize and design leading edge websites taking advantage Web 2.0 capabilities.
• Led teams in creating creative pitches to conceptualize and represent designs and user interactions for executive approval.
• Successfully created winning designs competing against third party interactive agencies.
• Performed contextual inquiries to understand Disney’s user community and inform persona creation.
• Analyzed qualitative and quantitative user research in persona creation.
• Championed personas for usage in the organizational culture.
• Created task and activity models to represented user mental models to help inform design.
• Incorporated storyboards and user Interface illustrations to communicate design concepts and ideas.
• Created scenarios and edge cases to refine and communicate designs.
• Created annotated wireframes to communicate technical requirements to tech teams.
• Mentored IA’s and managers, creative and tech teams and project managers in various user centered design methodologies such as goal directed design, usage centered design, task case and use case modeling.

Independent Consultant - UCSF

Lead Interaction Designer (1/2007 - 6/2007)

Lead User Experience team in creating and implementing a UI Pattern Library specific to University of California, San Francisco web-based applications. Recommended best practices for incorporating UI Patterns into current software development lifecycle. Worked with project management to incorporate User Centered Design best practices into current development processes.

Responsibilities

• Implemented a design methodology and strategy that incorporated User Centered Design principles and into current development methodologies.
• Created a UI Pattern Library recommending best practices for incorporating UI Patterns.
• Trained and mentored Project Management team in UCD practices.
• Facilitated JAD sessions to validate requirements.
• Identified system features from business requirements.
• Created a Use Case Models from requirements and feature lists.
• Created Activity Diagrams to establish user actions.
• Created Wireframes to validate use case functionality.
• Incorporated UI Patterns into prototypes.

Independent Consultant - U of I

Lead Information and User Experience Architect (7/2005 - 12/2006)

Lead a 15 member design team in the design of a Front End for the University of Illinois’s ERP System. The system has a user base of thousands HR staff in the university's Urbana-Champaign, Chicago and Springfield campuses, and manages records of tens of thousands university employees including academics, civil service and students.

Responsibilities

• Implemented a design methodology and strategy that incorporated User Centered Design principles and RUP methodology.
• Led a 15 member strong design team in the creation of a new web based front end to an existing ERP system.
• Mentored entire team in User Centered Design and RUP.
• Trained team members in User Centered Design and RUP methodologies.
• Facilitated user community interview sessions identifying users’ needs and wants.
• Extrapolated preliminary business requirements from user community interviews and online surveys.
• Facilitated JAD sessions to validate requirements and identify additional requirements.
• Identified system features from business requirements.
• Created a Use Case Model from requirements and feature lists.
• Created Activity Diagrams to establish user actions.
• Created Wireframes to validate user functionality.
• Created Use Case Specifications.
• Created Functional Design Document based on requirements, use cases, wireframes and activity diagrams.

Innodata-Isogen

Information Architect / Business Analyst (11/2003 - 7/2005)

Innodata-Isogen provides a wide range of content-related services to many of the world’s leading commercial publishers, blue-chip enterprises, federal and state agencies, and major archives, libraries & museums.

Responsibilities

• Established and implemented requirements standards and processes for the all project teams using the Rational Unified Process (RUP) in an SOA environment.
• Created process guidelines to establish a standardized, repeatable approach to requirements gathering and use case modeling that provided increased communication through out all phases of the project life cycle.
• Created business models that accurately reflected the workflow processes implemented by the client.
• Created use case realizations from the business models and business requirements to ensure the system accurately fulfilled the client's expectations.
• Created User Acceptance Tests (UAT) to ensure that the system meets the client’s expectations.
• Established versioning procedures for all requirements artifacts.
• Lead and mentored other analysts throughout various phases of the requirements process.
• Implemented user centered design principles by incorporating HI and Low fidelity UIs and UI specifications into an existing SDLC process.
• Created Visio stencils to assist in the rapid prototyping of UI designs.
• Ensured product consistency across multiple products and development teams through peer review sessions.
• Championed user centered design principles by incorporating UI prototyping, reviews and client walk-through prior to development.
• Successfully brought UI development in-house to allow greater control, and standardization of the product look and feel.
• Created User Interface (UI) guidelines to ensure consistency of UI development across multiple projects.
• Designed UI mockups and UI specifications to ensure the system was developed to design specifications.
• Lead Joint Analysis and Design (JAD) sessions with the client to understand their needs.
• Facilitated brain storming sessions to gather requirements, understand product features and user processes.

Intellinex

Information Architect / Business Analyst (1/2000 - 11/2003)

Intellinex, http://www.intellinex.com, is a leading provider of learning Business Process Outsourcing offering design, delivery and global management of comprehensive learning programs for national and multinational business and government organizations.

Responsibilities

• Established and implemented requirements standards and processes for the all project teams using the Rational Unified Process (RUP) in an SOA environment.
• Created process guidelines to establish a standardized, repeatable approach to requirements gathering and use case modeling that provided increased communication through out all phases of the project life cycle.
• Created business models that accurately reflected the workflow processes implemented by the client.
• Created use case realizations from the business models and business requirements to ensure the system accurately fulfilled the client's expectations.
• Created User Acceptance Tests (UAT) to ensure that the system meets the client’s expectations.
• Established versioning procedures for all requirements artifacts.
• Created Visio stencils to assist in the rapid prototyping of UI designs.
• Ensured product consistency across multiple products and development teams through peer review sessions.
• Designed UI mockups and UI specifications to ensure the system was developed to design specifications.
• Lead Joint Analysis and Design (JAD) sessions with the client to understand their needs.
• Facilitated brain storming sessions to gather requirements, understand product features and user processes.