How to Avoid the UX Black Hole of Creation Without Validation

Imagine a project, near the end of Product Definition (or in the case of agile, closeout). All strategists, product managers, designers and clients have had multiple brainstorming sessions to come up with a unified vision of the best solution that can be delivered within scope. Every user story has been clearly defined. Each UI element has been rendered to fulfill its pixel-specific destiny.

Everyone has done their part to create something wonderful and can’t wait to see development bring it to fruition.

This should be a time of celebration and collective appreciation for a job well done. Ideally, this would always be true. However, this period can potentially become a digital service company’s worst nightmare.

Knowing that the window of opportunity for changes is closing, clients can start throwing all their last minute feedback at the team, stressing that each item is of top priority. That confirmation button MUST be full-screen width in metallic green because it will double conversion rates! Let’s add the ability to filter search results by “mood” to connect with users on an emotional level! We need to increase all imagery by 50% because nobody will be able to see our products at the current size!

The client sees the creation of the product as part of the service being provided to them. They’re going to own it after completion, so shouldn’t it be designed primarily to achieve all of their business goals? Anyone involved on the product side wants to make sure the client is happy with the end result, but they will probably feel apprehensive about implementing any of this last minute feedback for a few key reasons:

The additional scope. Changing the filter criteria may be simple enough in a mockup, but how much time will it take for the developer to build support for it on the backend? How will product managers prioritize this feature against others that have been deemed critically important? How many edge cases and devices will QA have to test for before giving it approval (sparkle pass)?
The implications it may have on other areas of the product. If product imagery is enlarged, how will that restructure the rest of the UI on the screen? Will important elements still be in view upon landing? If a significant layout change is required, does this screen still seem cohesive with the others? If not, how many other areas need to be modified to retain consistency?
The validity of any of these changes. How do we know that any of these last-minute changes will create the desired results? Is there any data to prove that implementing this feedback is worth the additional time and risk added to the project timeline? Stakeholders on both the product and client side are too heavily invested to make any assumptions on user behavior. Stakeholders may be willing to spend months iterating on a product they feel ownership for. But if a change in requirements adds an additional field for login, a user may decide it’s just not worth their time.

So with different stakeholders advocating either side of the argument, and a deadline rapidly approaching, how do you prevent a battle royale of wills that could potentially derail the completion of the product?

For many of the most successful tech companies, design is no longer subjective.

Rather than wasting valuable time engaging in lengthy speculation, it’s in everyone’s best interest to put any proposed changes to the test. If a team finds themselves with multiple options for a homescreen layout or a variety of icons that could potentially represent a tagging function, the decision should come down to the reactions of test users. Most designers and product managers have heard and/or read this countless times before, but unfortunately don’t always have the time to user test and prototype each iteration in an effort to find the perfect solution.

Not all clients understand the value of validating UI/UX because when it comes to their industry/product, they’re the experts, right? Product teams who design without validation try to justify decisions with their experience, which has surely given them an intuitive understanding of user needs, no? GO BACK. Stakeholders are so far removed from the user – who is unlikely to have much knowledge about the product or industry – that it is very difficult for them to empathize with the user’s needs.

This is why every idea should be tested by outsiders who’ve never seen the product before. Untested designs can become a tool used to impose an experience driven by business goals rather than user needs, which is a sure-fire recipe for failure. Companies that understand this often create incredibly intuitive interfaces, and are primed to leave their competition behind in the great mausoleum of companies/products that couldn’t (see Microsoft Zune).

This past April, Spotify released their first UI overhaul in eight years. The largely well-received redesign was guided by user testing. This testing led them to create a much darker interface that was free of clutter and showcased album art and other content. Iteration and testing also prompted the removal of the familiar “Star” icon, in favor of a plus icon that was found to better represent the function of adding a track to a collection. Earlier this year, Facebook announced a mobile A/B testing framework it developed to deploy and analyze up to 15 micro UI variations at a time to its 751 million mobile users. To some, this may seem like a lot of effort to determine where the optimal placement of a “like” icon is, but those who appreciate the importance of fine tuning a product to best serve users will often benefit greatly.

Shut up with the idealistic UX talk already! How can I fit validation into my workflow?

While not all of us work at multi-billion dollar companies that can fund entire research labs to collect and analyze user feedback, there are a few tips, tools and services that are available to just about anyone who wants to improve the usability of their interfaces.

Clickable Mocks

This is by far the easiest way to create hi-fidelity prototypes. A low-barrier entry point into the world of prototyping is creating a clickable pdf. If you’d like to step up your game by adding transitions or animations, Keynote is a wonderful tool for creating prototypes that can help represent different flows in an interface. Many designers also advocate paper prototypes using sketches, but I find that these do not translate the intended experience very well and provide too much opportunity for users to accept sub-optimal designs in the rough draft. For testing, it’s best to represent the final interface as closely as possible (usually at mockup level) so that users may be more critical. That’s not to say there is nothing to be learned by testing wireframes, but rougher sketches are better used internally earlier on to rapidly iterate on ideas.

Online Prototyping Tools

There are thankfully quite a few online tools available that are either inexpensive or even free.

InVision– Great for creating interactive mockups. Simply add hotspots to your mocks. Most basic gesture interactions are supported, and you can choose from a few common transitions.

Flinto – This is another great web service that allows you to overlay hotspots on your mocks. It features a very easy-to-use interface for mapping your prototypes, as well as set of animations for screen transitions.

Proto.io – Proto.io is a step above InVision as far as interaction support. It also provides a UI library so you can create interactive wireframes from scratch online. This process is more time consuming, but worth it if you need a bit more complexity with your interactions.

Usertesting.com

If you don’t have the time, space, equipment or budget to facilitate an in-house user-testing lab, fret not. There is an online service that will outsource it for you! Usertesting.com is an online validation platform that gives designers and developers access to a round-the-clock community of testers that get paid for their feedback. This is a great service to get unbiased feedback on a prototype or build that needs some direction or refinement. You can specify high-level tester criteria such as age and gender, a list of tasks you would like them to perform and questions you would like answered. Feedback videos are usually returned within a 24-hour period, and then it’s up to your team to analyze the videos and identify common pain points that need to be iterated on. Well-written, open-ended questions will often lead to some insight about what it is the users would like to see.

When should you validate?

“Test early and often” is a saying that gets used quite a bit in the UX community. But in a digital services company, this is far easier said than done.

Ideally every slight modification should be tested to be able to pinpoint contributors and detractors from the overall experience. However if you’re dealing with a very tight timeline, there are a few key points in a project timeline to test.

During strategy, you should test competitor products to learn where competitors have made mistakes with their products, so that you can steer clear of those pitfalls. Understanding potential mistakes this early in the product lifecycle sets the stage for you to finish on top. Additionally, during product definition, you should use quick and dirty clickable wires to help determine which user flows and navigation patterns work best.

By the time mockups have been made, it’s time to test between the slight variations of UI elements. Again, this is the golden window of opportunity to get reactions from testers that will be more accurate to the final product. If the project you’re working on is agile or if you have more time to iterate and refine, you can conduct user testing on builds. While there is nothing more realistic than an actual build, the main drawback to testing at this point is that implementing any feedback requires a development effort. Hopefully you’ve conducted testing at all the previous steps, and any feedback at this point should be minimal.

Understandably, fitting validation into a project plan that doesn’t accommodate for it is not always an easy task. However, if you become proficient at using these rapid prototyping methods, you’ll soon see the advantages of being able to back up design decisions with data – instead of just aesthetic preference or past experiences that may or may not be relevant. Even better, if you can document the testing results and show how they led to a better-informed design, perhaps you can convince your next client or the rest of your team of the value in validation.

Filed under: Product Engineering | Topics: A/B Testing, Design, UI, UX