Here's a bit of heresy that will drive your business managers wild: When preparing app requirements, forget business requirements (it needs to provide a 5 percent increase in sales), functional requirements (it needs to ring up a sale) and technical requirements (it needs to be built on Windows). Instead, push to the top of the list interface design requirements (it needs to accomplish the critical tasks in the least number of clicks possible). Believe it or not, that's where the money will come from.
Think about it, RIM had the BlackBerry on the market for years delivering E-Mail to business users around the world, but it wasn't until Apple launched the iPhone and that mobile access to E-Mail became ubiquitous. And when it comes to design and usability questions, the best resources for the IT team to ask for help (outside of an actual Interface Designer) are the ones least likely to get the call: Marketing, Creative and Store Associates.
The impact of poor design and usability is significant. I have been involved in launching an application that showed a return of 2 percent in store profitability that never got traction because it was hard to use. Now, "hard to use" is a relative term. But I would suggest in most retail applications you use the same design standards as you do for your customers. Don't expect your associates to put up with a poor design just because you pay them or because "the results are worth it." If a retailer is willing to pass up on $20,000 per year in savings because the company thinks an application is too difficult to use, you start to get an idea of how important design really is.
I previously wrote that I think it would be an excellent idea to let the sales clerks design a POS interface. This could also apply to inventory, labor, ordering and clientelling applications. By better understanding how the system is being used, the application can (and should) be modified to deliver the maximum benefit/results.
The Marketing and Creative teams deal with "look and feel" all day long. Why not leverage that expertise to help design your application? If you were to treat your associates (the ones using the application) the same way you treat your end users (the users of your E-Commerce application), you would see a dramatic improvement in usability and overall usage of the application.
Part of the reason these teams do not get involved in retail technology projects is because they don't directly support their goals of growing store sales. They are charged with finding more customers and getting them to spend more when they walk in the door. Asking them to help out in store operations, although it may indirectly impact their goals, isn't going to make the CMO happy if those departments miss this quarter's same-store sales target.
Another problem is that many IT professionals are burdened with a sense of pride when it comes to asking for help. There is this "tell me what you want done and I will go do it" mentality. Asking for creative input (or help, for that matter) on an application doesn't jive with a lot of IT personalities.And although the IT team could hire an interface design expert, it is a difficult to justify to senior management. "We need to hire someone to help us understand how the POS screens should look" is likely met with a scowl and a "Really?" when put under cost pressure from the CFO. "Just have the VP of Operations tell you how she wants it to work."
Instead, think about it as a user yourself. Have you ever seen one of those grey "submit" buttons on a Web site? You know, the ones that are the default within HTML? Although these buttons functionally work, they just look bad. It takes 15 minutes to create a graphic version of that button that matches the look and feel of the site and can easily take the look and feel of a site up 10 notches.
Most applications are being introduced as a replacement for some other process that either exists in another system or is being done manually today. Without a focus on making the new application extremely easy to use, you may see adoption/usage of that new application never make it off the ground. It also helps with change management when the new application looks so good that the users are excited to use it.
There are plenty of examples of retail technology solutions that provide a ton of business value but fall far short of the "looking good" category. A large part of that comes from the fact that applications are started with the goal of providing a certain set of functions, but are then rapidly expanded to include other functions as the solution is implemented in more locations.
What starts as an easy-to-use application, takes a nosedive into the complex and difficult. I can imagine there was once a day when Microsoft Project was an easy-to-use application (not so much anymore).
I can't tell you how many times in my career I have heard a store operator tell me, "I really wish the application did this," only for someone on the technical sides say, "It does. You just have to go here, here, here, here, here and then here to see that info."
The problems can be significant. Maybe a process takes too many steps to complete. Maybe the information is hard to find, or maybe there is too much information presented. Maybe the users aren't interacting with the application in the same way it was designed to be used (this happens a lot). Or maybe it just looks like something from a community credit union circa-1990.
Many retailers will implement tools or services that enable them to track the click-paths of their E-Commerce site so they can make adjustments to how users interact with the site. But rarely will they look at similar metrics for their associate-facing applications.
If you take the same amount of care on the look and feel of an application as you do for a TV spot or a print ad (or even the look and feel of your Web site), you will see a much better adoption of the program.
What do you think? If you disagree (or even, heaven forbid, agree), please comment below or send me a private message. Or check out the Twitter discussion on @todd_michaud.