The web standards movement has done amazing things for the web over the past few years. Not just for the web vaguely - specifically for web developers and for the users of the web alike. The web standards movement has taught developers to become more conscious of our coding practices both for ourselves, (for sake of efficiency and future friendly development practices) and for users, who we now know that we must be very considerate of as we design and implement solutions that work across a variety of browsers, devices, and accessibility contexts.

But as far as we have come in web standards and taking up the cause of users, and as much as "usability" has become both a buzzword and a staple of the modern web philosphy, we still have far to go.

How do I know? Because I know I have far to go - and I'm not an isolated sampling.

User Experience FTW

I am absolutely fascinated and energized by the concept of user-experience design. As I have progressed in my career and in my skill set, one of the most exciting aspects of web design & development to me personally has been focusing on the user experience.

This might be partly because I'm fascinated by people, and by relationships. So it's a natural connection for me to be intrugied by how what I design and build directly connects with the end user. Afterall, if I'm only designing for sake of design, there's something that feels pretty pointless about that. So in some sense user experience seems like the culmination of the creative process.

But as enamored as I am with user experience, and thinking about how users are going to interact with my work, and designing the user experience with all of it's nuances and insights - my habbits as a user experience designer are falling far short of where they should be.

How do I know? Because the last time I actually observed a user test was more than a year ago - I think. Maybe longer.

And I'm not alone. I talk to people all the time about web stuff and I can't remember the last time I talked with one of my industry peers about what someone learned from an actual user test case for a build. If I think hard enough I can recall a few such discussions with colleagues, but they have been few and far between. What's more, I can't recall a single such discusison I've had with an industry peer who was not a colleague.

And that's a big problem.

Going the Distance

Often the issue is mere laziness. We are really (speaking for myself, at least) content to listen to people who have done a fair amount of user studies, and just take the "best practices" we hear and apply them till the cows come home. But every one of the usability experts in our industry will tell you one of the most important "best practices" of usability or user experience is to actually conduct usability testing on your own project!

Only observing people actually using our products is going to reveal some of the specific problems with our work. We can apply best practices till we are blue in the face, but unless we actually observe people using what we build and design first hand, I guarantee we will still miss many fatal errors in the experiences we create.

If we are just considering the user experience but not actually testing our products on users, then we are only going part of the way in our usability efforts.

Not Just for the QA Team

Another problem is that sometimes, due to our being influences by the practices of larger agencies, actual user testing seems to fall as the responsibility of "the QA guy" after the build is complete. This is a grossly backwards workflow. This type of patten assumes that problems only need to be revealed after the majority of the work is done, and user testing is just part of polishing and fine-tuning.

But when we use the opposit workflow, looking for usability concerns all along the way while we design user experience, we gain the opportunity to make major adjustments while the opportunity cost and development cost of change is still relatively low, rather than having to fight the elephant of momentum that projects tend take on by the time they are almost finished.

Nobody wants to make major changes when something has been "almost finished", yet we pretend that somehow user testing is only really necessary once the heavy lifting has been done.

I still think there should be QA people who are really focused on finding the stuff that slips through the cracks, and being sort of like the last line of defense against critical experience errors. But that should never occur at the expense of we as developers shirking our own responsibility to thinking critically from a user perspective from the start, and actually observe users uncover problems with our work in the early phases and throughout the duration development.

Even more importantly, as we make this practice a reguar habbit, our thinking will evolve to where we may begin seeing things with a view more empathetic to the average user from the start, which will only serve to make us better programmers and UX architects over time and as a whole.

Guilty as Charged

I'm as guilty as anybody - so there's no finger pointing here. Just a firm personal challenge that I'm issuing myself, and anyone else who can see there is much to be gained by embracing actual user testing as hardcore as we embrace the best practices of usability in coding and design, and the trendiest of practices in front end engineering.

My personal goal is to begin to test every piece of code I design and build on at least two people. I'm going to set out a list of a few specific tasks (maybe 5-8) for each tester to accomplish with the software/app/site, and personally watch them do it.

I even have a wonderful OSX app from the folks at Clearleft called Silverback App, made for simple user testing. The app records your screen and your video camera at the same time, so you can observe the user and what they are doing after the test. To my shame, I've owned it for almost two years when I bought it with the intent of testing the CURE.org redesign in 2012, but haven't used it once.

Why the Sudden Soapbox?

Somebody unintentionally lit a fire under my butt. I was at Dan & Cherrie Denney's awesome Front End Design Conference over the weekend when a friend I met last year named Chad asked if during lunch me and my colleague Doug would mind taking a look at an app he is developing for a client to get some peer feedback/user feedback.

I was blown away. That was actually the first time an industry peer had ever asked to watch me using their work. I've had people ask for design input or general feedback, but nobody has ever asked to observe me using their work.

And that is a real shame. We should be doing this all the time with each other, and with our non-techincal friends. For as much as we post our work on Dribbble, Behance and our websites for pats on the back and constructve criticism, we should be asking people to use our work and give usability input just as much - if not more.

And my experience yesterday with Chad's work brings up another great point: we need to observe both peers and average users interacting with our work.

While users bring the benefit of raw user interaction, peers can bring the benefit of meaningful technical insights into what can be improved or what may only present obstacles in unique scenarios that the average user may not even uncover in testing.

Interactive Designers We Are

If we are truly to be excellent interactive designers, let's start taking user testing more seriously. Or maybe it's not that we don't take it seriously, but let's start to practice what we preach - more than we do.

What about you? Maybe you are user testing. How has it helped you?