Re-prioritize for the start of each iteration to adapt to changes in business needs and/or scope, referred to as "Backlog Grooming."
Backlog Grooming should occur regularly. A best practice is to do once per week as a pre-Iteration Planning activity.
Scrum Team Members can use Story Points (a.k.a. Planning Poker) to determine both the perceived level of difficulty for a given User Story, and the perceived volume of work to achieve the given User Story. Values of Story Points should not be a measure of estimated hours.
Story Point values for each User Story are relative to the other User Stories, and the goal is for the Scrum Team Members to gain an understanding of each others' work for the Sprint. The Fibonacci number scale can be used for the Story Points.
User Stories should be prepared in advance of the Iteration Planning meeting/conversations.
Scrum Team members select User Stories from the prioritized Product Backlog to commit to achieving by the end of the Iteration time duration.
User Stories can be deconstructed into actionable tasks and sub-tasks. A technique called User Story Mapping can be used to help deconstruct User Stories.
Story Points can provide an estimate of Scrum Team's potential bandwidth thru-put for the Iteration, referred to as "Iteration Velocity." From past Iterations, actual velocities can be used to inform the team’s achieved bandwidth thru-put.
Players: Scrum Team Members, Scrum Master (SM), & List
User Stories as well as related tasks and sub-tasks are tracked throughout the duration of the Iteration, as progress is made towards completion.
Common categories for tracking progress are:
Not Started - team has committed to achieving this user story or task during the current Iteration, but no one has begun work towards this item.
Work In Progress - one of the team members has begun work on this item.
Done - this item is 100% completed, tested, and ready for deployment.
A visual display of all User Stories, tasks, and sub-tasks can help all team members stay informed on their collective progress. For example, color coding elements can assist in the visual display:
Planned user stories - Green
Tasks/sub-tasks - White
Unplanned user stories - Yellow
Bugs - Blue
Impediments - Red
The team’s actual velocity can be tracked during a Iteration as well as Iteration-to-Iteration.
To note, while this isn't anything revolutionary, we did this as an exercise to establish a common definition and description for our team members.
Let me start off with some background context. This past Summer I was introduced to two brainstorming / ideation techniques.
First was SCIPAB, which is an acronym for "situation, complication, implication, position, action, and benefit." It was created by Mandel Communications as a 6-step method to help people communicate in a more impactful manner. (For more information: https://www.mandel.com/why-mandel/tools-methodology/scipab )
Second was a new technique for group brainstorming called the Business Model Canvas. It is a visual chart template initially proposed by Alexander Osterwalder for creating new, or re-evaluating existing, business goals ad value propositions for a product, system, or service. Additionally it is a technique recommended in the Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers ;book by David Gray, James Macanufo, and Sunni Brown ;(For more information: https://en.m.wikipedia.org/wiki/Business_Model_Canvas ).
As I was beginning to understand how each of these two techniques were intended to be used in a professional setting, I noticed a few similarities to other goal-setting and idea-generating methods in which I was already familiar. These other techniques include: SWOT analysis (strengths, weaknesses, opportunities, and threats); Problem-Solution-Benefit model, SMART Objectives (Specific, measurable, actionable, relevant, and time-bound). ;On the flip-side, there were also some unique, differentiating elements to each of these methods.
I had been asked to facilitate a brainstorming/ideation session in late summer, so I decided to create a new model which combined elements from several of these other methods and models.
At the beginning stages of a project, or even a new phase of an existing project, there are ;many challenges. Often one of those challenges is reaching an agreement on the goal or vision for the effort, in other words establishing a common direction. Once a ;common direction in place, then an additional hurdle can be ;communicating it out to all the project team members, stakeholders, managers, and others. Furthermore, for the individuals who will be contributing to the project, the next obstacle might be ;forming a shared alignment. In other words, once the direction has been established (the over used metaphor of the flag at the top of the mountain to ascend to the summit), next is to verify all the project team members are coordinated and synchronized in their work towards the common direction (to use the mountain metaphor, are they all pointing towards the flag with a level of awareness of all the other team members and the path they will take to ascend the mountain). ;
My goal for creating a new model was to focus on a tool to help project team members and stakeholders achieve a consensus for the direction/vision of a project and begin to establish the shared alignment towards that direction. For a technology product, one key element of this is to identify who the primary target audience is for the product. Notice this reference to target audience is singular. Sure a product can have multiple target audiences, but there should be one specific and primary target audience identified.
I introduce to you the "Journey Canvas."
The goals when using the Journey Canvas may include:
Describing the purpose of the project as a single statement, and keeping it aligned to the organization's purpose.
Describing the high-level "current state" circumstances
Identify the complications and implications
What are your key strengths and value propositions?
Who are the key target audience members?
How does the project team (or organization) interact with the target audience members?
What are the key objectives and metrics to gauge success?
What drives your budget (cost and revenue)?
Sections of the Journey Canvas:
1) Frame - a one line statement for the purpose of the product/project. In other words, stating a motto of the project team. This should be aligned with the organization's purpose and vision. 2) Situation - Top 3 "Current State" circumstances 3) Strengths - Top 3 Business/Project strengths; what are we really good at doing? 4) Complications - Top 3 Changes/Pressures/Demands, which are creating problems, challenges, or opportunities? 5) Implications - Top 3 consequences of failing to act... to address the challenges, or seek the opportunities. What is the opportunity cost? 6) Solutions - Top 3 capabilities; begin to generate solution-oriented ideas
7) Unique Value Proposition - Clear, compelling message that states why this project/product are different and worth investment 8) Benefits - Top 3 results (what's in it for the business, stakeholders, target audience/end-users, etc.); what would they say about the solutions (listed within ;section 6 of the Journey Canvas)? 9) Target Audience - Key personas/Users/Stakeholders 10) Channels - Paths to the Target Audience; this can be if validation is needed of ideas, to conduct user research, and/or to solicit feedback from prototypes
11) Key Objectives / Metrics - Specific, Measurable, Attainable, Realistic, Time-bound. What does success look like? How do we know if we achieved success? Key Performance Indicators (KPIs) to measure? 12) Unfair Advantage - Why can't the Solutions (from section 6) be easily replicated, copied, or replaced by competitors/threats? What gives us an upper-hand? 13) Business Model (Costs & Revenue) - How will we make money, and what will be the costs we incur? Will this effort be a loss-leader?
A recommended 3-step approach for using the Journey Canvas:
Individual activity [part 1 of 2] - with each person writing their ideas (1 per sticky note) for the first five sections (approx. time to allocate for the activity 5 minutes)
Individual activity [part 2 of 2] - with each person writing their ideas for the remaining six sections (approx. time 5 minutes) [note, this separation of the sections is based on feedback to guide participants through the activity and focus their attention on a few sections at a time].
Group Activity - once each person has contributed their individual ideas, now the group can perform a card sort activity with the sticky notes in each of the sections. This will begin to help visualize if there are any emerging common themes as well as any distinctly unique concepts. (approx. time 10 minutes)
Lastly, once the Journey Canvas has been completed by the project team, it can serve as a spring board into other activities to build upon and further refine the concepts generated.
Seeking a deeper understanding and a more clearly articulated vision for crafting engaging and aesthetically pleasing user experience and user interface designs, were the goals for crafting this list. Over time this will be an evolving, living document as expectations of users change. An item to note, this shouldn’t be considered a magical checklist, but rather a set of guidelines or tenets.
Over the past year, our UX Team objectives have been:
Foster and energize partnerships with cross-functional teams, especially Software Development and Web Operations, to continually establish trust and a positive rapport to serve as cross-functional peers.
Partner with Software Development to
establish an understanding of GIS fundamentals and of the Core conceptual model to further enhance a story-first approach (such as storyboards & workflow diagrams)
create flexible design patterns to harmonize our products and increase familiarity across the ArcGIS Platform
confidently participate to advance "conceptual-model design," "interaction design," "layout (IA) design," "visual design," and "comparative design"
Produce modern, innovative designs and engaging, user-centric experiences; utilizing research methods for continual validation and regularly observe usability studies
Stay current with latest trends and best practices to advocate forward thinking
Strengthen and enhance the synergy of team, emphasizing a combined collaborative effort with proactive, timely communication
Every aspect of the user's interaction with a product, service, or company that make up the user's perceptions of the whole. User experience design as a discipline is concerned with all the elements that together make up that interface, including layout, visual design, text, brand, sound, and interaction.
User experience (abbreviated as UX) is how a person feels when interfacing with a system. The system could be a website, a web application or desktop software and, in modern contexts, is generally denoted by some form of human-computer interaction (HCI).
What is UX? I've heard some people refer to it in the context of the system or the interface. Are they correct? Or is it more than that?
A definition that I keep going back to for User Experience (UX) is from the International Organization for Standardization (ISO; http://www.iso.org/ referenced as ISO 9241-210). They define it as:
User Experience (n.) - a person's perceptions and responses that result from the use or anticipated use of a product system or service.
So what does this really mean? It's a person's preconceived notions about the product, system, or service before they have even used the system. Perhaps based on information they have heard from other individuals, or based upon their past experiences from other products, systems, or services from the same organization. It's the emotions they bring with them before they've even started based upon their anticipation.
Also, it is their responses as they are using the product, system or service. Is it providing them the information they expect, and when they expect it? Is the product or system doing things on their behalf, but they didn't directly as for it? Is the product or system presenting an error message, but it doesn't make sense? Are they running into points of confusion or frustration?
Let's take a moment to look at user experience from a different perspective, from a software / product development perspective. I often hear that "we need to build the system for anyone to use." I jokingly refer to this as a chicken-little effect. Anyone in the whole world, all 7 billion of us, need to be able to "intuitively" be able to use this system.
The challenge is when we build something for "anyone" to be able to use, you end up building it for no one. So who are we building it for?
We're building it for... (queue the drum roll) ..."the user." ...the who? This mystical living thing often known as "the user."
Sometimes I hear "the user" referred to as you, in first person. Once the system is created and launched into production, if you are the person who will be regularly using the system as well as paying to use the system, then great! If not, then you are not "the user."
At other times, I hear "the user" referred to as your mom. (Hi mom!) Often in the context that the system needs to be so easy to use your mother can figure it out. Now if your mother will be using the system regularly as well as paying to use the system, then great! If not, then sorry mom but you are not "the user."
But what we need to keep in mind is that "the user" represents real people who need to accomplish real tasks. Another way to look at this is by identifying a specific target audience of people.
This reminds me of a quote from Jim Henson, the creator of the Muppets:
Good experiences are invisible... give the audience enough to work with and they will do the rest.
On a side note, it's usually the bad experiences that we hear about. Just as with the infamous Kermit the Frog, people don't usually think about the puppeteer controlling Kermit behind the scenes, they think of Kermit. In parallel to technology, people don't usually think about all the server farms, load balancers, database schemas, and business logic layers; they just think about the interface they see displaying on the screen of their device. However, just as Kermit wouldn't come to life without the puppeteer, in most cases the interface would not come to life without all the programming and system architecture design. But it's the interface that people experience and have an emotional response.
As I'm working on software / product development efforts, I try to keep four principles in mind for the identified target audience:
Minimize / decrease their confusion
Minimize / decrease their frustration
Maximize / increase their productivity
Maximize / increase a positive response
To further elaborate, by "positive response" I'm referring to providing the given target audience with a compelling experience, aka a WOW factor.
Throughout the process, trying to minimize opinionated feedback. It's not what my opinion that matters, or the personal opinion of any member of the project/product team, but rather what really matters is what is in the best interest of the identified target audience who will be using the product / system.
Another quote that comes to mind is from RJ Owen, stating:
Every project... starts with people.
People who will pay for the project. People who will be on the project team. People who will draft the requirements and user stories. People who will design the database. People who will do the coding. People who will craft the user interface and user experience. People who will conduct the QA. And hopefully once that is all said and done, people who will use the product or system (and hopefully it doesn't just turn into an assumption of "if you build it, they will come").
From the user experience discipline, we can validate what we are building with the real people who will be using the product or system. A group of people who belong to the identified target audience. And not to only validate the product or system with the stakeholders who are paying for it. We can achieve this validation by observing real people perform real scenarios and tasks (known as usability studies and ethnographic research) using a proof of concept, a prototype, or something already in production. Once again, doing all of this while trying to minimize opinionated feedback.
It's an ongoing challenge to seek the balance between the needs of the business with your users' real needs. However as user experience practitioners, our goal should be to create extraordinary experiences for our identified target audience.
And, this is why UX is more than just a buzz word.
On behalf of the User Experience and User Interface teams at Esri, we are excited to announce we will be hosting the User Experience & User Interface Summit at the Esri User Conference, on Thursday, July 17th from 10:00am to 4:00pm. This will be the 3rd year for having an event at the Esri UC focused on sharing best practices about user experience and user interface. An important item to note, attendees for the User Experience & User Interface Summit must also be registered attendees for the 2014 Esri User Conference.
Explore the latest best practices and emerging trends in visual design, interaction, information architecture, and user experience. Discover how starting with a "people first" approach can benefit mapping applications and location-enabled apps. Presentations and demos will be offered for all levels, novice to expert, covering a variety of disciplines from developers to project managers.
The work that you do every day is important and we are looking for ways to help you be more productive and efficient (because we know your time is valuable).
During your journey of using ArcGIS Online, we decided to spend some of our time to look at the starting point for that journey. What could we do to help you, our users and customers, to ease into using the product in a delightful and simplified process. Or even, for someone who has never used the product before, how could we help them to "quickly get up and running"?
We decided to craft in-app Guided Tours with coach marks. To quickly define what we mean by coach marks (at least our interpretation at the present moment): small, visual boxes presented within the application containing informational or instructional content, which are unobtrusive and can be dismissed at any time. When we string together a series of coach marks, presented in a sequential manner, each can provide instructional information to complete a specific workflow in a guided tour format.
The basic idea here is: continue to provide strong documentation (such as http://doc.arcgis.com/en/arcgis-online/ ) as well as continue to provide videos (such as http://doc.arcgis.com/en/arcgis-online/reference/videos.htm ). When comparing these to the three learning modalities (http://en.wikipedia.org/wiki/Learning_style#Learning_Modalities, the written documentation targets the visual learning style and the videos target the auditory learning style. Now we are introducing a baseline with the Guided Tours which targets the tactile (kinesthetic) learning style. What we mean by this is, rather than A) read a document, then go to the product and follow the written document; and B) watch a video and maybe hit play / pause regularly) , then go to the product and follow what was displayed in the video; now, C) please lead me through how to use a specific capability within the product itself.
n the previous paragraph we mentioned “we are introducing a baseline” and what we mean by this is, we see this as establishing a foundation for what else could potentially be achieved with coach marks and guided tours.
A group of us (from Product Management team, Software Development team, and User Experience Team) have worked together to craft three Guided Tours, primarily targeted for an ArcGIS Online 101 audience:
Make a Map
Walks you through a series of short steps to quickly build a map and save it, then be able to share with others.
Style Your Map
Guides you through how to change the symbol for a point location on your map (in GIS terminology, a "feature"), then save the map.
Explore ready-to-use Layers
Introduces how to add authoritative information and data to your map, then explore the information.
With the addition of custom roles into the ArcGIS Platform (http://doc.arcgis.com/en/arcgis-online/administer/configure-roles.htm), the Guided Tours will take into consideration the permissions and privileges given to each user account by the Organization Administrator. In other words, some people may see more or less Guided Tour options, based on the privileges in which they have.
The tours appear in the About panel when signed in with an organizational account that has privileges to create items. For the best experience, be sure to follow each step of the tour. Another point to note, with this initial baseline for the Guided Tours, we didn’t want to introduce an experience that would be obtrusive, so the Guided Tour options appear in the About panel without interfering with your use of ArcGIS Online. Therefore each person can choose to take one of the Guided Tours if they feel a particular tour is helpful.
We hope to learn from this to further improve this baseline and see what other ideas come from these Guided Tours and coach marks. If you have any thoughts or suggestions, please share them in the comments below.
We don’t care about support costs or pain from frustration
When we design something for our own use
Works great when:
Our users are just like us
We regularly use it just like our users do
When we’ve previously learned what users need
Works great when:
We already know their knowledge, previous experiences, and contexts
We’re solving the same design problems repeatedly
When we’re designing for new activities unfamiliar to us
Works great when:
We can easily identify the users and their activities
We need to go beyond our own previous experiences
Innovations can come from removing complexity
When we’re designing for the entire experience
Works great when:
We want to improve our users’ complete experiences, in between the specic activities
We can be pro-active about the designs
Game-chaning innovations are the top priority
Thanks to this list of design decision styles, we can use this as a common anatomy language during meetings and other conversations about design, user interface, information architecture, and user experience.
The "User Experience (UX) & User Interface (UI) Summit" has two components:
1) attendees at the Developer Summit can join us for informal discussion topics throughout the afternoon on March 12th covering topics from responsive web design, User Experience + Agile Development, Interface Design, User Research, Icon Design, and more. A full list of the discussion topics is provided below.
2) we've pulled together some of our best designers and developers to present a series of 15-minute Lightning Talks (each starting on the hour and on the half-hour). A full list of presenters is below.
We have hosted a User Experience Summit at the annual Esri International User Conference in San Diego for the past two years and we are pleased to be bringing to the Developer Summit for the first time. Here they will be able to explore the latest best practices and emerging trends in visual design, interaction, information architecture, and user experience. Discover how starting with a “people first” approach can benefit mapping applications and location-enabled apps. Presentations and demos will be offered for all levels, novice to expert, covering a variety of disciplines from developers to project managers. Connect with user experience experts, geek out geo-geek style, and live by the code.
The Esri International Developer Summit is an annual event for the developer community. This year the keynote speaker, Chris Wanstrath, CEO and a cofounder of GitHub, will share his vision for social coding.
Informal Discussion Topics:
What is UX?
User Research & Usability
UX & Agile / Scum Development
UX Deliverables - Diagrams, Wireframes, Prototypes & more
Mobile & Apps
Web & Adaptive / Responsive
Visual, Graphics & Interactive Design
Icons & Symbology
Scheduled 15-minute Lightning Talks:
1:00pm Development and Design Discussion
1:30pm Developing in Context: A Case Study
2:00pm Where design fell FLAT on its face
2:30pm Building great user experieces for location based applications
3:00pm Adding the WOW factor to your interfaces
3:30pm Performance Metrics for End User Experience
4:00pm Organizational Efficiency Using Model Based Design
4:30pm So long sprites, front row fonts!
5:00pm The Design Process: Staying ahead of developers with caffeine addictions
5:30pm Developing User Experiences in ArcGIS Online
The event was held in Pasadena, CA at the Art Center College of Design - South Campus. Today's theme was "Making the World a Better Place" and the three topics/challenges to work towards finding solutions using information architecture were:
LA River Revitalization
LA Transportation Methods (alternatives to automobiles)
Additionally, I was honored to have the opportunity to present and discuss how interactive maps with information from authoritative sources can help to "geo-enable" our discipline of Information Architecture and User Experience through the interfaces we help to design and create. Ultimately we can use the power of location-based information to help us find solutions for real-world issues.
We provided 4 sample maps as a resource for the workgroup teams:
Today a member of our Product Management team (thanks Paul), shared with me an article from FastCompany (on fastcodesign.com). The article, "Move Over Product Design, UX Is The Future," is by Rick Wise, CEO of Lippincott. Wise describes how "experience innovation" is emerging as the new "design imperative."
Key sections of the article which stood out to me:
"We believe that experience innovation will be a crucial component for companies seeking to remain relevant and retain customer loyalty in 2014"
"Don’t ask customers what they need, but observe how they behave and what makes them happy or sad. Then assess what people could do. Think about what they will notice, and what they will remember. Look for the big moves--can you take entire steps out of the process, change the sequence, add new value in unexpected places?"
Products are usually managed by one person, whereas an experience must be curated by several different owners with separate goals and metrics. Drawing on expertise across functions is essential to push thinking, discover what is possible, and forge connections across operational silos. And, before an experience will come across as real to the outside world, dozens, hundreds or thousands of employees need to be educated and empowered to deliver the vision.
"...it’s about how we feel when we use the product or service."
The 3 primary areas of focus for a user experience team includes: Design, Development, and Research
An additional element, as a 4th focus area, to factor in is "business." This can range from product management to product marketing, and sales to strategy. In other words, the business stakeholders for the respective project/initiative.
Our task as UX practitioners is to collaborate with all the stakeholders for each project and find a balance between:
needs of the person (customer) and needs of the business
what aesthetically looks pleasing (design) and what functionally works well (development)
The Esri International User Conference 2013 was July 8th - 12th in San Diego, CA. Throughout the week we had several user experience (UX) activities going on...
User Experience / Usability Research We conducted various user experience / usability research studies ranging from prototypes, to new web sites, to mobile apps.
For the studies related to the prototypes and new web sites, we had a mini-lab set-up in one of the main hallways. The UX Research Lab included a participant/facilitator room plus an additional observation room.
The exterior of the research room.
User Experience (UX) Summit During the afternoon of Wednesday, July 10th we hosted the 2nd annual User Experience (UX) Summit at the Esri UC. We had an excellent attendance of UC attendees. The event was hosted by the Esri User Experience Team and the Esri Developer Network.
This year the format had 2 components: a) eight scheduled 20-min lightning talks from 1pm to 5pm, and b) informal discussion topics, ranging from development to design to cartography.
Stickers with #esriUX
Pillars with the 8 discussion topics:
What is UX?
Visual, Graphics & Interactive Design
UX Research & Usability
UX & Agile / Scrum Development
Web & Adaptive/Responsive
Mobile & Apps
Maps & Cartography
Attendees participating in conversations about UX topics.
One of the eight lightning talk presentations.
We look forward to hosting the event at the Esri International User Conference 2014... and potentially an additional event at the Esri International Developer Summit (March 2014 in Palm Springs, CA)
Please contact me if you or someone you know is interested.
Do you have a passion for creating websites and mobile applications that are intuitive, usable, and elegant? As a UX designer at Esri, you’ll work with developers and visual designers to map out and deliver well-defined user experiences. In addition, you’ll use your knowledge of research principles to conduct usability research and reviews.
Create information architecture diagrams, user experience workflow diagrams, wireframes, proof-of-concepts, and interactive prototypes
Create holistic design solutions that address business, brand, and user requirements
Effectively communicate conceptual ideas, design rationale, and the specifics of user centered design process
Foster collaboration and present cohesive interaction, design, and user experience approaches to a non-design audience
Ensure consistency between the various customer-facing platforms created by Esri
Work in partnership with business stakeholders, graphic designers, and developers to design end-to-end experiences using participatory and iterative design techniques
Act as a UX evangelist, ensuring others understand the value of UX activities and help develop and drive user experience strategy
Stay up to date with new technologies and trends in the web design space
Bachelor’s in human factors, interaction design, psychology, or a related field
A minimum of three years of related work experience in interaction design, user interface design, and user experience research
Experience working with cross-functional teams including business development, product management, and engineering
Strong ability to create information architecture diagrams, user experience workflow diagrams, wireframes, proof-of-concepts, and interactive prototypes
Ability to create pixel-level mockups and/or clickable high fidelity prototypes based on an existing style guide, using tools such as Balsamiq, Fireworks, or Photoshop
Demonstrated ability to work as part of a highly collaborative team to listen effectively, to respect others’ perspectives and contributions, and to offer and accept feedback openly
Outstanding verbal and written presentation and facilitation skills, with the ability to quickly adapt the content to the audience
Organized, able to think beyond what is asked for, and able to juggle multiple projects and competing priorities in a fast-paced, often evolving environment
Experience with internationalizing websites and mobile apps
Experience working in an agile product development environment
Please include a link to your online portfolio or samples of recent work and a link to your blog. Samples must demonstrate design skills and a mix of low fidelity and high fidelity UX deliverables.
When: Wed, Jul 10, 1:00PM - 5:00PM
Where: Room 33 B/C (San Diego Convention Center)
Explore the latest best practices and emerging trends in visual design, interaction, information architecture, and user experience. Discover how starting with a “people first” approach can benefit mapping applications and location-enabled apps. Presentations and demos will be offered for all levels, novice to expert, covering a variety of disciplines from developers to project managers.
Recently I was asked about providing two wizards for a system. One would be for existing users to highlight the updated aspects of the system's interface. The other would be to introduce new users to the system.
However, a traditional wizard provides a separate experience from the system with a step-by-step sequence to complete a procedure. This doesn't help a person learn where elements are within the actual system.
Another suggestion was to provide 2 how-to videos. While these are good additional resources to have, it can be frustrating to... watch a clip, then pause it, do an action in the system, press play on the video, then watch another clip, pause, do an action... etc.
Screen capture from Fishidy.com, showing their Map Tour (step 1)
Screen capture from Fishidy.com, showing their Map Tour (step 2)
In the article, the author discusses using concepts from the 1950s, and the inquisitiveness of a Air Force Colonel named John Boyd to apply towards web/software development. A version of Boyd's sequence for web/software projects is called: OOPA (observe, orient, plan, act).
Boyd's Law of Iteration:
In analyzing complexity, fast iteration almost always produces better results than in-depth analysis.
Dev vs UX: Responsive Mapping Apps for All Devices
Everybody loves mapping apps! Here’s the scenario: You’ve been asked to design and build a web-based mapping application that can work across multiple devices… desktops, tablets, and smartphones. So how do you build a single application that is responsive to all these devices and still provides a positive user experience (UX)? Allan Laframboise and Frank Garofalo from Esri, a global leader in mapping and geographic information systems (GIS), will discuss techniques and methods that both designers and developers can use to create mapping applications for multiple devices while having a positive user experience.
The other day I was asked by a co-worker (something similar to):
When you're developing a system, how do you know when the user experience is good-enough rather than continually trying to improve it?
My response was essentially:
You can certainly get stuck in a trap of wanting to continually improve the system before you ever publish the system. But I try to use three main principals:
For the person who has to use the system, have we decreased any possible causes for confusion while using the system.
For the person who has to use the system, have we minimized any possible causes for frustration while using the system.
For the person who has to use the system, have we provided a solution to enable the person to be productive and efficient.
If the project allows for an agile development process, after each sprint you can conduct a usability study. This can help to validate that the system doesn't cause confusion and frustration for the target user audience.
Now from something that happened today... building a system that helps a person be productive and efficient, while minimizing confusion and frustration, often can pose a development challenge. I specifically chose the word "challenge" in that sentence. At times, what is in the best interest of the person who has to use the system may not necessarily be the easiest to programming, however at the end of the day it should provide a better end product.
For this post, I've decided to link two scientific terms and show their relation... from a user experience point of view.
As defined by Webster, Anthropology is "the science of human beings; especially : the study of human beings and their ancestors through time and space and in relation to physical character, environmental and social relations, and culture" (definition).
One branch of Anthropology is called Ethnography. From a research perspective, ethnography is "the study and systematic recording of human cultures; also, a descriptive work produced from such research," according to Webster (definition). Another definition for it is, "a qualitative research design aimed at exploring cultural phenomena which reflect the knowledge and system of meanings guiding the life of a cultural group" (Wikipedia).
Data collected from ethnographic research is usually by means of participant observation, interviews, and questionnaires. By observing an event occurring or the description of an event, in a scientific manor, is referred to as a phenomena. The study of phenomena is called Phenomenological Research (Wikipedia).
Another way to describe the observation of people while interacting with technology is referred to as "usability studies" (also called "user testing").
In the May 2012 edition of Inc Magazine, there is an article from Jason Fried, co-founder of 37signals, a Chicago-based software company. In the article, titled "You Can Lead a Customer to an Upgrade but can you make him like it? Turns out, it's a bit trickier than we thought," Fried discusses the experience 37signals had as a software company when they encouraged their customers to upgrade to their new Basecamp product version.
Basecamp is a web-based collaboration and project-management tool. As the article discusses, when 37signals released their new version of Basecamp everything went smoothly... for "the tens of thousands of new customers who signed up." However the problem arose when their existing customers were asked to migrate to the new version.
"For them, new didn't mean better. It meant different. And different is always a challenge," Fried states.
The lessons learned: "New ideas take time to get used to." Rather than asking people to transfer to the new Basecamp, they should have invited "existing customer to check out the new Basecamp without encouraging them to make a wholesale switch." Fried suggests for the "need to think as much about customer habits and expectations as they do about design, code, hardware, and the like."
Eventually "with a little handholding, even the most baffled users were able to get the hang of the new software."
View the example with a modern Internet browser (such as Google Chrome), then change the width of the Internet browser size. You will see the content of the app change based on "screen" size detection.
This morning I went for a cycling ride. I was excited because I went a new route, until I realized that my bike GPS was on "pause." Earlier on my ride I had paused it while I stopped for a water break. However, from my own user error I forgot to press "resume."
For the user experience of the entire system... if one part of the system doesn't function as intended, the other parts that are dependent upon the first probably wont function either. In other words, since software is practically always dependent upon the hardware - if the hardware malfunctions or there is a user error with the software... this can result in a bad user experience with both the hardware and the software (...the whole system).
Last week a heard of a new term, which I have decided to embrace: Location Intelligence
On Wikipedia, Location Intelligence is described as:
Location Intelligence is the capacity to organize and understand complex phenomena through the use of geographic relationships inherent in all information. By combining geographic- and location-related data with other business data, organizations can gain critical insights, make better decisions and optimize important processes and applications. Location Intelligence offers organizations opportunities to streamline their business processes and customer relationships to improve performance and results.
I will be attending the Esri DevSummit 2012 in Palm Springs, CA for the first time and giving a demo theater presentation titled "Strategic User Experience with Flex" on Tuesday, March 27th.
Please join me for the demo theater where I will be covering a basic approach to strategic user experience for projects and I will share some examples from projects using Adobe Flex and the ArcGIS API for Flex.
Here is a description I've found myself using quite frequently in the past few weeks. Just to note, this is purely my view and option - this does not necessarily reflect those of my employer.
My employer takes a geographic approach to problem solving to ensure better communication and collaboration for understanding our world. We are more than just a mapping company, we are a geographic information systems company. Sometimes this means viewing your data on a map, sometimes this means viewing your data in a table / data-grid, and sometimes this does mean a combination of the previous two.
Today I came across a white paper on the web site for UX Magazine. The white paper was published by Modius Associates, a digital strategy and design firm, in December 2011.
In the paper, titled "Yes We Can: The Future of Government Online" there are several excellent points made. One section in particular stood out to me, On Page 11, labeled "Law #4: Design around people, not technologies or Org Charts." Here the author discusses keeping a fundamental principal in mind when starting a project: "Know your users and plan everything with them in mind." The author goes on to state "... the single most important thing you can do to ensure the success of your web presence is to follow a user-centered design process."
The primary difference is to not start by focusing on the technical aspects (databases, servers, algorithms). But, to "optimize the user experience around how people can, want, or need to work, rather than forcing users to change how they work to accommodate your system."
The below diagram is from the white paper (pg 11):
In Jakob Nielsen's Alertbox published today he discusses how after 19 years the Thinking Aloud technique for usability testing still ranks #1, according to his research.
Nielsen defines the thinking aloud technique as: "In a thinking aloud test, you ask test participants to use the system while continuously thinking out loud - that is, simply verbalizing their thoughts as they move through the user interface."
Also in the article he discusses the pros and cons of the technique.
At the end of the day, when "all is said and done," if a user experience practitioner is able and empowered to effectively do their job and add value to a project, the client should be happy and the project manager should look good. Now this doesn't always occur because the user experience practitioner, at times, is restrained by factors, such as: development, budget, schedule, and/or other various overriding opinions.
The role of a user experience practitioner is to help project stakeholders visualize and understand the target end-users of the system they want to implement. This includes how the user will access, navigate, and interact with that system. The goal is to never make the user feel puzzled, frustrated, or confused, but rather confident, pleased, and accomplished. In this competitive world, the experience a user receives from a system should result in the user becoming an ambassador for your system - therefore telling others that they should also adopt and use your system.
Using CSS Image Sprites can actually have an effect on the user experience. By properly using image sprites, there can be a decrease in the number of HTTP server requests for your web page. Therefore, the loading time for the web page can be decreased.
Here is a simple example of an image sprite used on this website:
The Esri Developer Network (EDN) has been working on an application to track Jordan Romero and his climb of Mt. Vinson in Antarctica this December. The web application was built using Adobe Flex and the ArcGIS API for Flex.
I assisted the EDN team with aspects of the interface design and user experience.
I've recently been working on a project where there is a specific process a new end-user of the system needs to follow to register with the system. There are three brief and sequential steps that the user must complete in order to use the full capabilities if the system.
While the user is in this sequential, step-by-step workflow there is value in showing the user the number of steps and which step they are currently on. This helps to give visibility of the system through feedback to the user by communicating how long the process is and where they are in the process.
This follows two items in Jakob Nielsen’s "Ten Usability Heuristics:" 1) Visibility of the system status and 2) Match between system and the real world. Additionally, this follows two items in Don Norman's "Design Principles:" 1) Visibility and 2) Feedback.
Progress Indicator Examples: (shown are the three different steps, each highlighted once)
The progress indicators should be hidden once the user has completed the workflow steps, if they are able to return to those same interface screens during the regular, re-occurring use of the system and not led through the entire workflow process. In this scenario, the progress indicators represent the sequential process and now during the on-going use the workflow process is no longer necessary.
ALT text and tooltips typically appear when the user moves the mouse cursor to hover over an interface element. These can be very helpful. In fact, for Section 508 Accessibility compliance, these are required.
However, using ALT text and tooltips as a primary method to communicate a message to the user is a recipe for disaster.
The "ArcGIS Viewer for Flex - Application Builder" was released recently. This was one of the first projects I've worked on since joining Esri. I was called in to help with the user experience of the Application Builder. Based on initial prototype that had already been developed, here is a rough outline of the steps we took:
1) held a UX Storyboarding Workshop (thanks Bjorn for seeing the value in it);
2) reviewed the protoype's UX / UI;
3) took the prototype through a round of usability testing (thanks for your help Neal);
4) drafted wireframes for all the interfaces;
5) created color compositions for the new visual design;
6) generated Flex component skins with Adobe Flash Catalyst
Here are links to download the Application Builder (for free) and review the documentation:
Tuesday Google announced a new menu bar as part of the larger redesign initiative. The classic navigation bar, black bar across the top with the most common links (Gmail, Web, Images, etc) is going way. Now each of those options will be nested in a compound drop-down menu under the Google logo.
There are several pros and cons about compound drop-down menus. On UseIt.com, Jakob Nielsen has two articles about "mega menus."
I recently read an article by Matthew Ericson, Deputy Graphics Director at The New York Times, about using maps to communicate information regarding data that is geography based.
Ericson uses two examples from the NY Times about how information presented on a map could cause more confusion that communication. One example is from the 2008 election and the other is from flooding in New Orleans from Hurricane Katrina.
Overall, to effectively communicate information, in some situations, a map may not be enough and may need to be paired with a table, chart, and/or graph. This pairing can provide both spatial reference to the data as well as to analyze the data for patterns.
Pandora has launched a new interface for their free user accounts (it was rolled out to the paid-accounts a couple of weeks ago).
The album art is now displayed larger with two song album covers by default, however with a drag handle you can increase or decrease the size of the album for the current song and there show/hide album art from recently played songs.
I also like the added option to select "I'm tired of this track" for a particular song, in addition to the standard like and dislike.
I've joined the Interaction Design Association (IxDA). Their self described mission is to improve the human condition by advancing the discipline of Interaction Design. They go on to define "interaction design" as the structure and behavior of interactive systems.
This presentation is based on a presentation at SxSW 2011 by:
Rachel Evans, Intuit
First of all, I don't consider myself a project manager. However, I decided to make
a blog post that combines typical project management life cycles with common user-centered design methods.
Making use of these
UCD Methods earlier in a project can help to uncover potential issues while still at the "blueprint stage" instead of finding potential issues
during the "construction stage" (In other words, it's easier to add a door to a wall with a pencil and eraser while its on the drafting table,
rather than once the wall has been built at the construction site).
I've commonly found that those outside the disciplines of UCD/UX
occasionally confuse "usability testing" and "user acceptance testing." Below are the Wikipedia definitions for both:
Testing is a technique used to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it
gives direct input on how real users use the system.1 This is in contrast with usability inspection methods where experts use different methods
to evaluate a user interface without involving users. Usability testing focuses on measuring a human-made product's capacity to meet its
intended purpose." Source
"User Acceptance Testing
(UAT) is a process to obtain confirmation that a system meets mutually agreed-upon requirements. A Subject Matter Expert (SME), preferably the
owner or client of the object under test, provides such confirmation after trial or review. In software development, UAT is one of the final
stages of a project and often occurs before a client or customer accepts the new system." Source. User Acceptance Testing is also referred to as Holistic Testing.
In my opinion, there are two primary differences between these two processes. First, Usability Testing involves an expert facilitating actual end-users performing specific tasks with a system / application. Where as User Acceptance Testing involves a trial / review conducted by a
subject-matter expert. Second, User Acceptance Testing typically occurs near the conclusion of a project. On the other hand, Usability Testing
should occur as early as possible in a project. This can include performing a usability test on a paper prototype ("mock-up") and/or
interactive prototype. However, Usability Testing can be conducted at any stage of a project, even after a project has concluded. In some of
these instances, a usability test can be used to compare two versions of a system / application.
The intention of this post is
not to down-play User Acceptance Testing. There is a very specific purpose of User Acceptance Testing. Rather the goal is to highlight the
differences between these processes.
However, one paragraph of the article especially stood out to me. For quite some time now I've been looking for a way to justify usability improvements through a financial context. Now, thanks to Jakob, I can reference his article and the ROI for Usability formula.
Nielsen describes the formula as "the annualized value of a design improvement that saves t minutes in time-on task." In other words, by reducing the time end-users (such as employees) spend on a task can save an organization money through
increased productivity and efficiency.
T = minutes decreased completing a specific task
E = number of end-users who perform this task
N = number of times per year a typical end-user performs the task
S = average end-user salary / compensation per minute
Now multiply: T x E x N x S = Dollar amount in potential savings through usability improvements.
T = 10 minutes decreased completing a specific task
E = 1500 end-users who perform this task
N = 520 times per year a typical end-user performs the task (10 times per week)
S = $0.401 average end-user salary / compensation per minute (based on avg salary of $50k and 40-hr work week)
Calculate: 10 x 1500
x 520 x $0.401 = $3,125,00.00 in potential savings through usability improvements.
The UX process is usually
a creative, exploratory process as you and your fellow project team members go through brainstorming sessions. When iterating through the
process, a variety of artifacts are typically created. As ideas and concepts are eliminated from a project, don’t discard those ideas or the
related artifacts archive them instead. By archiving the various artifacts of each project, the ideas and concepts generated throughout the
life of the project are not discarded and lost. The ideas can be retained and potentially reevaluated for use in future projects or as a
starting point for further ideation in future projects.
Early in a project, you and your team may start to exchange concepts
through dry-erase board sketches and paper sketches. Capture those ideas and retain them as digital artifacts by taking digital pictures of the
board sketches and making scans of the paper sketches. This also applies to any other artifact generated throughout the entire process that is
not originally in a digital format.
Most organizations have a method for documenting the UX specifications for a project. These
documentation methods usually focus on what is to be included in the project. As you and your team continue to iterate on the specifications
through the life of the project, some ideas will be removed. For example, an entire use-case description might be determined to not be
significant enough to be accounted for in the project, so the concepts related to that use-case are “scoped out” of the project. However,
don’t discard the related artifacts that have been already generated. Those ideas, though not implemented in the current project, could be a
viable solution for another future project.
Although, what is included can be equally as important as what has been considered
and determine to not be included in the project. This documentation can be useful, perhaps as an appendix to the UX specifications, to
highlight decisions made during the UX process with a brief description as to why it was not included in the project. If someone later asks why
a design was made in a particular manner, you will have documentation to reference regarding the other concepts considered and the reasoning
behind the decision made.
An excellent tool for archiving these artifacts is a wiki (http://en.wikipedia.org/wiki/Wiki). Most wikis maintain a change log for content, and also have
tagging and searching capabilities. Each artifact can be associated with the specific project within the wiki as well as tagged with common
terminology across all projects. Digital scans of sketches and other documents can be tagged with, for example the project name as well as a
“scoped-out” tag (certainly other tags could be created as well). These tags can then be used in searches within the wiki. This archiving
process effectively generates a Knowledge Management Repository (http://en.wikipedia.org/wiki/Knowledge_management) of both concepts used in
projects and concepts eliminated from projects.
From the lens of Knowledge Management, this method of capturing what has and may
have not been implemented offers an organization the ability to collect the ideas, concepts, and knowledge of their employees into an organized
Yesterday I read an article on the UX Magazine web site by Stephanie Arnold, Executive
Director of User Experience Design at AT&T Interactive, titled, "UX: Don't Hate, Participate." Arnold shares her thoughts on how she has
strived to establish relationships across different teams within AT&T Interactive. Several of the methods she describes also reflects several
methods also promoted and recommended by presenters at SXSWi 2011 - including Steve Krug, author of "Don’t Make Me Think" and "Rocket Surgery
Arnold starts off by describing the importance of establishing strong, trusting relationships between the UX team and
other teams within the organization. She states “other teams will trust and depend on your team more when they understand your process and
feel like they are participating.” This is an important aspect of the relationships between the teams. When members of the various
cross-functional teams feel like they have contributed towards the end result of a project, plus receive credit for their contributions, then
trust can begin to be built among the team members. She also highlights that including members of "other teams into the UX process allows you
to ensure that your designs are built and reviewed with different lenses and perspectives."
She pin points three primary
cross-functional teams, in addition to UX: the executives, the product team, and the developers.
Usually have time/bandwidth constraints, so keep them involved at a high-level but don’t burden them with
too many in-depth details.
Provide updates that reflect results and returns for the organization.
Data for a creative
process can be provided through Usability Testing results. Arnold states: "We invite the entire executive team to weekly usability sessions…
after the session are run, I share our high-level findings in a weekly readout, further, twice a month we review our most recent design comps
with the CEO..."
One key item to point out, which I as well as other UX professionals agree with, is the method of conducting weekly
user testing sessions and, as Steve Krug says, "make it a spectator sport" - get key stakeholders of the project to attend the
Arnold's summary for The Executives: "The trick with this group is to use their time efficiently. Get to the
point. Show them data. Don’t inundate with details, but show progress. And definitely find a way to keep them informed and
The Product Team
These are the individuals usually in the trenches along side of
Build constructive participation from the product team into your UX design & research process through constant
When starting a new project, hold kick-off meetings with the product team.
When brainstorming and
iterating through ideas, wireframes and design comps - invite the product team to join in the discussions.
If a strong relationship
can be established between the UX team and the product team, and members of both teams are comfortable with meeting informally to collaborate,
then the need for formal, scheduled meetings may be able to decrease.
Invite and insist that the product team attends usability
testing sessions. Furthermore, invite them to actively participate in the planning process for the usability testing to determine what is
Invite them to participate in the testing debriefs to review the results of usability testing and make recommended
Through all the active participation, product teams are able to observe firsthand the reasoning behind decisions
made by the UX team to further fine-tune their product.
Arnold's summary for The Product Team: "Communicate regularly. Establish
collaborative relationships. Invite them to take part in brainstorming. Give them a peek into what has motivated your design decisions
(usability, outside research, competitive research, etc.). Treat them as a partner in UX, and not as an outside
Just as with the product team, the relationship between the UX
team and the development team is "most successful with a lot of communication and collaboration."
"Usability testing is valuable to
the developers… it is one of the only times they are able to get insight into end users, and it allows them to see the product through a
completely different lens than they are used to." The can see both the success of testing participants using the product as well as the issues
where participants come across challenges and issues.
Invite them to attend the usability testing sessions, as well as the
post-testing debriefs (same as with the product team).
Invite developers to brainstorming sessions (especially early in the
process) and reviews of UX deliverables - this provides another perspective on the product design. By "involving them early in discussions
allows you to explore new ideas as well as get a reading on the viability of your UX solutions." I would take Arnold’s statement a step
further and say not only the viability of the UX solutions but also a timeline to have the potential solutions included into a release cycle
Arnold’s summary for The Developers: "Communication. Show and tell. Collaboration and brainstorming. Involve
them early and utilize them as a sounding board for potential ideas and solutions."
Arnold goes on to discuss the
common threads that runs throughout each of the teams.
"Hone in on the language that each team speaks when they view
Determine which UX deliverables are most important to each team - research results, wireframes, comps,
"Usability testing is invaluable for cross-collaboration. Urge participation from any and all groups ...to fully appreciate
the value that usability testing brings to the organization, it is imperative to watch it firsthand."
I couldn't agree more
with Arnold's statement. Anyone and everyone involved with the project should make all possible attempts to attend usability testing for that
project. Seeing challenges users may experience firsthand is more valuable than being told about the challenges. Plus, when the user has a
positive experience, as Arnold suggests earlier in the article, provides a sense of accomplishment to the project
Overall the most important aspect of all of this, as Arnold concludes her article with, is relationship
building. Collaborate with all the project members and strive to institute an environment of constructive participation where ideas,
suggestions, and critiques can be freely shared. Work towards having all the project members feel like they have contributed to the project's
design to hopefully generate buy-in for the solution from all involved.
A concept that I started thinking about today I'm calling "UX R&D." The principle behind that concept comes
from the notion that user experience really is a "research and development" process. Some of the inspiration behind this concept came from Jeff
Gothelf's presentation called "Lean UX" at the SXSW Interactive 2011 conference. I agree with Jeff's "Lean UX" concept, as I further share
details of his presentation on another blog post.
In Jeff's concept of "Lean UX," he defines it as
"Inspired by Lean Startup and Agile development theories, it's the practice of bringing the true nature of our work to light faster,
with less emphasis on deliverables and greater focus on the actual experience
being designed." Jeff emphasizes "true nature" and
"actual experience" -
he states that these are really the same thing, the true nature of the
work done by a UX professional is trying
to determine the actual
With this "true nature" to determine the "actual experience" is very much a research and
development process. The order of the words need to play the childhood game of leap frog and constantly swap order, as this is an iterative
process to determine the actual experience. To expand on Jeff's Lean UX process here are some thoughts on a UX R&D process:
Concept - research the actual problem of the customer, research how your solution will have the vision to solve the customers'
Jeff defines "Lean UX"
as: "Inspired by Lean Startup and Agile development theories, it's the practice of bringing the true nature of our work to light
faster, with less emphasis on deliverables and greater focus on the actual experience being designed." Jeff emphasizes "true nature" and
"actual experience" - he states that these are really the same thing, the true nature of the work done by a UX professional is trying to
determine the actual experience.
The Lean UX process:
paper, coded, etc.)
Validate Internally - talk to stakeholders, managers, dev team, business analysis
Learn from user behavior
Get to the "just good enough" phase quickly and iterate on it. Post your concepts, wireframes, sketches in
public where people can see it to get feedback.
This diagram depicts the benefits feedback can
provide to help achieve meeting the objectives of a project. (Image Source)
Lean UX is
Lazy - "...the best part ...is that the team is doing a xxxx-ton of UX. They document a ton of stuff explicitly
on the walls and implicitly in shared understanding among team members." ~Austin Govella
The only thing being removed is
This is NOT design-by-committee.
Lean UX is...
Control - don't need
"The Spec" to keep control; "Keeper of the Vision" to show work early and show work often
Feasibility - make sure it can be built (and built well); talk to the developers regularly and
frequently; prototyping - focus on the core flow to focus on what the customer needs and what the business needs; validate it with your
customers and demo it to your team; the prototype becomes the documentation (to minimize additional documentation)
Test Frequently, Test Cheaply - show the prototype to your customers; schedule regular user testing sessions with about 3 people each week -
keep it light and cheap; show them a sketch on a napkin, a prototype, etc.
Fill in the Gaps - What did you not think about? The
more you talk about it the more you get critiqued to realize what is missing from the experience. Iterate forward.
This document shows the different interpretations of information, however through having visual sketches and
wire-frames drafted, shared, and iterated can help to reduce miss communications. (Image Source)
Jeff goes on to describe how this model can be accomplished...
Internal software/web design shop:
"You are in the problem-solving business and you don't solve problems with design documentation. You solve them with elegant,
efficient and sophisticated software.
Agencies are in the deliverables
Get members of cross-functional teams to sketch together
Cross-functional team, get everyone involved early
Everybody draws, presents and
Refine ideas through 3 rounds
Generate tons of raw ideas
Huge head-start for UX
Early team-wide alignment
Team-wide feeling of ownership & buy-in
Lean UX is a team-based model -
having transparency, building trust. Designers may be the largest obstacle. This is not a revolutionary concept, it's an evolution. Get
back to the experience design business and out of the deliverables business.
I attended a presentation from Google's Marissa Mayer on Fri, March 11. She
showcased several new features / products / services / projects from Google - most of which are focused on location-based technologies
especially for mobile. Here are a few:
Vector-based maps for Google Maps for Mobile
Traffic Avoidances for Google
Google Places "Hotpot"
Google Art Project
New Augmented Reality
Combining data captured from location, calendar, weather, etc.
Next Thursday I will be traveling to attend SxSW 2011 -
Interactive. This is my first time to attend this conference and I'm looking forward to it. Throughout the conference will be posting to this
blog and on Twitter (@fgarofalo). If you're going to SxSW, send me a tweet.
Quote from Aza Raskin: "You are iterating your solution as well as your
understanding of the problem." In other words, through each iteration of a concept and a prototype you are able to better understand the
challenge you are trying to solve.
A system, regardless of being desktop-based or web-based, needs to always
provide the user with a sense of what the system is doing. Here are some example scenarios:
system is loading information and the user needs to wait for that information to be loaded, provide a progress bar of the percentage complete.
Providing a numerical or visual indication of the amount completed is better than just an arbitrary animation.
If the device just changed data such as added data, updated data, or deleted data, inform the user that it was successfully
These concepts follow the six design rules from "The Design of Future Things" by Donald
Provide rich, complex and natural signals
Provide a good conceptual
Make the output understandable
Provide continual awareness, without annoyance
mappings to make interaction understandable and effective
This article is a combination of user testing and user experience. I
don’t mind filling out surveys for companies wanting feedback. Being in the user experience industry and knowing the value of customer
feedback, I’m willing to share my opinion. However, all too often when I’m completing a web-based survey an indication of my progress in
the survey is not provided. This lack of information is an extremely frustrating experience. At times, I’ve exited out of a survey after
completing page 10 of a survey and not knowing how many more pages exist.
To solve this issue, communicate to the user with an
indication of where they are in the process of completing the survey. This can be accomplished in a variety of formats, such
Numerical / Percentages
Simply state either “Page 3 of 10” or “30% Completed”
methods are easy to implement, from both a design perspective as well as a development perspective. To the user, this provides a sense of
location of where they are in the process. If you are concerned with providing this information because of the length of your survey, then you
may need to re-address your survey content.
A friend of mine and fellow web developer, David Auble (Twitter: @dauble), shared with me an article he found on UXMovement.com titled "Why Your Form
Buttons Should Never Say Submit."
This article discusses how an interface appears more friendly to a user when the terminology
labeling a button is more related to the action that occurs as part of the user's task instead of labeling the button simply as
I've been trying to do this more as I've been building interfaces.
"Treating Users as Customers: Designing the end-to-end" (what a
brilliant concept), is the title of an article by Steve Workman, a consultant at PA Consulting Group in London, UK. Workman begins his article
with a discussion about how for web designers it is easy to divide elements of the user interface and/or the user experience into small parts.
He states: "Breaking an experience into small parts allows the details to be worked through and perfected." This is true. However, only looking
at the situation with a magnifying glass can miss details seen at the big picture level, as Workman describes: "It's rare that web designers
think of the bigger picture - not just the end-to-end journey of a user, but the entirety of a customer's experience." The full span of the
customer experience can take numerous weeks to occur, or "it can be as immediate as someone being told about an app, downloading it, playing
with it for five minutes, and leaving a review." I strongly agree with Workman's point of: "...the need for designers to think big in order to
deliver customer experience has never been so important."
The path a customer takes to arrive to your user interface can greatly
affect the expectations they will have of your interface/system. Workman breaks these path/expectation combinations into three categories, to
Search gives the lowest expectation because relatively little information is contained within search
Advertising often paints a rosy picture of products or services so expectations are higher.
networks produce the most realistic expectations, as this is the only channel where both negative information and independent praise can be
Trying to match what a customer is expecting with methods to develop the interface/system to meet those
expectations, UX professionals usually turn to generating use cases. Workman states:
Many designers simply view this
touchpoint as a single use case, and attempt to group people into buckets to predict what they will do. If customers expect more than a use
case can describe, it is entirely possible that they won't be happy with a product or service - their expectations won’t be
With the increased number of web sites and mobile apps available on the web, customers' standards for customer
support have also increased. I agree with Workman's thoughts on this:
A few years ago, a frustrated customer would simply
sigh and give up on a difficult product, or try to accomplish the same thing using another service. More recently, though, people have been
treating web sites and "garage-made" apps as if they were products from multi-national corporations, expecting the same level of service from a
one-man band as they would get from their electric company.
This is now presenting one-man bands as well as companies of
all sizes with several new challenges; "...expectations for support are also going up, often faster than the companies can keep up with," says
Workman. He goes on to make the observation, which I agree with, of "...many companies, both large and small, are not providing the same
quality of customer service that they provide for their core services as for their mobile apps... they make the mistake of assuming their
application is good enough and their customers are technically savvy, so they don’t have to put much effort into customer
Looking at the big picture there are several actions that can be taken to improve the full experience of interacting
with a company. Workman describes this as:
The customer's experience must be considered at all stages of UX design; the big
picture should always affect in the design of the small picture, as each touchpoint in the ecosystem is crafted. Marketing teams must be
involved in designing the customer experience, so that the holistic experience of using a service or interacting with a company conveys the
right message every time.
Once again, the discussion leads towards collaboration with user experience, information
technology, marketing, operations, and customer support. Customers today are expecting an open dialogue with a company to resolve any issues
they may encounter. Not only are customer support departments being called upon to help resolve these issues quickly, but information about the
issues need to be communicated efficiently to the other departments within the company so that the company can learn from these issues and
better respond to the customers' needs thus moving towards the continual goal of providing the best experiences.
I'll wrap up
this post with the last paragraph from Workman, which ties the idea together very well:
Thinking of the customer experience,
rather than just the user experience, leads to a more complete product, one where customers’ expectations are met before, during, and after
their journeys. Thinking of the big picture leads to happier customers, not just happier users.
This past weekend I had the opportunity to see Disney's TRON: Legacy movie (http://disney.com/tron/). The storyline overall was good, however two quotes from the movie
stood out to me (and even made me laugh):
"I'm a user, I'll improvise" ~Sam Flynn (Garrett Hedlund)
fight for the user" ~ Tron (Bruce Boxleitner)
The first quote (as is the title of this blog post) especially stood out
to me. As I've mentioned in other blog posts, one most recently "Information
Architecture," users will come up with their own use cases for a product or a system. Just because a designer, developer, or UX
professional planned for a product or system to be used in a particular manner, doesn't mean that once in the hands of the end-user, that is
how they will actually use the system.
What does this mean to a UX professional...
Plan for the
Give users options instead of making decisions for them
Collect data / feedback whenever possible about how
they are using the system to better understand the end-user
Harley Manning, Vice President Research Director for Customer
Experience at Forrester Research, sat down with UX Magazine for an interview regarding "Making User & Customer Experience a Business
Competency" found the thoughts Manning shared to be very interesting and quite accurate.
Manning defines customer experience
(CX) as "the perception that customers have of their interactions with your organization." In comparison to user experience, customer
experience is the perception of the interaction your customers have with your organization from start to finish (product packaging,
advertisements, customer support call centers, products, services, web site, etc.); whereas, user experience is the perception of the
interaction your customers have with an interface your organization is associated with (such as a web site or a software device). According to
Manning, companies are starting to see that marketing, IT, business, customer support and design are not separate silos on an organizational
chart but rather are interconnected in the eyes of the customer.
When assisting a current customer to resolve an issue, it is one
thing to determine what happened to cause the issue. However, to dive in deeper it is another thing to ask how the customer perceived what
happened. This is where underlying details can be captured about the customer’s opinion of not just their user experience, but rather their
thoughts on your company’s brand as a whole.
Planning, designing, developing and building the user interface
for a system has a plethora of parallels to constructing a house. Just as an architect for a house needs to plan the structural support for
the house as well as the aesthetic design of the house, the same applies to planning the user interface for a system. Planning must occur for
the functional development of the system, as well as for the aesthetic design of the system. But it isn't just that simple. There are business
and consumer needs which factor into the equation, so the architect has to work within the threshold of the construction company's needs as
well as meeting what the new home owner will want. Again, parallels exist from an architect for a house to planning a user interface.
Considerations for the user interface need to be made for the business needs as well as the needs of the consumers. Overall, throughout the
process there is a concept lying in the center trying to find this balance; that concept is called "information
The two primary items on either side of the balancing act for information architecture are 1) creative design, and
2) functionality / interaction. The other smaller players in the game at varying levels can typically include, but are not limited to:
marketing, software, engineering, language translations, copy writing, and upper-management.
Planning for Information
When building a house, there are usually blueprints, material lists, schedules/timelines, and budgets. The same
documents need to be generated when building an interface. Each of these documents are very important to have listed and detailed. This allows
the key stakeholders for the project, in addition to the individuals actually working on the project, to know exactly what needs to occur.
Sounds like another field is involved here… called project management. However, for this discussion I'm not going to focus on project
management in relation to user experience and/or information architecture. Let’s further dive into the process of drafting blueprints in
regard to information architecture. To quote renowned architect Frank Lloyd Wright, "You can use an eraser on the drafting table or a sledge
hammer on the construction site." Planning and concept development are essential, or perhaps you need to invest in a large quantity of sledge
hammers (which from another aspect could result in a low morale among workers since now they are tearing apart what they just built).
User Experience vs Information Architecture
The two concepts of user experience and information architecture
go hand-in-hand. However, if a "high-level" of one exists, that doesn't automatically mean that a "high-level" of the other will exist. I
think Oliver Reichenstein, co-owner and manager of Information Architects (MA Philosophy; former senior brand consultant at Interbrand),
describes this well in his following quote: "Architects design houses that lead to a spectrum of experiences, some foreseen, some not. But they
do not design all possible experiences one can have in a house." In other words, an extravagant house can be designed and constructed; however,
just because the architect designed for a room to be the dining room, the home owner could place a billiards table in that space instead of a
dining room table.
The same is true for user interfaces. A quality interface can be produced with excellent information
architecture, however all the possible use cases that could occur when in the hands of a consumer are almost impossible to conjure up. Yes,
I'm stating that in my opinion, even a leading user experience expert would be challenged to account for all possible use cases for a given
product or system. Although, through user testing and observing individuals, better use cases can be generated. To further explain, just
because a team of designers and developers define a list of use cases, this does not mean that the consumer will use the system exactly as the
use cases had described. This introduces a whole other topic where I've observed numerous occurrences of users essentially forming "hacked"
methods of using an interface or system to achieve what they want the system to really be able to do in comparison to what the designers and
developers plan with the use cases.
During the blueprint phase of planning, designing, developing,
creating, and/or building a user interface, try to work out as many ideas and issues as possible. Build prototypes to test the concept and
observe people interacting with the prototype. This is a cyclical, iterative process… make changes with a "pencil" and try to reduce/avoid
the need for a "sledge hammer."
Find a balancing between what is visually pleasing on the screen and what is a natural
interaction… in other words a middle ground between creative design and functionality / interaction with the goal to achieve a strong
Susan Weinschenk, a psychologist shared her thoughts on user experience design
with UX Magazine in a November 2010 article. She started off by sharing the following story, which I think is worth
A king brings six men into a dark building. They cannot see anything. The king says to them, "I have bought
this animal from the wild lands to the East. It is called an elephant." "What is an elephant?" the men ask. The king says, "Feel the elephant
and describe it to me." The man who feels a leg says the elephant is like a pillar, the one who feels the tail says the elephant is like a
rope, the one who feels the trunk says the elephant is like a tree branch, the one who feels the ear says the elephant is like a hand fan, the
one who feels the belly says the elephant is like a wall, and the one who feels the tusk says the elephant is like a solid pipe. "You are all
correct", says the king, "You are each feeling just a part of the elephant."
This story highlights how individuals will
have different perspectives, even of the same shared experience.
Weinschenk broke down her thoughts into the following
People don’t want to work or think more than they have to
For this point, I especially liked her
discussion on: "Only provide the features that people really need. Don't rely on your opinion of what you think they need; do user
research to actually find out. Giving people more than they need just clutters up the experience." Guessing what your user wants versus
listening to what your user wants can provide two very differing solutions - I would wager that the "guess" would be the fastest to fail.
People have limitations
Here is another point I enjoyed: "People prefer short
line lengths, but they read better with longer ones! It's a conundrum, so decide whether preference or performance is more important in your
case, but know that people are going to ask for things that actually aren’t the best for them.
Weinschenk states: "Preventing errors from occurring is always better than helping people correct them once they
occur. The best error message is no message at all." I could not agree with this more.
Human Memory is
Here Weinschenk shares: "People reconstruct memories, which means they are always changing. You can trust what users
say as the truth only a little bit. It is better to observe them in action than to take their word for it." I'm glad to see another
expert who agrees that it is better to observe users rather than listen to them. I believe that people are fundamentally bad at communicating -
expressing to others what they have and what they want.
People are social
"People look to others
for guidance on what they should do, especially if they are uncertain. This is called social validation (http://en.wikipedia.org/wiki/Compliance_(psychology)#Social_validation). This is why, for example, ratings and reviews are
so powerful on web sites," states Weinschenk . Hmmm... I wonder why Facebook and Twitter are so popular - it's all about seeing what others
are doing and making decisions based upon that social interaction.
For this point,
Weinschenk describes attention as one of the primary factors to "designing an engaging UI." She goes on to say: "Grabbing and holding
onto attention, and not distracting someone when they are paying attention to something, are key concerns."
People Crave information
Here is another one of the points I enjoyed most: "People need feedback. The
computer doesn't need to tell the human that it is loading the file. The human needs to know what is going on." I've heard others in
the industry say something to the point of "well the user can wait" ...ok, tell the user why they are waiting, that we are processing something
and will have it available to them in a moment. Then a response I've heard is "but then it might show the user that we are slow at doing the
processing" ...I would counter that statement with "so you would rather have the user wait for the processing to complete without knowing why
they are waiting?" Talk about frustrating your users.
On this point, Weinschenk also states "People will often want more
information than they can actually process. Having more information makes people feel that they have more choices. Having more choices
makes people feel in control. Feeling in control makes people feel they will survive better." I totally agree with Weinschenk, while there is
challenge to not overload the user with information, giving them choices is always preferred rather than picking something for them.
"Most mental processing occurs unconsciously," states Weinschenk. "People's behavior
is greatly affected by factors that they aren't even aware of ...called framing."
People Create Mental
"In order to create a positive UX, you can either match the conceptual model of your product or web site to the users'
mental model, or you can figure out how to 'teach' the users to have a different mental model." I'm not usually a fan of teaching a user
something new, unless it is a novel concept. To further explain myself, I've heard over and over again, well the user can learn what this
"star" icon means - the symbol of a "star" is used throughout a variety of interfaces for a multitude of meaning and now you are wanting to add
yet another meaning... I'm not a fan of that. Whenever possible, I agree with Weinschenk that it is better to map your product or web site to
the users' mental model (how do you know what the users' mental model is you ask… through a thing called user research).
This point simply highlights points about colors, fonts, and positioning. Weinschenk
recommends, as I agree with, the use of "groupings to help focus where the eye should look ...things that are close together are believed to
In an article by Aza Raskin (Creative Lead for Mozilla Firefox) on the UX
Magazine web site, titled "How to Prototype and Influence People," Raskin shares some thoughts on prototyping that I found
Raskin states: "The goal of a prototype is to sketch an idea and to inspire participation: you are creating a
The Principals of Prototyping, as suggested by Raskin, are:
Your first try will be wrong. Budget
and design for it.
Aim to finish a usable artifact in a day. This helps you focus and scope.
You are making a touchable
sketch. Do not fill in all the lines.
You are iterating your solution as well as your understanding of the
Treat your code as throw-away, but be ready to refactor.
Tell a story with your
prototype. It isn't just a set of features.
From these principals, I enjoyed #1, #4, and #7. I especially enjoyed #4,
when problem-solving with issues related to UX / UI / UCD, through each iteration of a concept and a prototype you are able to better
understand the challenge you are trying to solve.
I recently came across an article on the UX Magazine web site by Alexander
Negash titled, "The Evolved User Experience: Using social media technologies to drive UX design and product strategy." I found several points
from Negash to be very valid.
Breaking traditional approaches He starts off by discussing how in today's market
a product can fail just as quickly as it is released to the market. The failure to have a successful launch can be caused by the product being
"either less than useful and engaging or isn't innovative enough." He goes on to suggest that the root of this problem for many companies
appears to be inability to "break away from more traditional approaches to product design and development process... this often means they
design complex features that are dependent on a single big launch, but consequentially companies can't predict and design for future changes
in user behavior trends." It's to no surprise the number of companies who can't break out of the old mindset. My suggestion, which
isn't novel, would be for companies to launch a product that can last for years with the built in capability to push software updates to it...
sound like a familiar concept? (perhaps, among other products, just like software updates pushed to smartphones).
From listening to reacting Listening to your target audience on a day-to-day basis can certainly generate fresh
ideas, as Negash highlights. One of the main benefits is the ability to capture changing user behaviors so that over time your organization can
become better at predicting user behavior. I completely agree with Negash's statemen: "the difference today is that social technologies enable
ongoing user interaction with the product in real time, allowing product designers to vet ideas with users, and learn from users' concerns and
Empowered users Negesh describes how social media has empowered users in ways
unlike in the past with new avenues to "consume media, do business, and share information." In other words, the target audience of your brand
no longer consists of "passive consumers," they now can take ownership in your brand and their experience of your brand… plus share it rather
quickly with their friends, both the positive and the negative. Nagesh also suggests that UX teams need to collaborate with other divisions of
their company that may already have established communication methods with social media technologies. Collaboration is always a good thing.
However, from what I've seen the other divisions (most likely in this cause some combination of marketing, communications, and PR) seem to use
social technologies to push out messages from the company. The UX team needs to use social technologies to at least listen, or better yet a
Incorporating feedback into development cycle With the ability to capture feedback from
your target audience and adapt to changing user behaviors, as Negash points out "social technologies can allow UX teams to quickly and
iteratively inject fresh ideas throughout the development cycle, enabling them to move faster to match the more agile product development
cycles." This is a very good point. I have seen several companies move towards adopting some of the more rapid development cycles, such as the
Agile model. Therefore UX teams need to find ways to be compatible with these models. They are challenged to find the balance between what the
user wants, what the business wants, and to make the concept become a reality within the timeline of the development cycle.
Showing a business value Proving the value and benefit of using social media technologies to the business can be
challenging. One of the playing cards in your favor is that for the most part, social media technologies are free to use. I agree with
Nagesh's statement: "UX teams need to evangelize the value of user insights to enhance the user experience and the business' success."
Intellectual property concerns There is one fundamental concern I have with UX teams using social media
technologies which Nagesh doesn't address. This concern is regarding the ability to welcome feedback from users, or furthermore even
throughout a topic for users to provide feedback. However, if the topic is sensitive intellectual property a challenge is presented with using
social media technologies to have a dialog with your target audience without putting the idea in front of your
I recently read an article titled "10 Most Common Misconceptions about
User Experience Design," by Whitney Hess, an independent user experience designer, writer (authors the blog Pleasure and Pain) and consultant based in New York
Here are my thoughts on her "10 Most" list:
User experience design is NOT... User Interface Design I agree
with Hess' statement that "UI is just one piece of the puzzle" ...and it usually is a complex puzzle.
experience design is NOT... A Step In the Process Creating something that offers a great experience to your user requires keeping the
user in mind from start to finish. This doesn't mean to make assumptions on what the user would want, what it means is that a user-centered
process is an iterative process: 1) You have an idea, 2) you build a prototype, 3) you test the idea, 4) you analyze the data from your test
which should generate new ideas, 5) repeat from step 1. In this process, you can refine your ideas to generate an end-result that offers a
great experience to your users.
Hess states that we "need to keep listening and iterating" - I partially agree with this statement.
My modification would be to keep observing and iterating. It is quite interesting to observe what a user will do when interacting with a
product/system/software/device, and how they will describe what they did when they interacted with it - these two sets of data can be very
different. I prefer to do both, observe and listen, however I place more emphasis on the observations.
experience design is NOT... About Technology I don't completely agree with Hess here. She describes that "user experience designers
use technology to help people accomplish their goals. But the primary objective is to help people, not to make great technology."
The Merriam-Webster Dictionary definition of technology is: "the practical application of knowledge especially in a particular area."
Technology is usually a means to provide a solution to a challenge/problem. Through a user-centered design process, the UX professional can
strive to provide a solution that the user can use and wants to use.
User experience design is NOT... Just about
usability I agree with Hess on this point. User experience is a balancing act between design, technical, and information to produce a
result that the user is able to use as well as a result that the user wants to use.
User experience design is
NOT... Just about the User I also agree with this one too. To add to the balancing act, a UX professional must also take into
consideration the business' needs.
User experience design is NOT... Expensive Just as Hess describes,
user experience doesn't have to be expensive. She quotes another UX professional in her article, who's quote I agree with "In reality the
best designers have a toolbox of options, picking and choosing methods for each project what makes sense for that particular project." There
isn't an end-all solution that magically solves all the problems (that could be expensive). The UX professional needs to select, for example,
the appropriate testing technique for each project (see my article titled "Preliminary Exploration vs. User Testing").
experience design is NOT... Easy Honestly, what is easy in life? I agree with Hess' statement regarding "cutting corners on some
important steps such as UCD is a recipe for disaster." Hess included a statement from Erin Malone, principle at Tangible UX. Malone states
she "finds that both product managers and programmers believe they will create the experience as they build it. 'UX designers are caught in
the middle of trying to speak the business language and the developer language to justify why we need to do our jobs and why it's important to
success." Hess goes on to state that making assumptions about your users can be dangerous - that as a UX professional you need to get to
know your users in a facilitated manner... again, observe them interacting with your product/system.
experience design is NOT... The Role of One Person or Department This is true - while there can be a team of dedicated individuals for
user experience, it really needs to be a company-wide culture to be user-centered. However, I have seen cases where the interpretation of
"user-centered" means to make assumptions of how various individuals working on a project think the
user would interaction... don't make a guess, build a prototype and go test it to observe the user interacting with it - then you know!
User experience design is NOT... A Single Discipline "User experience" as a discipline is in its infancy.
Because of this it is difficult to define the role. When a company hires an accountant, they know what they are going to get. However, when a
company hires a user experience designer / information architect / interaction designer / etc. it is a challenge for the company to know what
they are going to get. Because of this it seems to lend very well to promote collaboration to utilize the skill sets of everyone on the
User experience design is NOT... A Choice Definitely agree with Hess on this point. She quotes
Jared Spool, founding principal and CEO at User Interface Engineering, which highlights the flaw most companies make: "good experience design
is an add-on, not a basic requirement." If you start with the experience at the end, or near the end, then simply put you are setting yourself
up for a potential path for failure.
As a user experience
professional, emphasis is always placed on determining whether or not your target user can successfully perform the intended tasks within an
interface. I think Dr. Susan M. Dray, President of Dray & Associates, Inc. (an international consulting agency for interface design and
usability), states it best, "If the user can't use it, it doesn't work." In other words, the system can have the very best backend data
algorithms, cutting edge processing capabilities, etc; however, if the user cannot interact successfully with the interface of the system then
everything else is of little or no value to the user. So how do you solve this?
Numerous experts, from Jakob Nielsen to Don Norman,
recommend that user testing needs to be performed as frequently as possible. So let's say a functional, or semi-functional, prototype is
produced to allow you as a user experience professional to put the prototype in front of people and collect data. But when it comes to user
testing, where do you start?
Types of User Testing
From my own experiences the term "user testing" is thrown
around very loosely. Everyone needs to do user testing, but what actually is user testing? From what I have seen performed in some instances,
user experience professionals will ask five to ten people for their opinions on a workflow process or a visual interface design. For example,
placing either a paper prototype or software prototype in front of those five to ten people and ask them simply "What do you think?" The
benefits of this are that it is cost effective and can be done relatively quickly. However, the underlying problem arises when user experience
professionals attempt to make generalizations across a larger user population based upon the opinions of a few people, such as ten individuals.
Furthermore, if the user experience professional is only asking the participant for their opinion, they are missing a key piece of information.
To quote Henry Ford, founder of the Ford Motor Company, "if I had asked the public what they wanted, they would have said a faster horse." The
user experience profession needs to give value to taking notes from their observations of the participant. "...pay attention to what users do,
not what they say," said Jakob Nielsen. To expand on Nielsen's statement, I find it interesting to compare what I've observed a participant
do during a testing activity to what the participant tells me about what they did during the testing activity.
With that said, in my opinion and from my experiences in academia, there are really two forms of user testing:
"Preliminary Exploration" and "Structured User Testing." Both forms can provide very valuable data. The key difference is the configuration, or
methodology, for how the testing is conducted. On a side note, while I love working within Photoshop and Illustrator, the researcher in me
prefers to use the "scientific" terminology. Let's break apart each form.
Preliminary Exploration is simply asking a few
people for their opinions. This can provide a sense of direction based upon the perspectives of those individuals but generalizations across a
larger audience of users cannot be made with true certainty. I would consider this an alpha test, or even a pre-alpha
Structured User Test should have a defined methodology. A series of questions can be generated for each participant to
answer as part of a pre-test data collection process. Then for the test itself, a target audience in which the user experience professional is
trying to collect data about needs to be chosen. Since it would be impractical to test the entire target audience, a sample population is
selected from that audience. I will go into more depth about sample population with respect to qualitative research and quantitative research
in the next section. Once the sample population is determined, a set of criteria to actually test needs to be selected. For example, if having
the participants complete an activity, there should be tasks and goals establish for each task. This provides a methodology that is defined,
and can be replicated and then verified by other researchers. Finally, a post-test set of questions should be generated. How the post-test
questions are constructed again brings me back to quantitative research versus qualitative research methods.
To break this down further, the sample population size depends on the type of research you are conducting, as
well as the format for the questions you ask: 1) Quantitative, 2) Qualitative, or 3) a hybrid of quantitative and qualitative. Below is a table
breakdown of the differences between Qualitative and Quantitative research methods:
Methods include focus groups, in-depth interviews, and reviews
Primarily inductive process used to formulate
Primarily deductive process used to test pre-specified concepts, constructs,
and hypotheses that make up a theory
More subjective: describes a
problem or condition from the point of view of those experiencing it
provides observed effects (interpreted by researchers) of a program on a problem or condition
Text-based (for example, open-ended questions)
Number-based (for example, ranking scales)
in-depth information on few cases
Less in-depth but more breadth of information
across a large number of cases
Unstructured or semi-structure
Fixed response options
No statistical tests
tests are used for analysis
Can be valid and reliable: largely
depends on skill and rigor of the researcher
Can be valid and reliable: largely
depends on the measurement device or instrument used
expenditure lighter on the planning end and heavier during the analysis phase
expenditure heavier on the planning phase and lighter on the analysis phase
* I wanted to clarify the terminology regarding "unstructured or
semi-structured." This is stating that the user experience professional would ask open ended questions to the participant. This is not stating
that the user testing study itself is "unstructured" or "semi-structured." Additionally, for qualitative research I prefer "semi-structure" -
you have an initial set of questions, but you are also free to ask follow-up questions to the participant to dig deeper into their
To aide with determining what sample size should be selected if using a quantitative research method, there are tools
available as sample population size calculators. Here is one example that I found with a quick Google search: http://www.surveysystem.com/sscalc.htm.
The Application of
Conducting research and user testing with a product release timeline can be challenging. There are plenty of situations
where prototyping and user testing are cut from an overall project in order to meet release deadlines. "The joy of an early release lasts but a
short time. The bitterness of an unusable system lasts for years," Author Unknown. As a user experience professional, a push to upper
management needs to be made to strive to keep prototyping and user testing in the development life-cycle of
Testing individuals outside of your organization usually means that those individuals want to be compensated for
their time - now there is an expense associated in addition to just your expense to the organization. I agree with other industry professionals
that if you are going to test participants, the value of the data collected can be significantly more beneficial by testing the target audience
you are striving to gain as new customers. However, now you need to justify the additional expense to upper management. In addition, now that
you are testing individuals outside of your organization regarding experimental concepts there may be the need to use Non-Disclosure Agreements
to protect your organization's interests.
Pulling it All Together
The role of a user experience professional has
its challenges, just like any other profession. In this role we try to be advocates for the user / consumer. We do this by collecting data from
the users, also known as user testing, rather than just making assumptions. User testing in and of itself has several possible processes that
can be utilized, each with their own advantages and disadvantages. The proper method needs to be selected on a case by case basis, which is up
to the user experience professional to determine.
These are just my thoughts from my experiences, but I would love to have a dialogue
to get perspectives from others.
About the Author
Frank Garofalo is an on-line and interactive architect living in
Kansas City. Currently, he has two roles, one running his own company Cyber View, an online media and interactive solutions agency
(www.cyberviewsites.com), and second as a User Experience Designer for Garmin International (www.garmin.com). He started designing and building
web sites in 1999. Frank has a Master of Science in Computer Graphics Technology with a specialization in qualitative research for interactive
multimedia from Purdue University. His passion lies in producing a quality experience for the user by combining creative designs and functional
development to achieve a balance of information architecture. You can follow him on Twitter @fgarofalo
I recently read an article on TechCrunch.com by David Barrett titled "Why Products Suck (And How To Make Them Suck Less)." In
the article he discusses how making a product not suck (and to avoid the "tar pit" of sucking) is actually a complex challenge - if it was
easier, more products would be on the market that didn't suck.
Barrett's 5 key points are:
1. It only takes
one person to make your product suck
From Barrett's discussion on this point, I liked the following statement: "Convey to your
team and the world that not sucking is your primary goal."
2. Nobody ever got fired for sucking
words, hire intelligent people - Barrett shares the quotation: "A people hire A people, B people hire C people."
easier to suck more than suck less
This point made me laugh, especially when he elaborated and said: "Sucking is like a tar pit:
once you step in, your struggles only pull you in deeper. After you make that one product compromise to satisfy some crazy customer, then
you’ve got to support that setting." We certainly have run into that issue. Customer A wants specific features as a solution to their current
challenges. But the feature is so specific to Customer A, now whenever you have to upgrade the system for all your other customers you have to
upgrade these small plug-ins specific to Customer A. It causes such a headache...
4. There are more ways to suck than to
Barrett's states for this point: "If sucking is like a tar pit, then building a product that doesn't suck is like
walking a tightrope over La Brea (http://en.wikipedia.org/wiki/La_Brea_Tar_Pits)."
demand sucky products
Ok so no offense to customers, but we all do it as customers without even realizing it. We want products to
align exactly with our needs, but do those needs actually span across all the customers of the product? One strive we are taking towards
remedying this situation is to make our web-based products more adaptive and anticipative to what the customer needs at the given moment. I
certainly agree with the following statement made by Barrett: "…not all complaints are equal: complaints that you don't support feature X
are far better than complaints about how feature Y sucks."
Recently I've been reading a book by Donald Norman called "The Design of Future Things." I'm not one to do much pleasure reading often,
however I have found this book to be: insightful, entertaining, and informative.
On page 93 he discusses the interaction between
humans and machines. Through the various interactions that occur between humans and machines, there are all sorts of indicators that machines
have been designed to use to attempt to inform their user with some type of information. Now that last sentence may sound very vague - but
think about it from beeps to buzzers, LED lights to digital displays - there are a variety of indicators. Norman refers to this in the book as
the "human-machine social ecosystem." For example, on my Android phone the same LED light will illuminate green for a text message, voicemail
message, and Gmail message. However that single LED light doesn't provide me with information to distinguish specifically what it is trying to
bring to my attention - and honestly at times this is frustration. Norman expresses the point that with the design of devices today - some
devices try to adapt to the user and on the flip side, the user usually has to adapt to the device. This can be a strong positive and a strong
negative at times. To quote Norman, "Combining implicit communication with affordances is a powerful, very natural concept" (pg. 71). Norman
goes on to suggest that a "symbiosis of machine and person" is a form of "human-machine interaction at it's best" (pg. 90).
a user experience perspective, how can devices and interfaces be designed to benefit the user? Norman shares details regarding how devices
today are trying to adapt to a user's behavior pattern to predict what the user will want. The primary goal to achieve is to not cause an
annoyance or dangerous situation for the user, but rather to support the user. Predict and give the user suggestions. The device can then adapt
and become better at predicting the suggestions to give the user without completely automating the process by making a selection for the user.
To support the user information provided, according to Norman, must be "voluntary, friendly, and cooperative" (pg. 130). I certainly agree with
Norman especially when he describes the concept of "informate," which he defines as "impact of increased access to information afforded by
automation" (pg. 133).
There is a challenge between making a device completely automated and making a device completely manually
controlled. The middle ground, as Norman suggests, can be a very complex and potentially dangerous combination. However overall, devices and
interfaces need to "provide a user with tools to work and live smarter" (pg. 128).
Tweet with me @fgarofalo and let me know
what you think.
I read an article be in late August about a brainstorming concept at Pixar Studios (owned by the
Walt Disney Company). Although, now I can't seem to find that article.
Anyways, the article discussed how at Pixar to promote
creativity from all levels of the company, the truly utilize dry-erase boards. They do this by hanging dry-erase boards in the hallways. I
believe the article mentioned that employees could still reserve the boards to hold meetings. just as if it was a conference. The benefit this
offers, is that Pixar has established a culture were if anyone passing in the hallways hears or sees something on a dry-erase board there is an
open invitation for them to contribute and offer suggestions/ideas.
I found this concept to be very interesting. I can see how this
promotes contribution and brainstorming from a community perspective. Along with the notion, that any idea can be considered. I guess taking
this to another level, you could almost parallel this to the movie Good Will Hunting (1997) where Matt Damon's character, a janitor, helps to solve a Professor's math
Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites
rely on "rollovers", which pop up menus or other elements when the mouse arrow hovers over a specific spot. Apple's revolutionary multi-touch
interface doesn't use a mouse, and there is no concept of a rollover. Most Flash websites will need to be rewritten to support touch-based
devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and
Now as a designer / developer for multi-touch interfaces with the Adobe Flash Platform, I may be a bit biased
here, but I disagree with his statement on several points. Most technologies were designed during the PC age, including Flash, the Web, HTML,
and even several products from Apple. The mouse at the time was the most cost effective input device to replicate actually clicking and
selecting items on a computer screen/display. Now with the continuing evolution of multi-touch devices, there are several new interface
advantages and disadvantages emerging.
"Rollovers" can still occur in a multi-touch interface to help indicate to the user what
element of the UI the user has selected. While I do admit, with multi-touch there is a blurred line between a "rollover" and a
"single-tag/touch," so depending on the interface these may need to be coded differently to acknowledge a touch vs a mouse click.
for the "modern technologies like HTML5" - we've seen time and time again with various Internet browsers slightly different implementations of
web standards created by the W3C and I doubt HTML5 (http://dev.w3.org/html5/spec/Overview.html) will be any different. The challenge with
this to web designers / developers is creating a consistent user-experience across all Internet browsers and computer operating systems. At
least with Flash, a consistent, engaging experience can be achieved.