UX Insight: Measure Twice, Cut Once

I recently attended a large UX conference – lauded as one of the largest in Canada. It was an enjoyable couple of days with some well-known and soon-to-be well known speakers. The audience was a good mix of client side and consultant side UX junkies. If we could only get a few more product, marketing and executive types to show up! But I digress…

Following the event came the normal post-event survey. As I clicked through the survey, and reflected on the event, something felt wrong. I struggled with the feeling a bit, as the event was well structured, the food was good, the venue was comfortable and the audience was receptive and enthusiastic. So what was it? I looked back at the agenda, the speakers and the topics. It took some time staring dazed at my monitor to put it in words. Despite all the interesting topics and entertaining speakers, amusing anecdotes and lessons learned, there was a conspicuous lack of actual research presented over the couple of days of talks. There was plenty of design work, both physical design and digital, there was plenty of talk of testing and usability principles in general, but there was little to no talk of user or customer research and how it was leveraged to build better products. Should this bother me?

As a UX practitioner with an absolute bent for research it does! The UX I learned, back then called user centered design, didn’t just include research, it was mounted firmly as fundamental to making evidence based design decisions. Research was where things started, where we found inspiration, how we focused subsequent work, and how we ultimately designed products and services.

Or maybe I’ve got this all wrong and I am witnessing my ultimate demise to a more design centric approach where research is less relevant? One where disposable design is the new world order! Does anyone still follow the idiom of measuring twice and cutting once?

Many in the incubator community will argue you only need a minimum viable product. I obviously take issue. Building something doesn’t make you a business!   Nor does building, launching and failing – whether it be done “fast” or a slow lingering death. (I’ll comment on the “fail fast” mentality in a later blog)

But startups are not alone, enterprises are equally culpable. I’ve seen companies engaged in product/service design which pushes engagement with user to later and later in the build process – in many cases where usability testing post development if the first time a user actually gets to experience the thing! Where are the user profiles? Where are the use cases? Has the value proposition for the application – it reason for being – ever been validated with prospective users?

A long way back, in 2005, the IEEE Consortium published an article called “Why Software Fails.” While there are many comparable articles, including a more recent report by CBInsights, I like this IEEE article simply because of the source. IEEE is the largest and arguably most reputable organization for the advancement of technology innovation. I find the article as relevant now as it was the day it was published.

12 common factors why software projects fail

• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project’s status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project’s complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

How many of these you have experienced? How did you overcome them, or did you overcome? While the article was not written specifically to promote UX, consider how many of the issues identified could have been resolved or at least better managed with user and customer research? I count several, whether it be better understanding customers and users, clearly defining user valued product requirements and functionality, or managing stakeholder needs.

At Akendi, we believe in a research first approach to product, application and services design. Investing in understanding your users and customers will pay a dividend in both your current and future products. We thrive on helping clients better understand their customers and users, and enabling them to make informed design decisions based on users not opinions.

I’m remaining bullish on the value of research in product design and looking forward to the next event and perhaps hearing how research helped define a product direction because a savvy product manager invested in measuring twice (or at least once).