Oct
20

Usability Testing Is Undermining UX Design

Source: UXMatters

By Peter Hornsby

Published: October 21, 2014

“I’ve recently had a number of conversations with designers that suggest their perception of usability testing is fundamentally wrong. … They believe that nothing can be known about a design that a team is going to implement unless that design has been tested with the target audience.”

I’d be the first to admit that there are a lot of things that irritate me. These include, but are not limited to the following:

  • people referring to a small, potent coffee as an “expresso”
  • people saying “pacific” when they mean specific
  • the use of the word intuitive in describing a design or product requirements
  • anything else that undermines the delivery of effective UX design

And although I’ve never before considered usability testing as something that falls into the large—and growing—list of things that undermine effective UX design work, I’ve recently had a number of conversations with designers that suggest their perception of usability testing is fundamentally wrong. I’ve heard both junior and senior designers express their perception of usability testing in different ways, but the core message is the same: They believe that nothing can be known about a design that a team is going to implement unless that design has been tested with the target audience.
Usability Testing Is Undermining UX Design

Oct
20

Keys to a Successful Digital Strategy: CapTech Ventures

Source: UXMatters

By Bill Rattner

Published: October 21, 2014

“One of the major benefits of a modern digital strategy is its innate ability to centralize an organization’s numerous different operational facets. For any business, interdepartmental accountability is key to streamlined operations….”

One of the major benefits of a modern digital strategy is its innate ability to centralize an organization’s numerous different operational facets. In other words, it gives us the ability to avoid the fragmented approach that we often encounter in the world of 21st century business. Why is this so important? The answer to this question is as simple as it is critical. For any business, interdepartmental accountability is key to streamlined operations—and without effective cross-channel communications, efficiency will suffer as a result. An example that shows the critical nature of digital strategy is the way in which CapTech Ventures provided a from-the-ground-up digital strategy for the energy giant Dominion Resources.
Keys to a Successful Digital Strategy: CapTech Ventures

Oct
20

Persuading Clients That the Need for User Research and Usability Testing Is Real

Source: UXMatters

By Janet M. Six

Published: October 21, 2014

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our panel of UX experts discusses how to explain the need for user research and usability testing to a client who wonders why an expert review is not enough.

I hope you enjoy this month’s lively discussion about the best ways to persuade a client that user research and usability testing are a necessary part of a project. Why is it essential for UX designers to rely on user research and usability testing? What value does getting the views of users provide? What data already exists about users and  what are the gaps in that knowledge? How can all of this data support your UX design work and deliver project outcomes that deliver value to your client? You need to convey the answers to all of these questions to your clients—and be sure to connect your answers to your clients’ business reasons for starting a project in the first place.
Persuading Clients That the Need for User Research and Usability Testing Is Real

Oct
20

Introducing the Build-Measure-Learn Approach to an Analytics Tool’s Redesign

Source: UXMatters

By Stephanie Schuhmacher

Published: October 21, 2014

“As UX professionals, we pride ourselves on making software that is human friendly and easy to use. But keeping the right balance between adding features that customers and users need and maintaining a clean, simple user interface design is often harder than it seems it should be.”

As UX professionals, we pride ourselves on making software that is human friendly and easy to use. But keeping the right balance between adding features that customers and users need and maintaining a clean, simple user-interface design is often harder than it seems it should be. This is a challenge that most product teams have in common. In this case study, I’ll describe how our team at Bloomfire integrated Lean UX into our product-development process to address this challenge.

How can you distinguish between what the people who purchase and use your products say they want and what they actually need? Luckily, there are some effective ways to reduce the risk that you might design products your customers don’t want or your users can’t use and, instead, to design for their actual needs.
Introducing the Build-Measure-Learn Approach to an Analytics Tool’s Redesign

Oct
20

Bridging UX & Web Development: Better Results Through Team Integration

Source: UXMatters

By Jack Moffett

Published: October 21, 2014

“A collaboration life cycle maps the activities of designers to those of the developers in each phase of a typical product development process. The cycle starts with requirements analysis….”

This is a sample chapter from Jack Moffett’s new book, Bridging UX & Web Development: Better Results Through Team Integration. 2014 Morgan Kaufmann.

Chapter 3: Collaboration Life Cycle

Process. Regardless of what type of designer you are—graphic, information, interaction, service, industrial, game—you follow a common process. It typically begins with research and observation as you learn about the people who will use the product of your efforts and the context of its use. Then there’s synthesizing of the information you’ve collected, coupled with ideation and iterative prototyping, as you plan what is to be built, physically, digitally, or figuratively. Ideally, this also involves some form of testing with users to verify your rationale. As I illustrated in Chapter 1, this is where many of us stop, passing our specifications on to the developers who will implement the work. There are also varying degrees of participation in following phases of testing, bug fixing, and further documentation. Of course, there are sundry variations, Agile and Lean UX being the most notable, but the same activities are involved (or should be).
Bridging UX & Web Development: Better Results Through Team Integration

Oct
18

Personalizing Git with Aliases

Source: A List Apart

Part of getting comfortable with the command line is making it your own. Small customizations, shortcuts, and time saving techniques become second nature once you spend enough time fiddling around in your terminal. Since Git is my Version Control System of choice (due partially to its incredible popularity via GitHub), I like to spend lots of time optimizing my experience there.

Once you’ve become comfortable enough with Git to push, pull, add, and commit, and you feel like you’d like to pursue more, you can customize it to make it your own. A great way to start doing this is with aliases. Aliases can help you by providing shorthand commands so you can move faster and have to remember less of Git’s sometimes very murky UI. Luckily, Git makes itself easy to customize by setting global options in a file named .gitconfig in our home directory.

Quick note: for me, the home directory is /Users/jlembeck, you can get there on OSX or most any other Unix platform by typing cd ~ and hitting enter or return. On Windows, if you’re using Powershell, you can get there with the same command and if you’re not using Powershell, cd %userprofile% should do the trick.

Now, let’s take a look. First, open your .gitconfig file (from your home directory):

~/code/grunticon master* $ cd ~
~ $ open .gitconfig

You might see a file that looks similar to this:

[user]
  name = Jeff Lembeck
  email = your.email.address@host.com
[alias]
  st = status
  ci = commit
  di = diff
  co = checkout
  amend = commit --amend
  b = branch

Let’s look at the different lines and what they mean.

[user]
  name = Jeff Lembeck
  email = your.email.address@host.com

First up, the global user configuration. This is what Git references to say who you are when you make commits.

[alias]
  st = status
  ci = commit
  di = diff
  co = checkout
  amend = commit --amend
  b = branch

Following the user information is what we’re here for, aliases.

Any command given in that screen is prefaced with git. For example, git st is an alias for git status and git ci is git commit. This allows you to save a little time while you’re typing out commands. Soon, the muscle memory kicks in and git ci -m “Update version to 1.0.2” becomes your keystroke-saving go-to.

Ok, so aliases can be used to shorten commands you normally type and that’s nice, but a lot of people don’t really care about saving 10 keystrokes here and there. For them, I submit the use case of aliases for those ridiculous functions that you can never remember how to do. As an example, let’s make one for learning about a file that was deleted. I use this all of the time.

Now, to check the information on a deleted file, you can use git log --diff-filter=D -- path/to/file. Using this information I can create an alias.

d = log --diff-filter=D -- $1

Let’s break that down piece by piece.

This should look pretty familiar. It is almost the exact command from above, with a few changes. The first change you’ll notice is that it is missing git. Since we are in the context of git, it is assumed in the alias. Next, you’ll see a $1, this allows you to pass an argument into the alias command and it will be referenced there.

Now, with an example. git d lib/fileIDeleted.js. d is not a normal command in git, so git checks your config file for an alias. It finds one. It calls git log --diff-filter=D -- $1. And passes the argument lib/fileIDeleted.js into it. That will be the equivalent of calling git log --diff-filter=D -- lib/fileIDeleted.js.

Now you never have to remember how to do that again. Time to celebrate the time you saved that would normally be spent on Google trying to figure out how to even search for this. I suggest ice cream.

For further digging into this stuff: I got most of my ideas from Gary Bernhardt’s wonderful dotfiles repository. I strongly recommend checking out dotfiles repos to see what wild stuff you can do out there with your command line. Gary’s is an excellent resource and Mathias’s might be the most famous. To learn more about Git aliases from the source, check them out in the Git documentation.


Read the full article

Oct
18

This week’s sponsor: Vitamin T

Source: A List Apart

Vitamin T connects amazing digital creative talent with equally awesome mid-sized companies and ad agencies. Freelancers rejoice!


Read the full article

Oct
18

Nishant Kothary on the Human Web: The Politics of Feedback

Source: A List Apart

“Were you going for ‘not classy’? Because if you were, that’s cool. This isn’t classy like some of your other work,” said my wife, glancing at a long day’s work on my screen.

“Yep. That’s what I was going for!” I responded with forced cheer. I knew she was right, though, and that I’d be back to the drawing board the next morning.

This is a fairly typical exchange between us. We quit our jobs last year to bootstrap an app (for lack of a better word) that we’re designing and building ourselves. I’m the front-end guy, she’s the back-end girl. And currently, she’s the only user who gives me design feedback. Not because it’s hard to find people to give you feedback these days; we all know that’s hardly the case. She’s the only one providing feedback because I think that’s actually the right approach here.

I realize this flies in the face of conventional wisdom today, though. From VC’s and startup founders emphatically endorsing the idea that a successful entrepreneur is characterized by her willingness—scratch that: her obsession with seeking out feedback from anyone willing to give it, to a corporate culture around “constructive” feedback so pervasive that the seven perpendicular lines-drawing Expert can have us laughing and crying with recognition, we’ve come to begrudgingly accept that when it comes to feedback—the more, the merrier.

This conventional wisdom flies in the face of some opposing conventional wisdom, though, that’s best captured by the adage, “Too many cooks spoil the broth.” Or if you’d prefer a far more contemporary reference, look no further than Steve Jobs when he talked to Business Week about the iMac back in ’98: “For something this complicated, it’s really hard to design products by focus groups. A lot of times, people don’t know what they (customers) want until you show it to them.”

So which is it? Should we run out and get as much feedback as possible? Or should we create in a vacuum? As with most matters of conventional wisdom, the answer is: Yes.

In theory, neither camp is wrong. The ability to place your ego aside and calmly listen to someone tell you why the color scheme of your design or the architecture of your app is wrong is not just admirable and imitable, but extremely logical. Quite often, it’s exactly these interactions that help preempt disasters. On the flip side, there is too much self-evident wisdom in the notion that, borrowing words from Michael Harris, “Our ideas wilt when exposed to scrutiny too early.” Indeed, some of the most significant breakthroughs in the world can be traced back to the stubbornness of an individual who saw her vision through in solitude, and usually in opposition to contemporary opinion.

In practice, however, we can trace most of our failures to a blind affiliation to one of the two camps. In the real world, the more-the-merrier camp typically leaves us stumbling through a self-inflicted field of feedback landmines until we step on one that takes with it our sense of direction and, often more dramatically, our faith in humanity. The camp of shunners, on the other hand, leads us to fortify our worst decisions with flimsy rationales that inevitably cave in on us like a wall of desolate Zunes.

Over the years I’ve learned that we’re exceptionally poor at determining whether the task at hand calls for truly seeking feedback about our vision, or simply calls for managing the, pardon my French, politics of feedback: ensuring that stakeholders feel involved and represented fairly in the process. Ninety-nine out of a hundred times, it is the latter, but we approach it as the former. And, quite expectedly, ninety-nine out of a hundred times the consequences are catastrophic.

At the root of this miscalculation is our repugnance at the idea of politics. Our perception of politics in the office—that thing our oh-so-despicable middle managers mask using words like “trade-off,” “diplomacy,” “partnership,” “process,” “metrics,” “review” and our favorite, “collaboration”—tracks pretty closely to our perception of governmental politics: it’s a charade that people with no real skills use to oppress us. What we conveniently forget is that politics probably leads to the inclusion of our own voice in the first place.

We deceive ourselves into believing that our voice is the most important one. That the world would be better served if the voices of those incompetent, non-technical stakeholders were muted or at the very least, ignored. And while this is a perfectly fine conclusion in some cases, it’s far from true for a majority of them. But this fact usually escapes most of us, and we frequently find ourselves clumsily waging a tense war on our clients and stakeholders: a war that is for the greater good, and thus, a necessary evil, we argue. And the irony of finding ourselves hastily forgoing a politically-savvy, diplomatic design process in favor of more aggressive (or worse, passive-aggressive) tactics is lost on us thanks to our proficiency with what Ariely dubs the fudge factor in his book The (Honest) Truth About Dishonesty: “How can we secure the benefits of cheating and at the same time still view ourselves as honest, wonderful people? As long as we cheat by only a little bit, we can benefit from cheating and still view ourselves as marvelous human beings. This balancing act is the process of rationalization, and it is the basis of what we’ll call the fudge factor theory.”

Whether we like it or not, we’re all alike: we’re deeply political and our level of self-deception about our own political natures is really the only distinguishing factor between us.

And the worst part is that politics isn’t even a bad thing.

On the contrary, when you embrace it and do it right, politics is a win-win, with you delivering your best work, and your clients, stakeholders, and colleagues feeling a deep sense of accomplishment and satisfaction as well. It’s hard to find examples of these situations, and even harder to drive oneself to search for them over the noise of the two camps, but there are plenty out there if you keep your eyes open. One of my favorites, particularly because the scenarios are in the form of video and have to do with design and development, comes in the form of the hit HGTV show Property Brothers. Starring 6'4" identical twins Drew (the “business guy” realtor) and Jonathan (the “designer/developer” builder), every episode is a goldmine for learning the right way to make clients, stakeholders, and colleagues (first-time home owners) a part of the feedback loop for a project (remodeling a fixer-upper) without compromising on your value system.

Now, on the off-chance you are actually looking for someone to validate your vision—say you’re building a new product for a market that doesn’t exist or is already saturated, or if someone specifically hired you to run with a radical new concept of your own genius (hey, it can happen)—it’ll be a little trickier. You will need feedback, and it’ll have to be from someone who is attuned to the kind of abstract thinking that would let them imagine and navigate the alternate universe that is so vivid in your mind. If you are able to find such a person, paint them the best picture you can with whatever tools are at your disposal, leave your ego at the door, and pay close attention to what they say.

But bear in mind that if they are unable see your alternate universe, it’s hardly evidence that it’s just a pipe dream with no place in the real world. After all, at first not just the most abstract thinkers, but even the rest of us couldn’t imagine an alternate universe with the internet. Or the iPhone. Or Twitter. The list is endless.

For now, I’m exhilarated that there’s at least one person who sees mine. And I’d be a fool to ignore her feedback.


Read the full article

Oct
18

This week’s sponsor: Pantheon

Source: A List Apart

Pantheon is the professional website platform developers, marketers, and IT use to build, launch, and run their Drupal and WordPress websites.

Get a perfect launch every time.


Read the full article

Oct
10

The Future of UX Leadership: Radical Transformation

Source: UXMatters

By Jim Nieters and Pabini Gabriel-Petit

Published: October 6, 2014

“Insights on how to help companies progress from delivering mediocre user experiences, as is all too common, to producing truly great experiences that differentiate their products and services in the marketplace.”

This column is the first in a series that will offer insights on how to help companies progress from delivering mediocre user experiences, as is all too common, to producing truly great experiences that differentiate their products and services in the marketplace. Doing so requires a radical transformation in the way business executives and UX teams engage in creating user experiences.

This series is not about making incremental improvements to the way UX teams work. It is about taking a different approach and driving radical transformation within organizations. No major changes in history have ever come about by playing it safe. Having said this, all of the ideas that we’ll share in this series have proven effective in one business context or another.
The Future of UX Leadership: Radical Transformation

Older posts «