UX Deliverables

To create a web product requires cross-disciplinary consensus, and we realize it's not easy to achieve with talk after talk in the boardroom. For years, we've employed creative problem solving, acute communication skill, and diagramactic force to look at business problems through the lens of user experience, then translate them into a solid web product.

We model your information, study it's flow and consumption patterns, then guide you through the decision making with your stakeholder group. We provide you with visibility into your product's purpose and function by informing the conversation at an early stage. We lean on our visual training to produce the framework for your product "on paper" or "in prototype" before your development team begins a development cycle.

For some organizations it's already part of their application planning process. For smaller firms, this may be a step that's too often missed. Poor planning can waste a small to medium sized budget. When you can't afford to waste budget dollars, UX Planning can be an effective efficiency tool.

We create information architecture diagrams, interaction designs with notation, user & domain analysis and other usability deliverables. We specify, so interpretation goes smoothly when you're paying for expensive development time or in front of the board.

We realize all efforts are different. We supply the details appropriate for your project, and no more. If achieving a smart consensus with your stakeholders is appropriate for your effort, and investing in professional usability analysis to assure your web project is a success seems like the only way to move forward, we should be in touch.

We sport over 27 years of UX and IxD experience. That's longer than the web has been around. We are the people that birthed Criminal Justice Information Systems used by 10+ states today.

User & Domain Analysis

A User & Domain Analysis combines the following into a comprehensive view of your web product's field of play:

• Product, prototype & competitive audits
• Qualitative, stakeholder, SME, and ethnographic interviews
• Technical, business, and environmental contexts — the domain
• Vocabulary and social aspects of the domain

This form of analysis helps the process of web product development by:

• Rooting design decisions in research results
• Uniting the team with a common understanding of domain issues and user concerns
• Empowering management to make informed decisions rather than rely on personal preference or guesswork

Some examples of questions we seek to answer are:

• What goals motivate people to use the product?
• What tasks help people accomplish these goals?
• What experiences to people find compelling?
• What problems do people experience using existing products?
• What are the behaviors, attitudes and aptitudes of potential product users?

Requirements

We prefer the action/object/context method for requirements definition. This helps defined interactions using direct statements like:

Email (action) a contact (object) directly from an issue (context).

This kind of clarity helps stakeholders think of requirements as separate from features or tasks. Describing requirements like this frees the design process from traditional data and functional requirements and yields cutting-edge experiences.

That's not to say we don't have vast experience dealing with requirements in the traditional data, functional and contextual requirements. These regularly take the following form:

Data Requirements

The objects and information that need representation in the system. Ie. accounts, people, documents, messages, songs, images and attributes of same

Functional Requirements

The operations or actions that need to be performed on the objects of the system which traditionally translate into interface controls.

Contextual Requirements

Business requirements:
development timelines, regulations, pricing structures & business models

Brand & Experience requirements:
attributes of the experience you'd like people to associate with your product or organization

Technical requirements:
weight, size, form factor, display, power constraints, and software platform choices

Customer & Partner requirements:
installation, maintenance, configuration, support costs & licensing agreements

Personas

The goal in representing a set of personas is to represent the diversity of observed motivations, behaviors, attitudes, aptitudes, mental models, work or activity flows, environments and frustrations with current products or systems. We're trying to identify behavioral variables, map customers to those variables, and use that information to identify significant behavioral patters.

We work to identify:

• Activities — What the user does and frequency
• Attitudes — How the user thinks about the domain or technology
• Aptitudes — What training the user draws from
• Motivations — Why the user is engaged
• Skills — The users' capabilities related to the product

As personas are identified, we work to represent goals specific to each archetypal user. This helps design products that fit within the usage patterns of it's users. Then, we prioritize personas to assure your product's design targets it's primary base of users.

Primary personas represent the primary target for the design of the interface. Although there can be only one primary persona per interface, it's common in enterprise products to have multiple distinct interfaces for multiple primary personas. Secondary personas are mostly satisfied with the primary persona's interface but have specific needs that can be accommodated without upsetting the products ability to serve the primary persona.

Additional persona types of supplemental, customer, served and negative personas are used to capture those who's needs are met by the primary interface, though their interaction with it may be non-traditional or tangential. To learn more about how we construct personas for web products, get in touch with us today.

Information Architecture

Each digital product requires that attention be paid to how information is organized such that it best serves a user's goals. Often, this takes the form of a business' org chart, product offering table, or target market segments. Although this information is highly relevant, it's often not enough to organize large sets of information in a method relevant to the end user.

We use traditional tools like OmniGraffle and Visio to give structure to your information in a way that reflects how it will be used — and the user's mental model. During this process, stakeholder input, current IA, and knowledge gathered through qualitative analysis is synthesized into a diagramactic models.

One direct result of this process is improved navigation design. Navigation design and information architecture go hand-in-hand. Because navigation is the single largest inspiration for trust in a web product (not to mention brand), without good IA, your users can become disillusioned with the organization of your information, frustrated with disorganized content and apathetic about your product or service.

Throughout our product design process, we provide information architecture diagrams for relevant information sets… providing your stakeholders with a place for input before the web product reaches development. As you might expect, this saves time and money by reducing rework.

If this seems like something your organization could benefit from, please be in touch.