Offline Adblock

Imagine an environment with no advertising, that’s the idea behind BrandKiller, a project developed by four Philadelphia developers named Jonathan Dubin, Reed Rosenbluth, Tom Catullo, and Alex Crits-Christoph as part of as part of Penn’s annual PennApps hackathon.


Design thinking as a process for problem-solving

Cribbed entirely from Wikipedia – it’s a good meta view of a design process.

Unlike analytical thinking, design thinking is a process which includes the “building up” of ideas, with few, or no, limits on breadth during a “brainstorming” phase. This helps reduce fear of failure in the participant(s) and encourages input and participation from a wide variety of sources in the ideation phases. The phrase Outside the box thinking has been coined to describe one goal of the brainstorming phase and is encouraged, since this can aid in the discovery of hidden elements and ambiguities in the situation and discovering potentially faulty assumptions.

One version of the design thinking process has seven stages: define, research, ideate, prototype, choose, implement, and learn. Within these seven steps, problems can be framed, the right questions can be asked, more ideas can be created, and the best answers can be chosen. The steps aren’t linear; can occur simultaneously and be repeated. A more simplified expression of the process is Robert McKim’s phrase; “Express-Test-Cycle”.

Define
  • Decide what issue you are trying to resolve.
  • Agree on who the audience is.
  • Prioritize this project in terms of urgency.
  • Determine what will make this project successful.
  • Establish a glossary of terms.
Research
  • Review the history of the issue; remember any existing obstacles.
  • Collect examples of other attempts to solve the same issue.
  • Note the project supporters, investors, and critics.
  • Talk to your end-users, that brings you the most fruitful ideas for later design.
  • Take into account thought leaders’ opinions.
Ideation
  • Identify the needs and motivations of your end-users.
  • Generate as many ideas as possible to serve these identified needs.
  • Log your brainstorming session.
  • Do not judge or debate ideas.
  • During brainstorming, have one conversation at a time.
Prototype
  • Combine, expand, and refine ideas.
  • Create multiple drafts.
  • Seek feedback from a diverse group of people, include your end users.
  • Present a selection of ideas to the client.
  • Reserve judgement and maintain neutrality.
  • Create and present actual working prototype(s).
Choose
  • Review the objective.
  • Set aside emotion and ownership of ideas.
  • Avoid consensus thinking.
  • Remember: the most practical solution isn’t always the best.
  • Select the powerful ideas.
Implement
  • Make task descriptions.
  • Plan tasks.
  • Determine resources.
  • Assign tasks.
  • Execute.
  • Deliver to client.
Learn
  • Gather feedback from the consumer.
  • Determine if the solution met its goals.
  • Discuss what could be improved.
  • Measure success; collect data.
  • Document.

Although design is always influenced by individual preferences, the design thinking method shares a common set of traits, mainly; Creativity, Ambidextrous thinking,[5] Teamwork, User-Centerdness (Empathy), Curiosity and Optimism.

From Design thinking on Wikipedia


We need brilliant people working in our companies to take them to the next level but we also need smart people with humility and flexibility in their thinking. There’s not always “one best way” to do something; there are many paths. We are better team mates when we listen, when others can challenge us, and when we can admit to ourselves and others that we might be wrong.
VIA


Defining severity in Usability Expert Reviews

decision-tree

It’s easy to see why there is often push-back on the results of usability tests (nobody likes to be told why their solution doesn’t work), but it’s important to remember that the goal is the same for everyone on the development team: to constantly improve the products we design. Effectively communicating usability results is one step towards designing better products. Via.

Having a standard process for defining severity means that you can be consistent in the way you assign severity and means that you provide the transparency needed for people to check your work. With an expert review,
deciding on the severity is more a matter of judgement, but there are three questions you can ask to improve your objectivity.

From David Travis a concise set of questions to help assign a rating:

Does the problem occur on a red route?
Red routes — frequent or critical tasks — are the most important tasks that the system needs to support, by definition.

Is the problem difficult for users to overcome?
Some usability problems are show-stoppers: users just can’t proceed.

Is the problem persistent?
Persistent problems — problems that keep cropping up — are more severe because they have a bigger impact on time on task and on customer satisfaction.

The complete article: How to prioritise usability problems

More views:
Heuristic Evaluation Quality Score (HEQS): Defining Heuristic Expertise
Rating The Severity Of Usability Problems

20 years ago Jacob Neilson in his article Severity Ratings for Usability Problems outlined the following 5 point scale:

0 = I don't agree that this is a usability problem at all
1 = Cosmetic problem only: need not be fixed unless extra time is available on project
2 = Minor usability problem: fixing this should be given low priority
3 = Major usability problem: important to fix, so should be given high priority
4 = Usability catastrophe: imperative to fix this before product can be released

Problem Prioritization in Usability Evaluation: From Severity Assessments toward Impact on Design

Severity Scales.xls

Effectively Communicating Usability Problems

UXValue as a tool for prioritize bugs

Making sense of usability findings with criteria based severity ratings

Usability Severity Rating – Improved


Icons need text labels

I’ve spent a great deal of time recently staring at ambiguous icons trying to guess their meaning and offer suggestions, it’s a fascinating study and mind numbing at the same time.

When designing icons for interfaces it’s important to note that a user’s understanding of an icon is based on previous experience. This came up recently when evaluating an interface’s usage of the checkmark symbol as a signifier of a change of state (in this instance selecting a photo). In my experience this has always signified completion or success when working through a task or a process, but it seems Apple and Google both are using this in entirely different contexts.

In her article “Icon Usability” Aurora Bedford argues that “due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity”. I’m not sure this is possible in every instance but it’s a valid argument.

Icon labels should be visible at all times, without any interaction from the user. For navigation icons, labels are particularly critical. Don’t rely on hover to reveal text labels: not only does it increase the interaction cost, but it also fails to translate well on touch devices.

Via: Icon Usability


Real world design is often iterative – fail fast so you can succeed sooner.

Failing fast is one of those seemingly overly simplistic tenets that I often fail at achieving. Balancing perseverance (stubbornness) and the realisation that through failure we learn or succeed is often difficult to achieve.


Persona definition

persona

From Aurora Bedford:

The field of user experience centers on the idea that we must design products around people, rather than teaching people how to use products: user-centered design (UCD), not technology-centered design. In order to do so, we must understand people—their behaviors, attitudes, needs, and goals. […]

A persona is a fictional, yet realistic, description of a typical or target user of the product. A persona is an archetype instead of an actual living human, but personas should be described as if they were real people.

The description should be thorough, including details about the persona’s needs, concerns, and goals, as well as background information such as age, gender, behaviors, and occupation. This focus on a singular individual—or a small set of individuals, if using multiple personas—fosters empathy for the specific users we are designing for, and helps us break away from the attempt to design for everyone. A persona doesn’t need to document every aspect of the imaginary individual’s life, but rather should focus on those characteristics that impact what is being designed. It is likely that a business will have several personas to cover the various aspects of their organization, with one or two of them identified as the main targets for each product or service, feature set, or content area of a website.

Common pieces of information to include are:

  • Name, age, gender, and a photo
  • Tag line describing what they do in “real life”; avoid getting too witty, as doing so may taint the persona as being too fun and not a useful tool
  • Experience level in the area of your product or service
  • Context for how they would interact with your product: Through choice or required by their job? How often would they use it? Do they typically use a desktop computer to access it, or their phone or other device?
  • Goals and concerns when they perform relevant tasks: speed, accuracy, thoroughness, or any other needs that may factor into their usage
  • Quotes to sum up the persona’s attitude

Via Personas Make Users Memorable for Product Team Members