This is the sixth fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.
Have you shown this product to any actual humans who are like the users?
Acceptance is the act of testing your vision against the user’s needs. It’s not about whether the software works, or whether it’s usable, it’s about whether the user thinks it will help them get their work done.
The people you need to get to test it are users. This is not the same as people who you are selling the product to, and it may not be the same as the people you meet at trade shows. These are the people who sit down at their cubicle, or in their fire truck, or whatever they use, and count on their software to help them do their job. Find one of those people. Find five of those people. You don’t need statistical significance for this early stage test, you just need to hear something from outside the echo chamber.
Running an acceptance test
Show them the product. You can use a mockup if you need to, but don’t ask them how they work. Ask them what they are trying to do, and if you already know that, give all of them the same user script for consistency.
Shut up and watch. No, shut up. Don’t help them. Don’t explain how you meant it to work. Just ask them to perform a task and see how it goes. Take notes. It’s lovely to have a big expensive testing center like Microsoft and Intel have, with two way mirrors and cameras, but you can learn enough to be useful with a Webex and some listening skills.
You will come out of this test (probably) feeling ruffled and angry and frustrated with the users. Why would they want to even DO that? Why couldn’t they see the logic of the workflow? I feel like this when I get critiques on documents I have written. I sometimes feel like the feedback is wrong.
The user is not wrong.
The user is trying to tell you what you need to know to delight them, or at least satisfy them, and that is really important to your health as a company.
If you can’t hire an expert, become a student
If you can’t get people to agree to hiring UX, learn how to do it yourself. It’s really difficult to get people on a tight budget to pay for someone expensive to ask users about their feels about the software. It just is. You can talk them into hiring a user interface/front end person, but user experience? Nah.
So you’re going to have to do it yourself. You’re going to have to be the advocate for designing in not just utility, but usability. This is an amazing career-builder, but it probably won’t pay off at your current company. Maybe later.
To teach yourself the fundamentals of user experience, I suggest starting with Kathy Sierra’s excellent book, Badass: Making Users Awesome. Do buy it in paperback — the layout is unique.
Summary
There are lots of websites, books, talks, and skywritten messages on specific ways to do user experience, but it all comes back to the same question: am I helping the user do the thing they want?
Other suggested books:
Microinteractions by Dan Saffer
The Design of Everyday Things by Don Norman
Don’t Make Me Think by Steve Krug
The User’s Journey: Storymapping Products That People Love by Donna Lichaw and Eva Lotta-Lamm
This blog post is part 6 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).