nForm Blog

The Experience Gap (UX Camp Edmonton Presentation)

2013-05-13T19:00:57Z

I wanted to share the slides from my UX Camp Edmonton talk this weekend. The presentation is called "The Experience Gap," and its core idea is that there's a growing gap between the best experiences people have with technology and the ordinary ones created by most organizations. In that gap there are interesting opportunities for UX professionals, especially in places like enterprise software development.

The Experience Gap (UX Camp Edmonton) from nForm User Experience

(One of these days I'll pull together my complete notes to post too.)

User Experience Debt

2013-05-07T20:37:31Z

Have you ever borrowed something from a friend and written them an “I.O.U.”? I have. But have you ever written one to the people that use your website, your application, or your online services? No? I didn’t think so*.

Most digital products – like websites, apps, and online services – are designed and built with the best intentions. But something happens between identifying a need and delivering a solution. That “something” is an accumulation of User Experience debt, or “UX debt”, and it is something of an I.O.U. to your users.

A Brief History of the Term

The term "UX Debt" stems from another financial analogy called Technical Debt coined by Ward Cunningham to describe the hidden, future costs of cleaning up sloppy code and repairing unstable components of software because corners were cut during development. Ward Cunningham also described repaying this debt in terms of refactoring code to align with increased understanding of how the software ‘should’ function. We’re going to apply a User Experience perspective to this concept.

What is UX debt?

UX debt is the quality gap between the experience your digital product delivers now and the improved experience it could offer given the necessary time and resources. Put another way, UX debt measures the number and magnitude of potential product enhancements that would improve the user experience.

In his book Designing for Emotion, Aarron Walter remapped Maslow's Hierarchy of needs to the needs of our users. To paraphrase Mr. Walter: for a user's needs to be met at the most basic level, an interface must be functional. If you can't complete your task, you won't stick around long. Each level of the “functional, reliable, usable, pleasurable” pyramid satisfies different user needs and increases a user’s satisfaction with a digital product. UX debt is measured as the distance between the current quality of experience and the target quality.

In talking about UX debt, it’s important to acknowledge that it only exists if you believe digital products should be more than just functional; more than just reliable; and maybe even more than usable. While the target quality can vary based on the perspectives of the users, the business, and the project team, I believe it should skew towards user expectations and their desired quality of experience. For now, we’ll assume that all perspectives agree on a target quality of “usable”.

Classifying UX Debt

UX debt can be classified into two categories: intentional and unintentional. Intentional UX debt is the result of project constraints and deliberate corner-cutting. Unintentional UX debt, on the other hand, is less obvious than intentional UX debt and results from misconceptions about users’ needs or users’ comfort with technology.

Intentional UX Debt

Intentional UX debt is a result of decisions made based on project constraints. It is common that budget, time, or resource constraints determine which features are included in a digital product.

Sometimes, interaction along critical task-flows goes unimproved because "it works" and there are other, less-critical features to squeeze in before the deadline (that’s an I.O.U.). Sometimes, design ideas that simplify user interactions are sacrificed because they are viewed as too complex to implement in the time-frame (that’s an I.O.U.). Or, an organizational mantra, like “no customization” or “keep it vanilla,” prevents the team from even considering those improvements in the first place (a wicked I.O.U.).

These are realities of the software world. It sucks, but it happens. Priorities are measured and choices are made. When those choices compromise the user experience, the result is UX debt.

There's another form of intentional UX debt that can be harder to spot. It comes from cutting corners and taking the easy way out of design problems. Whether it's an individual or a team, sometimes people look for the fastest solution to an otherwise interesting design problem. They know there are better solutions that will meet the needs of the users more closely, but they would have to work harder for them (that’s an I.O.U.). UX debt is created when we take the easy path to avoid the effort required of a better solution.

In both situations – for whatever reason – there is intent to omit a higher quality experience.

Pro-tip: When you hear "we can train them on it,” you’re incurring UX debt.

Unintentional UX debt

Acquiring unintentional UX debt is easiest when you assume you know your users and can design a product or service without confirming your assumptions about them. For example, when someone says "Why don't we just design it for Joe Public / the average user / my mom and that'll be fine, right?" I cringe, bite my lip, breathe three times, and proceed to politely discuss alternatives to their suggestion. Without understanding the people a digital product or service is being designed for, you may be designing yourself straight into the depths of UX debt (and that’s a BIG I.O.U.).

The forgivable way to incur unintentional UX debt is when your understanding of the needs, abilities, or characteristics of a product's users change. For example, let's say your app is designed and built based on what your team knows today. This app delivers a high quality experience that aligns with users' needs and wants. But, over time, users are exposed to more complex interaction patterns in other digital products and their comfort level with technology increases. As this happens, people begin to perceive your app as less usable than, say, a competitor's product which has already adapted to this shift (and that’s an I.O.U.). Your users have raised the bar, thereby increasing your UX debt.

Accruing some unintentional UX debt is unavoidable and, perhaps, inevitable as we learn more about how people use our digital products. But there is a risk that these mounting I.O.U.’s will lead to project failure or user rebellion if they go unchecked. The risk increases as more time and resources are invested without some kind of user validation. Fortunately, the threat of UX debt can be reduced with the appropriate research into understanding the people that will be, and are currently, using our digital products.

Summary

UX debt is real and every digital product has some to repay. Some of this debt is incurred intentionally because tough decisions have to be made. Some of this debt is incurred unintentionally because assumptions about end-users go unchecked or there are unpredictable changes in the ecosystem.

The important difference between websites, apps, and online services we perceive as usable and those which are not, is that usable digital products have less UX debt than the products surrounding them. They’ve put in the effort to repay their UX debt and can happily tear up settled I.O.U.’s.

In a future post, I’ll discuss some ideas around tracking UX debt and how to transform it into opportunity.

* If you have written an I.O.U. to your customers or end-users, I’d love to hear your story and what came of it! Continue the conversation on Twitter using the hashtag #uxdebt or drop me an email at andrew<dot>wright<at>nform<dot>com.

Training vs. Design

2013-04-10T15:06:06Z

A friend of mine, a mid-level manager in a large company, recently told me about his employer's new expense tracking system. Like many big organizations, my friend’s firm designs and builds many of its internal applications. While rolling out the application, this company asked its employees to take a two-hour training session to teach them how to enter their expenses.

To say my friend is busy would be an amusing understatement. Naturally he was frustrated with the time commitment for training on such a mundane activity. I agreed that a two-hour lecture on logging receipts seemed excessive. But I was also astounded at his employer’s financial investment in training. If you count the costs for developing the training materials, delivering the sessions and the staff time, this organization probably spent well into the seven figures on training alone.

That's a lot of money, right? You'd expect to see some serious results with that kind of investment. But my friend reports that the next time he went to enter his expenses--probably a few weeks after his training session--he was pounding his keyboard in frustration.

Was he the only one? No, in fact, almost *everyone* who had to do expenses regularly felt this way.

This story encapsulates a common problem we see in enterprise application development projects: spending a lot of money on training instead of making a small investment in design.

The Economic Consequences of Ignoring Design

There's a simple and compelling economic argument in favour of design over training: design is a one-time investment; training is an ongoing investment over the life the product.

Not only do you incur training costs at least once for every user, the worse your user experience, the more likely you will incur those costs multiple times for every user (in the form of retraining and peer support).

Let's go back to my expense-tracking friend. His company has already spent over a million dollars (by my estimation) on training to roll out their new system—but realistically they're just getting started. Every new employee will need training at least once, and there will be support costs and lost time due to preventable errors. And let's not forget intangibles like the unnecessary frustration and the lost goodwill of employees.

Most importantly, no amount of training will ever fix the design flaws in this system.

A better approach would've been to do some prototyping and evaluation of the application--iterative design, in other words—-prior to the build. But for a variety of reasons—-sometimes it’s organizational culture, sometimes it’s ignorance of iterative design methods—-we see organizations trying to correct their user experience problems with training.

What's the Problem?

We’ve noticed three related issues that contribute to this problem:

Training is disconnected from application development. It happens at the end of a project, the costs are often distinct from development, and the trainer is engaged when the product is finished.

Training is actively used to compensate for poor or just unconsidered design. More than once we’ve heard “we can train them on it” as a way to justify confusing design choices.

Ongoing training, user frustration and preventable errors are negative externalities--they’re not accounted for in project budgets or in application operating costs so project managers are often free to ignore them.

What Can We Do Instead?

The first thing we should do is recognize that there are different kinds of training.

People need to acquire domain knowledge about the system and how it fits into their work. Someone who’s never worked in a large organization might need to know what kinds of things (e.g., meals, mileage, office supplies) she can expense.

People need to understand the business processes and policies that govern the system. This could mean anything from the approval process for expenses, to the time required to process a claim, to the deposit dates for direct payments.

In our experience, much training focuses on “how to” information--the key tasks and procedures that people need to complete when using the system. This is tricky because procedural knowledge is hard to learn and recall without practice.

Finally, people will train each other informally on how to use systems effectively. For software that isn’t intentionally designed to be usable, a significant amount of time can be sunk into peer support (“hey Sally, can you show me how to upload my receipts?”) or sharing workarounds (“if you open the expense codes in a separate tab you can cut and paste them easily”).

Generally speaking, domain knowledge is easier to acquire and share while procedural knowledge requires some practice to master.

The key thing to recognize is that good design can reduce the need for formal training by anticipating people's most important tasks and guiding them through them. In the case of expense tracking, an occasional-use application for most people, thoughtful design will help people do the right things at the right time without much training at all.

Good design should also eliminate the need for informal training through research (looking at the workarounds people currently use and designing the system to accommodate those) and evaluation (testing prototypes to ensure people don’t need to resort to workarounds to complete a task).

How Do We Fix This?

There’s a difference between knowing that design can reduce training costs and doing something about it. So how do we address the three core problems I mentioned earlier? Here are some suggestions:

Redeploy your training budget

If you’re not already doing design work in the early phases of a project, you should redeploy a portion of your training budget to design work in the requirements phase (or inception phase if you’re doing an agile project). Focus on using your design efforts to improve the learnability, memorability. efficiency and error rates for the application. These are standard usability quality components, but it’s important to call them out specifically because they all impact the need for training.

This redistribution of funds will pay off over the life of the application. Remember, design is a one-time investment; training is forever.

How much should you move from training to design? We think it depends on whether or not your users need to master the application. For expense tracking, mastery is not required, so a large portion of the training budget (perhaps 80% or more) could potentially move to design.

For systems that require mastery (anything from air-traffic control software to everyday point-of-sale systems) you will still need training as well as practice time for your users. But if you’re not doing design work you’ll get value from spending some of your training budget on design. I can’t give you an estimate for how much to spend--it could be 10% or 50% or more depending on how complex and critical the application is. The key is to assess how much a one-time investment in improving efficiency or reducing error rates could reduce lifetime training costs.

Iterate

Use an iterative design process so you can improve the application’s design quickly and cheaply as early as possible. Iterative design means you produce at least one prototype of the system, test it with real users, and make changes. Many of our projects involve three iterations of the application; some involve more. And our experience has been that sketches, wireframes and small-scale interactive prototypes are the best tools for working through design options. (Side note: Agile projects are only iterative if the team revisits and improves features in future sprints. Most agile enterprise application development projects we encounter are not iterative.)

After Launch: Fix the Simplest Non-functional Problems First

These two approaches above are great at the start of the project, but what about after an application has launched? The development and training budget are spent, but your organization is probably still absorbing the hidden costs (frustration, support and peer training).

One approach that’s worked for us is focusing on small non-functional changes to the most problematic features. On a recent project we worked with the application developer on minor adjustments--such as relabelling confusing fields and allowing users to move directly between two screens they often needed in sequence instead of closing one then manually opening another. These changes improved user performance and satisfaction but didn’t require major effort or any functional changes.

Depending on your organization you might be able to do guerilla redesigns or cafe testing as well.

Quantify the Negative Externalities

Another approach that might be useful is estimating the costs of ongoing training, peer support, frustration and preventable errors (the consequences of ignoring design that aren’t factored into project budgets or operating costs). UIE has a helpful article on the Cost of Frustration that provides several ideas for how you might quantify these things. Here are two we like:

Rather than trying to establish a dollar cost for frustration, talk about what people could do with their time instead.

Trace the pain and find allies who can support your cause. For an expense tracking system, for example, a finance manager may spend more time than they want on fixing errors or taking support calls.

This approach won’t yield immediate results, but it can help create a culture where design is valued because it contributes to the organization’s success. It also makes an explicit connection between doing iterative design and employee satisfaction, cost avoidance and project success. Then, the next time a big internal systems projects comes around, the project manager will be more likely to do a couple of rounds of design and prototyping early (and will have a way to justify the costs since it can come out of the training budget).

Event: Content Strategy for the Public Sector (April 11)

2013-04-02T16:26:06Z

Before I started consulting 10 years ago I worked in the public sector in a variety of communications and web management roles. Talking with clients over the past year I've realized that many of them still suffer from the same frustrations I had as a public-sector web manager--especially around content creation, management and governance.

We decided to put to together a talk on content strategy for the public sector to share some of our ideas (as well as the best ideas we've heard from our clients and industry) about content. If you work in the public sector and you deal with content creation or publishing we think you'll enjoy this event.

Details and a registration form are below. As always, tickets are free but attendance is capped. We'll provide coffee and a light breakfast as well.

Event Details

Content Strategy for the Public Sector
Thursday, April 11, 8:30 a.m. to 10 a.m.
Matrix Hotel
10640 - 100 Avenue
Edmonton, Alberta
View this on Eventbrite

Session Description

For many of our public sector clients, delivering relevant, compelling and findable content is a common challenge. They wrestle with diverse stakeholders and audiences, complex programs and policies, clunky content management systems, and limited resources for content creation. And yet, the content created by public sector organizations is highly valued and trusted by users, and is often people's first stop on their way toward accessing programs and services.

In this talk, we'll share insights about content strategy from our last decade of work with government, municipal, health and education clients. You'll hear about:

What we've learned about how people use web content, social media and online services
Governance, leadership and other factors that contribute to successful teams
Making a business case for investing in content development and building strong editorial teams
Essential strategies to get you through the next few years of shrinking budgets, rapid technological change and growing user expectations

Speaker Bio

Gene Smith is the president and owner of nForm. He's worked with a variety of Canadian public and private sector organizations on user experience strategy for their websites, Intranets and business applications.

Registration

Event Registration Online for Content Strategy for the Public Sector powered by Eventbrite

When to apply UX effort in agile

2013-02-21T19:15:02Z

Over the past two years, I've been the user experience designer on a number of projects with teams that are adopting agile as their chosen methodology (it usually comes in scrum flavour). Some teams were more experienced with the methodology and its practices; other teams were less experienced. I was learning with them.

My experience has been that UX design skills are most valuable to agile processes at three key points:

during modeling,
during evaluation, and
for facilitating day-to-day design activities.

1. Modeling

The first way that UX designers benefit an agile project is by modeling the system. The term modeling is borrowed from the world of architecture, but I’ve drafted a simplified version of this definition that works for application development projects:

"A model is a representation of a system – including its processes, interaction channels, and its users – created to study aspects of the design or to communicate design ideas to clients, committees, and team members."

Or put another way: modeling is the synthesis of details into something tangible that people can talk about.

Scenarios, experience maps, task flows, personas, and other storytelling tools are used to improve team members’ understanding of the business processes, the channels and modes of interaction, and the users’ behaviours and attitudes. These living documents also serve as focal points for design discussions and are pivotal in Visual Business Analysis.

Modeling should happen at the start of an agile project during iteration 0 or inception. It's important to note, too, that modeling is not about gathering or defining "requirements"; it's about creating hooks on which to hang questions so you can explore them properly later. It’s like saying: “This is how we understand it right now. Let’s use this to ask and answer our questions.”

The benefits of creating models like this are threefold:

models put everyone on the same page
models provide a solid foundation for design and development thinking
models simplify decision-making later because you’ve outlined the big picture better

Austin Govella sums it up nicely: "these kinds of models frame how the team thinks about how to solve its various problems." (source)

2. Evaluation

Evaluation is the second place where UX designers bring value to an agile project. As a UX designer, I am thrilled (and you should be, too!) that agile has evaluation built into each iteration.

Agile evaluation is slightly different from traditional usability testing. In addition to investigating issues of labeling, interaction, and navigation, agile evaluation aims to test hypotheses and validate design decisions. At a high-level, you’re, at least, trying to answer these questions:

Are we headed in the right direction with these designs?
What can we improve upon within this release cycle?
Does the system model align with the user’s mental model?

Each evaluation and planning phase is a critical point for a UX designer and/or researcher to contribute to the process. They have experience planning and facilitating usability tests to maximize the return for their time and effort. Because agile cycles move quickly, it’s important to be efficient with evaluations. Not asking good questions and not knowing what to evaluate means you miss opportunities to improve the product. Asking good questions helps validate and clarify requirements, and helps identify details that improve the models.

Additionally, evaluation findings enable the agile team to validate the current project trajectory or to correct course by using the findings to inform planning for the next iteration.

Using a UX designer’s skills to conduct efficient evaluations at regular intervals lets the team test and validate ideas while there is still time to make adjustments. This inevitably leads to a better product than if you wait until Release 1 to do evaluation.

3. Facilitation (Daily)

The third area, and a bonus opportunity, where UX designers can provide added value is in day-to-day activities.

Daily UX involvement in agile should focus on facilitation. Agile methodologies champion collaboration and encourage design contributions from all team members. That doesn't just happen magically. You know this. I'm sure everyone's seen a brainstorming session, or similar exercise, spiral out of control because no one was steering.

A UX designer can help everyone understand one another using pictures, diagrams, role-playing, whatever. Project teams include developers, designers, product owners, stakeholders, and many other voices; and they all think differently than one another. Each of these perspectives brings something valuable to the table, but they need someone to help them lay it all out and make sense of it, and they need that help daily.

By leading regular group design activities, like Design Studios, a UX designer can:

help team members foster a sense of ownership for their ideas and for project outcomes;
create sketches, wireframes, prototypes, and other design artifacts that become the project’s Rosetta Stone—the common reference point that helps the different stakeholders communicate and understand each other;
they can be available to answer developer's questions that invariably come up when implementing an idea; and,
they can continuously improve and adapt the models as new information arrives from research and evaluation.

At any point in the project, a UX designer can be called upon to lead a focused conversation about the design and how to prioritize the next steps.

Summary

In summary, when a UX designer is integrated into an agile team and helps model the business processes, interaction channels, and user behaviours at the start of a project, it gives everyone a clear, common vision of what they're working with, and it provides a foundation to build upon going forward. When a UX designer asks the right questions during evaluation, the models evolve, the requirements become clearer, and "bad ideas" are caught before it's too late. And, when a UX designer facilitates group thinking and collaboration on a daily basis, design decisions get made faster and team members have a stronger sense of ownership of the final product.

Experience Maps: A Case Study

2013-02-12T20:34:58Z

Last summer I received an email from Kent Grayson, a marketing professor at the Kellogg School of Management at Northwestern University. Kent had seen the experience maps we created for Comcast and was interested in writing a case study about them.

In Kent's words, "the case would inspire [MBA] students not only about the benefits of experience maps but also the more general principle of how beneficial it is to deeply understand the customer experience."

Last summer Kent wrote up the case study, I provided some details on how we developed the experience maps, and late last year it was published. You can get a copy for a mere $6.95 from the Harvard Business School website.

Harvard Business School is the leading source of these case studies worldwide, which means that in the next couple of years hundreds of business school students could read this and start to apply user experience research and design practices in their work. Exciting!

nForm at the 2013 IA Summit

2013-01-29T17:31:46Z

We're very excited to have two of our own speaking at this year's IA Summit in Baltimore. The Summit is one of the top IA/UX events anywhere, so we're honoured to be attending as speakers.

Ammneh will be talking about the need for UX practitioners to bring clarity and simplicity to our communications. Her talk, "Eating Our Own Dogfood: Simplicity in Practice and Not Just Design" will be on Sunday. Dennis will be presenting on on the soft skills UX practitioners need to cultivate in order to be successful. "The Zen of Consulting: A Meditation on Finding the Path" is scheduled for Friday.

As always, the program looks fantastic. The theme of "building bridges with people who don't know what we do" is one we think about a lot, as we often find ourselves on teams that are new to our perspective and methods.

Ammneh and Dennis are pumped (and more than a little scared) to be sharing ideas at this year's Summit. We hope to see you there!

Visual Business Analysis

2013-01-07T12:52:11Z

In recent years we’ve worked on a number of projects in which one of our designers has partnered with a client’s business analyst. Going into these projects, our rough approach has been for the BA to document requirements while we research end-users to build an understanding of their context. Then we design the UI to meet the requirements in a way that fits users.

One of the intriguing things we’ve observed in these situations is that, no matter how skilled and detailed the BA is, we always end up reopening the requirements discussion once we put screen designs in front of people. We think this is because of a gap in the traditional BA approach.

A gap in the BA approach?
BA methods, as described in the Business Analysis Body of Knowledge (BABOK Guide), focus on breaking complexity down into small, manageable pieces. Although a reductionist philosophy isn’t explicitly stated, it’s apparent that the essential method is to reduce big things into their smaller components.

When dealing with large, complex systems this is both logical and necessary. BAs have a wealth of methods for gathering and documenting requirements in a granular way. What’s missing from their toolkit, however, are methods to visualize how those requirements will come together into a coherent solution.

This, as it turns out, is a problem.

A coherent picture changes how people think about requirements
What we’ve observed is that people engage in a deeper way with UI visualizations than they do with text-based requirements or abstract diagrams. This is especially true when dealing with stakeholders who aren’t intimately familiar with web or application development. In order for these people to assess the completeness of a list of requirements, they need to see how everything comes together.

We believe the main reason requirements discussions reopen once design begins is that visual representations of the whole system reveal new requirements.

This has major implications for how requirements are defined. In complex systems, the traditional reductive BA process can never yield all the requirements because large lists of requirements have no collective meaning. Each requirement can be evaluated on its own, but it can’t be evaluated in relation to others unless you know how they fit together. This makes it virtually impossible for anyone looking at the list to know if the requirements are complete.

In addition, people can’t walk through realistic usage scenarios using a list of requirements. This means they have no way to assess whether the proposed system will function adequately in a realistic context.

As a result, we’ve come to believe that requirements analysis is essentially incomplete without modeling a coherent picture of the whole. And what could be more risky than incomplete requirements?

Requirements and risk
One could spend days debating the most challenging and risky aspects of complex application development projects. However, you would likely find consensus around the topic of requirements. Incomplete or changing requirements are among the most common risks teams face, and may be the greatest cause of project failure. We use visual models of the system during requirements gathering to solidify requirements and reduce overall project risk. We call this method Visual BA.

Visual business analysis
Requirements gathering and analysis are really about answering the question “what does our new _x_ need to do to be successful?”. In traditional application development projects, BAs answer this question by gathering requirements. Designers tend to be engaged later in the project.

Others have written about the need to include designers early , but we think Visual BA goes beyond ‘soaking up business context’ or ‘influencing scope’. In Visual BA a designer actively participates in defining and analyzing requirements by providing visualizations that allow team members to test scenarios and build a shared language.

Visual Business Analysis is the deliberate use of sketches, wireframes and prototypes to model how a system will work in order to learn more about what is required for success.

Visuals are used to ask questions and to build a common understanding of what success will look like. They’re used to deliberately provoke discussion, and to help people think about the problem in new and unexpected ways. They’re used to evade the trap of gathering requirements that pre-suppose a certain kind of solution.

It’s important to recognize that these visualizations are used as tools to dig deeper on requirements. They are not just steps on the path to the final design. They inform final design, but their primary purpose is to test known requirements and expose new ones. They are visual tools that help focus and test the team’s thinking before what would normally be thought of as the “design phase”.

Our Visual BA process includes both an analytic component (usually performed by a BA) and a synthetic or design component (usually performed by a designer). One person could perform both tasks, but we’ve had success pairing BAs and designers throughout the process. Subject-matter experts, technical architects and business stakeholders are also key contributors.

Iteration is a critical part of our approach. The team works through successive rounds of analysis, design and review by stakeholders to refine requirements and model a system that meets everyone’s needs. This is true regardless of the development methodology (agile, waterfall) being used on the project.

Is visual business analysis for you?
We think visual business analysis would benefit any project. Whether a big, small, complex or simple project, modeling how things come together helps people decide what should be in and what should be out.

But Visual BA is especially important when dealing with large, complex systems. Increased complexity brings special challenges that are best met with visualizations.

If you have more requirements than you can hold in your head at one time, Visual BA can help you understand how everything will come together, and give you a tool to assess the completeness of your requirements.

If you need to untangle competing business drivers, Visual BA will allow you to test different scenarios and to see the on-screen impact of specific trade-offs.

If you’re dealing with complex internal stakeholder relationships, or working with people who have different levels of technical sophistication, Visual BA will provide a common language that will ensure everyone has the same understanding.

In these and other complex situations, long lists of abstract requirements become a barrier to understanding and good decision-making. Visual BA fills the gap in the traditional, reductive BA process by modeling how things might come together. This helps teams develop a better understanding of what success requires before development starts.

Event: Making Sense of Web Analytics (Edmonton, Nov 27)

2012-11-15T04:41:59Z

We're running a short-but-informative workshop in Edmonton on November 27. This one is on web analytics, and we'll have two speakers sharing their insights on using analytics to make better design and business decisions. Details and a registration form are below. As always, tickets are free but attendance is capped (and this one is almost sold out already). Hope to see you there!

Event Details

Making Sense of Web Analytics
Tuesday, November 27, 8:30 a.m. to 10 a.m.
Matrix Hotel
10640 - 100 Avenue
Edmonton, Alberta
View this on Eventbrite

Session Description

Many organizations we work with are just scratching the surface of their web analytics tools. At our next event we'll have two talks about how you can get more value from your analytics—including understanding user behaviour, evaluating the effectiveness of your content and design, and answering key questions about your organization's online performance.

Ammneh Azeim is a senior consultant with nForm and a Google Analytics analyst. Ammneh will talk about starting a measurement program, using analytics to answer business questions, and creating basic key performance indicators to track your online performance.

Tim Schneider is the Digital Analytics Manager at the University of Alberta where he's created a measurement program that's guiding the university's digital strategy. Tim leads a small team of analysts that examine the performance of the U of A's websites and recommends content and design improvements. Tim will discuss the evolution of the U of A's analytics program, share some of his success stories, and talk about how they're using analytics tools to make better decisions about their online efforts.

Registration

Event registration for Making Sense of Web Analytics powered by Eventbrite

In Praise of Difficult Questions

2012-11-14T13:23:30Z

You know the moment. You're discussing the work you've poured your soul into for the past few weeks and someone asks a question. Normally, that's no problem because you know your stuff and you have rationale for all of the choices you've made. But this is a question that you just hadn't anticipated. Someone has exposed a hole in your thinking.

For many this is a nightmare scenario. All through life we're taught that we need to be in control; we need to be on top of things; we need to be… right. What do you do with one of those questions?

I had this experience recently on a large, highly complex project for an application to be used by clerks in the courtroom. After many design iterations I was asked how a clerk would search and filter a certain portion of the data. My response: "Um… I don't know. They can't. Why would they need to do that?"

It turns out there was an important scenario we had never investigated. After much discussion we decided that clerks actually needed a couple of simple easy-to-run reports instead of search and filter. But the key to uncovering that was my willingness to say "I don't know. I missed that. Tell me more". If I'd been unwilling to expose my ignorance; if I'd said "Oh, yeah – I'm working on that now. I'll have it to you tomorrow" we never would have gotten to the bottom of the need.

It's taken me years, but I've learned to love difficult questions. I've learned to seek them out. Because they're gateways to massive learning. They're keys to making my work better.

Donald Rumsfeld famously said "There are known unknowns; that is to say there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know." Despite the somewhat garbled delivery, he makes a great point. There are often questions that we don't realize we should ask.

Difficult questions reveal the things you didn't know you didn't know. And they're worth their weight in gold.

Drop by Our Open House on October 24

2012-10-15T15:56:32Z

This summer, after much searching and renovating, we moved our team in Edmonton to a new studio on 104 Street. We're having an open house on Wednesday, October 24, to celebrate.

We'd love it if you'd drop by, see our new space and meet the team (there'll be wine and appetizers from Culina too). Just send us an email letting us know you'll be there.

The details:
Address: #201, 10237 104 Street
Time: Drop by anytime between 3 and 6 p.m.
Map: http://goo.gl/maps/ZGj7i
RSVP: Email better@nform.com

Here are a few photos of our two-month renovation project (starting with the original layout from the previous tenant):

Event: Transforming Government Web Strategy (Toronto - September 20)

2012-08-29T16:29:43Z

Earlier this year we ran a sold-out seminar on public sector web strategy in Edmonton. We had fantastic feedback from attendees, so we decided to bring this event to Toronto on September 20.

If you work on the web in the public sector, or if you're interested in how to get traction for user experience initiatives in a large organization, this session will be well worth your time. As always, attendance is capped, so you'll want to register early (you'll find a registration form at the bottom of the page).

Event Details

Transforming Government Web Strategy
Thursday, September 20, 3:00 p.m. to 5 p.m.
Intercontinental Hotel
220 Bloor St W
Toronto, ON M5S 1W2

Session Description

Over the past two years the Government of British Columbia has been transforming its web presence. As part of a government-wide strategic initiative, ministries are making have been instructed to transform their sites to a citizen-focused, service oriented web presence. They're now consulting with citizens during the research and design phases of their web development projects. And they're improving their content, navigation and services so citizens can do more online.

One government department, staffed with user experience experts, is leading these changes. They've provided direct support and developed training and toolkits to help ministries plan all aspects of their web projects, from strategy and research to design and governance. And they consult with ministries to help them coordinate their efforts and align them with the government's new citizen-focused direction.

Dominique Bohn and Blair Neufeld have been at the centre of this transformation. In this one-hour presentation they'll talk about the strategies behind the BC government's new approach to the web, the tools they're using to transform their web presence, and the lessons they've learned in the process.

Session Leaders

Dominique Bohn

Dominique is the Director of Web Design in the BC Ministry of Labour, Citizens' Services and Open Government, Strategic Initiatives Division.

Blair Neufeld

Blair Neufeld is the Director of Information Architecture in the in the BC Ministry of Labour, Citizens' Services and Open Government, Strategic Initiatives Division.

Registration

Sell Tickets through Eventbrite

A Touch of the Extraordinary

2012-08-10T13:15:59Z

Most of us would agree that the quality of our boss has a big impact on the quality of our job. A good boss supports us in ways that make us better at what we do, and a bad boss confuses, demotivates, and generally drags us down. In a small business this importance is magnified because there’s no one else to go to, no other manager to provide direction or support.

A few months ago Inc magazine looked at some qualities that make a good boss – one that makes their employees and, by extension, their entire company better. Inc’s list of 8 Core Beliefs of Extraordinary Bosses caught the eye of several nForm-ers because it seemed to paint a striking portrait of our boss, Gene Smith.

At first, it was a shock to see that Gene displays all eight of the core beliefs. Sure, he’s a good boss and everything, but all eight? But there’s no question – he has ‘em all. A couple of examples:

Management is service, not control: Who knows how many mistakes we’ve made over the years? Many. Yet, we’ve never had a smack down. Not even the time one of us (who shall remain nameless) opened up the FTP server and risked all that was behind the wall. In fact, Gene may have laughed when the culprit 'fessed up. Of course, this may just prove that he’s crazy.

Work should be fun, not mere toil: Thanks for making us play laser tag, Gene, even though some of us really did not want to in the first place. It felt good to shoot you. Really good.

We could easily illustrate every point, but perhaps the entire list can be boiled down to a couple of things: empathy and a concern for the humans involved in any situation. In our previous building there was a lady who ran a small windowless shop. She loved to visit with customers and she could be hard to escape from. One time, over the drinks we bought from her, we were laughing about the many ways the shop lady could trap us. Gene laughed and then observed: "I wonder how it is for her to be in a shop with no windows and not many customers. It must be hard."

Maybe Gene's great leadership secret is his ability to understand other people's point of view and to evaluate them in a fair manner. Those are important qualities in UX design, in running a business, and in life.

So on this, Gene’s birthday, the nForm crew would like to say how glad we are to have a leader that has been officially endorsed by Inc Magazine. Or close enough. Not only do we benefit from a great work environment, our clients benefit from a team that has been empowered to do the best work it can.

Thanks Gene, from the whole nForm crew. Happy Birthday.

Man, we're gonna catch hell when he sees this post. No more blog privileges for you!

We're Moving July 31

2012-07-28T04:13:19Z

If you have trouble reaching us on Tuesday, July 31, it's because we're relocating to our new studio. Our telephones will be out that day but the team will still be available by email and on their cell phones.

This is a short but significant move for us. Phyiscally, we're only moving a block north. But we'll be in a larger, newly renovated space with tons of character that we've designed for collaboration.

For our Edmonton friends, our new office 104th street between 102nd and 103rd avenue above the old Business Link office. Or, almost exactly between Roast in the Mercer Building and Credo.

Here are a few pictures of the construction:

And here's a map:

View nForm - New Office in a larger map

Emotional response cards: a simple user research tool

2012-05-28T21:27:34Z

Being emotional is often frowned upon in a business environment. But on a recent research project we decided to test out a new tool to help people express their feelings and provide us with better interview results.

We call the tool emotional response cards. In this blog post we are going to tell you how we used these cards and how they helped our research.

The Tool

We adapted our emotional response cards from a couple of other examples we have seen. We started with Microsoft's product reaction cards, a set of 118 descriptive words that describe product characteristics. We reduced that to 50 terms, and tried to select words that were opposites or described opposing characteristics similar to a bipolar emotional response test (or BERT).

We then printed the terms on standard business card stock. Rather than have people use the cards to describe their reactions to a product, we were conducting interviews about participants experiences with complex services.

How We Used It

Last fall we travelled to four Western Canadian cities to interview ordinary people about the services they receive from a large organization. This organization provides services that people use just about every day and over long periods of time.

Our interviews were divided into two parts. The initial portion was a normal interview with questions and answers, as well as the usual probing and discussion initiated by the facilitator. We found that many people would talk about the services they received, but they sometimes couldn't describe their experiences in detail, or could only relate them in a superficial way.

The second part of our interviews required the participants to look at our set of emotional response cards and choose the ones that described the services they mentioned in the first part of the interview. We noticed that the participants opened up and were able to articulate the usefulness or the lack of it in the services better. The cards gave participants a vocabulary they could use to describe their experiences.

We devoted an equal amount of time, roughly, to each activity.

The Results

So what made emotional response cards a useful tool during the interviews?

People remember emotions. People often remember how they felt about a product or service more easily than how they interacted with it. When participants started with the emotion, they were able to expand on the experience they had with the service.

People need memory triggers. Open-ended questions are good, but the cards helped remind people of their experiences, especially the ones that happened far in the past. We thought the cards helped participants reconstruct their memories by linking together the emotions they felt over the whole experience.

Props help people express themselves. We noticed during our sessions that participants would spread out the cards, pick them up, stack them, and engage in other kinds of physical manipulation as they started to describe their experiences.

Emotions keep people honest. Some people intend to be polite when talking about a product or a service. However, we felt our participants were much more frank when choosing the emotional response cards that described their interaction with our client (especially compared to the first part of the interview).

In summary, we think emotional response cards helped us collect more useful data from these interviews. If you want to try them out you can download our template (below) and print your own set on Avery 05371 white business card stock.

Big thanks to Gene Smith who provided most of the content for this blog post and came up with the idea of using emotional response cards in the project.

Emotional response cards

View more documents from nForm User Experience

nForm Blog

The Experience Gap (UX Camp Edmonton Presentation)

User Experience Debt

A Brief History of the Term

What is UX debt?

Classifying UX Debt

Intentional UX Debt

Unintentional UX debt

Summary

Further Reading

Training vs. Design

The Economic Consequences of Ignoring Design

What's the Problem?

What Can We Do Instead?

How Do We Fix This?

Redeploy your training budget

Iterate

After Launch: Fix the Simplest Non-functional Problems First

Quantify the Negative Externalities

Event: Content Strategy for the Public Sector (April 11)

Event Details

Session Description

Speaker Bio

Registration

When to apply UX effort in agile

1. Modeling

2. Evaluation

3. Facilitation (Daily)

Summary

Experience Maps: A Case Study

nForm at the 2013 IA Summit

Visual Business Analysis

Event: Making Sense of Web Analytics (Edmonton, Nov 27)

Event Details

Session Description

Registration

In Praise of Difficult Questions

Drop by Our Open House on October 24

Event: Transforming Government Web Strategy (Toronto - September 20)

Event Details

Session Description

Session Leaders

Registration

A Touch of the Extraordinary

We're Moving July 31

Emotional response cards: a simple user research tool

The Tool

How We Used It

The Results