At the UPA Boston conference, Colleen Roller discussed why seemingly insignificant aspects of information presentation can have a surprising effect on people’s perceptions and behavior.

  • People like to make easy choices
  • Cognitive fluency is how easy or difficult it is to think about something. Cognitive fluency is subtle and pervasive.
  • People tend to be attracted to what is: average, familiar, symmetrical.
  • The mere exposure effect – Exposing people to stimuli more than once increases attractiveness
  • What impacts how people determine the truth of unfamiliar statements? The size / color of text, frequency of exposure, rhyming words.
  • Rhyming words are an easier cognitive load / mental ease
  • People apply the sensation of mental ease to statements
  • Fluency of perceived truth is as follows: easy to decipher => must be familiar / safe => must be popular  (reply on social consensus when unsure) => must be true
  • People perceive things with names that are hard to pronounce as: risky, new & novel, exciting and full of adventure, likely to make them sick
  • Something that feels hard to decipher => is not familiar => must be risky
  • Rhyming text is easily remembered and seems more accurate
  • How its worded / appearance changes perception of statement (rhyme as reason effect)
  • People will postpone difficult decisions when the fond size used is difficult to read.
  • What can help people be more careful and prevent silly mistakes on tests? Using a font that is difficult to read.
  • A personal questionnaire that is less legible causes people to answer less honestly
  • To boost student morale, ask them to list a few reasons why they’ll succeed, many reasons why they my fail. It raises moral because the amount of mental work needed to come up with a long list of reasons for failure changes perception.

At the UPA Boston conference, Janelle Estes discussed how she used a variety of user research methods to assess how people use postings from companies and organizations on social networks.

  • Estes conducted a usability study and a diary study
  • She recruited people  who used 2+ social networks for 3+ months, as well as folks that were willing to access their social network accounts during test sessions
  • The usability study revealed that users often have a difficult time finding where to sign-up to receive postings. They will search on keywords such as “friends, connect, social”, and many sites don’t have results on those common terms.
  • The diary study was a 4 week study. Estes sent out assignments 3x per week, and asked for responses using a Google spreadsheet. She sent the assignment on a consistent schedule. Estes suggest that its important to make a connection with participants over the phone prior to the study, and it might be a good idea to vary assignments or shorten the study with more participants.

Estes was able to glean some design guidelines from her study as follows:

  • Users had varying expectations on message types, it all depended on the org. News: top stories, Consumer: new products, sales; Non-Profit: Initiatives: upcoming events
  • Place important information at the beginning of the message, as people only scan the first few words
  • Clearly describe where a link take users
  • Users expected companies to be personable, informal, have more personality
  • Engage in two way conversation
  • Initiate conversation about relevant topics
  • Send messages regularly, but not too regularly
  • Choose a meaningful and eye-catching profile picture
  • Place calls to action on the homepage, footer navigation, and pair them with appropriate logos
  • Provide social network information in email and newsletters

At the UPA Boston conference, Bryn Dews and Thom Brando discussed their open-source prioritization game.

It is often difficult to get users to prioritize a list of features. In order to set priorities, Dews and Brando came up with a monopoly like game.

  • Provide users with “money” and have them “buy” features.
  • Ask users, “What’s it worth to you?”
  • Utilize 100 dollars in “bills”
  • Pilot tested the game using a physical board, then created an open-source online game
  • The game allows you to input and describe features, let users “buy” features, and write-in features as well as suggestions.
  • The game and installation instructions can be found here:


Bicycle tools

In my relatively short time in the field of UX design, I have been exposed to a variety of processes and techniques. I think about process a great deal, and have lately been enamored with agile methodologies, largely due to the team-centric ideals and practices. Having said that, as I become exposed to a greater variety of projects and clients, I realize that no process is a silver bullet, and no single process should guide how we approach our work. If we continually go through the same motions, eventually they become a habit and thinking creatively versus automatically becomes more difficult.

Given that each project, each stakeholder, and each problem is unique – with their own quirks and eccentricities – we should evaluate our approach to each problem on an individual basis. We can look at all of our techniques in the field as tools in our toolbox, and for each project it is our responsibility to choose the appropriate tool and methodology to solve to the problem at hand, rather than continually banging on different problems with the same hammer.

Furthermore, as new challenges arise, if the tools in our toolbox are not doing a sufficient job of helping us solve the problem it is also our duty to modify current techniques and invent new ones to add to our UX toolbox.

Working in Agile

So now that you have a definition of agile and some of the underlying principles, how do you actually do the work?

First, it is important to understand that you are not trying to squeeze UX into an agile process, but rather attempting to make the UX process more agile. This will mean being flexible, innovative, and nimble with established UX techniques.

The role of UX

UX practitioners are most successful in the customer role on an agile team. Remember, that customers mean something different in agile, a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan.

The customer defines the software, and determines what stakeholders find valuable. The recommended ratio is 2 customers per 3 developers, this means that there are 2 designers for every developer. Designers can be of any combination: UX, Usability, IA, Visual, IxD – whatever is needed to accomplish the project. The customers most important job is release planning which includes:

  • Evangelizing the product vision
  • Identifyng features and stories
  • Grouping features into small, frequent releases
  • Managing risk
  • Creating an achievable plan

In order to be able to achieve the above, I would recommend starting with:

  • Small, clear, and achievable goals
  • Letting go of control, and allowing your team help with some of the activities
  • Get “good enough” information, and continue to learn throughout the entire project, rather than trying to figure out everything up font
  • Be honest with yourself and work towards continual improvement

The Process

The process that has worked best for me was first described by Desiree Sy

The structure basically asks you to:

  • Gain initial insights through a short up-front discovery stage
  • Get just far enough ahead of development that you are not a bottleneck
  • Continually talk to users every iteration to get feedback and more in-depth insights
  • Start rough and refine as you go along. utilizing lightweight techniques like sketching
  • Establish a clear vision that you are working towards and iterate on the vision as you learn more information

It is important to understand that none of these activities are happening in a bubble, you as the designer are not going off to complete the work and then presenting a finalized design. Rather, you are sketching, concepting, and getting feedback from your entire team along the way. The feedback can be informal or a design critique.

Also, working in this rhythm or cadence will feel uncomfortable at first, and you might have the urge to resist, but stick with it and allow this rhythm to become the “new normal”.

Here are some common objections/questions that I often hear from designers and quick answers:

1) How many projects should a UX designer be on if the company adheres to an agile process?
Answer: ONE. Agile is specifically designed around the team dynamics, and its difficult or impossible to create the proper rapport if you are not sitting and working with the team.

2) Agile methods do not provide enough time for UX practitioners to conduct necessary research and discovery.
Answer: Agile methods do not provide enough time upfront to conduct research, the methodology assumes that you are doing the research and discovery on a continual basis, in every iteration. This not only helps keep the information fresh in your mind, but also allows you to dig deep into questions that arise once you start really trying to solve the problem (later in the project), rather than identifying the problem (as in the beginning of the project)

3) If I break up my design into pieces that can be fit into an iteration, it is difficult for me to picture the holistic system
Answer: Sketch your initial understanding of the holistic system using a storyboard, then begin to dive deep into the parts of the system that are prioritized for the upcoming sprint. Your understanding of the system will change over time, so utilize a low-fidelity medium to capture your current understanding and then update as it – and your understanding – changes.

4) Some designs are too complex to fit within one iteration
Answer: Break large designs into small, cycle-size pieces called design chunks that incrementally add elements to the overall design over several iterations. Whenever you design, you have to start somewhere, start in one iteration and incrementally add complexity / layers in subsequent iterations.

5) There is not enough time to conduct formative usability testing and then create a usability report.
Answer: Employ light-weight usability techniques, and progressively engage in defining test protocols and recruitment.

6) Working software over comprehensive documentation means no more wireframes or mockups
Answer: Use the tools that will help you and your team produce good work. There is no set “way” to do thing, figure out how best to communicate with your team, and which tools help you produce great work in an efficient way, then just do it!

Tags: ,

Agile principles and practices

In the first part of this agile series, I explained that there is no such thing as the agile method, but rather a set of principles or values. Specific methods do exist, and they support the agile philosophy. Two of the most popular methods include Scrum and XP. Having only worked in Scrum, I will describe how the practices in Scrum directly support and uphold the principles.

Co-Location: The entire project team sits together in one physical location, rather than being separated into departments.
Supporting Principle: Individuals and interactions over processes and tools
The agile philosophy centers on cohesive, trusting team. That kind of trust can only be build overtime through constant exposure to fellow team members, the demystifying of jobs and daily activities, and just hanging out together. There is also a great deal more cross-pollination of ideas, which leads to a blurring of roles and true teamwork.

Story Creation: Defining the requirements together
Supporting Principle: Working software over comprehensive documentation
The entire team will write stories, which are short requirements statements, versus tomes of requirements documents. They force the entire team to articulate the audience, purpose, and value of each feature.

Customer Demos: Present functioning software at the end of each sprint
Supporting Principle:Customer collaboration over contract negotiation
In Scrum, a “customer” is not a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan. UX folks fit perfectly into the customer role!

Stand-Up Meetings: Daily meetings where each team member lets everyone know 1) what they did yesterday; 2) what they are going to do today; 3) anything standing in their way
Supporting Principle: Responding to change over following a plan
This allows the team to gauge progress as well as address any obstacles preventing the team from moving forward.

Retrospectives: A team meeting at the end of every iteration where each team member lets everyone know 1) what went well; 2) what didn’t go well; 3) areas for improvement
Supporting Principle: Responding to change over following a plan & Continuous improvement
Although not stated as an explicit principle, continuous improvement is one of the core values of agile. A team does not need to follow a process dogmatically, but rather learn from each experience, improvise, and improve.

The above represent just a hand-full of the practices that go into a Scrum process. For a much more complete explanation, I would sincerely suggest getting Mike Cohn’s Succeeding with Agile.

Also, check out my full presentation on Slideshare:

Tags: ,

Defining Agile

Agile has recently become a hot topic, both organizationally and in the design world. Several articles have attempted to describe agile, and how to fit design or UCD into an agile development:

Bringing User Centered Design to the Agile Environment by Anthony Colfelt, published on Boxes and Arrows
How UCD and Agile Can Live Together by David Farkas, published in Johnny Holland

Although they provide a really good high-level overviews, they still seem to miss the mentioning the fundamental essence of agile – agile is philosophy or a mindset, not a set of methods or practices.

There is a lot of confusion between agile, scrum, and xp. Many times people refer to agile as the agile method. There is no such thing! Agile is a set of principles, and scrum or xp are defined practices that uphold agile principles.

So what are the agile principles?

In 2001, a group of developers came up with the agile manifesto, which outlines the four values of agile:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

In practice, these translate into the following

  1. Great products come from great teams
  2. Go to high function fidelity quickly, provide just enough documentation to produce great work
  3. Involve the end-users, decision makers, and stakeholders throughout the entire process
  4. Be ready for change, be it from the client, the market, or anywhere

As designers, constant communication, negotiation and feedback has always been part of our values and processes, but developers have been notoriously bad at such skills, which is why so many of the values center around communication. The most important value, and the core of agile, for both developers and designers is #4. Expect change, be ready for change, change is okay. Designers, like developers, do not deal well with change. Heck, human beings in general don’t do well with change, especially the last minute kind. However, if you go into a project with the mindset expecting change to occur, you will be much more prepared to be agile or nimble and handle it accordingly. In my opinion, that is the most valuable contribution of agile to both design and development.

Tune in to Part 2, Scrum in Plain English, coming soon!

Tags: , ,

Alla Zollers

I design products and services that just. make. sense.

When products make sense, customers are happy.

If customer are happy, they sign-up, stay on site, engage, share, and buy your product or service.

Happy customers allow companies to profit in both senses of the word.

I provide the following services:

• Heuristic Evaluations
• Discovery Research
• Strategy and Vision Development
• Information Architecture
• User Experience Design
• Usability Testing

You can find me on:

Twitter Updates