Posted by: David Scott
1 year plan
A business system recently came to my attention that had a number of ambiguous paths and choices – it was difficult to know what to click in order to proceed. The system is a core, mission-critical, business system at a “big box” retailer.
As to the ambiguities, consider this: When ordering a major product for a customer (in terms of size and cost), a model number is entered – after calling up an existing customer record or creating a new one. Once the product is added as a line to the order, the user is confronted with two buttons: “Order Product” at center-bottom of screen, and “Continue” at bottom-right. Hmmm…
Now, after undergoing a modicum of training, and with some acclimation to the system, a user knows to click “Continue” in order to complete the order; and knows to click “Order Product” to add another line item (another specific product) to the order. However, for new employees, the system can be cumbersome and arcane. Here, it would be an easy enough job for any business analyst to view the system through the user’s eyes: The “Order Product” button can just as easily be marked as “Add Another Item” or “Add Another Product.” Once all products are added, it is quite intuitive to click the “Continue” button to move the order along to completion. Much easier on the users, and a better match of easy-to-understand screens in match to training.
Another area of the system has a template for fill-in of very complex products. One example: Carpeting. Here, specifications (and fields) include Type (loop, pattern, texture, twist), Color, Brand, Fiber, and other qualifiers. However, a system anomaly exists here. the more comprehensively you fill the template, the more likely you are to receive a system error! In fact, it’s best to fill one field, and to proceed through a more cumbersome (and under usual circumstances, more inefficient) path to ultimate resolution of ordering carpet.
I see breakages and ambiguities like this all the time in the course of my consultations. I hear complaints from business people quite frequently. Here, IT needs to build applications and associated designs while imagining the business-class user’s negotiation of the system – to a business end. It’s really not that difficult.
To business folks: When participating as a stakeholder, and partnering with an IT counterpart, listen to what you’re saying through their ears, and be aware of what may be ambiguous to them. Smash ambiguity – be specific in how systems are to work, how systems are to look.
To IT folks: Design and exercise beta versions from business’ perspective, and watch for ambiguous and broken paths and procedures.
It’s easy to do with a little practice – and well worth it.
Now Playing: John Lee Hooker, Endless Boogie, original (commercial) open-reel tape, 3 ¾ IPS.