Skip to main content

Designing Software Blind

Chris Blatnick talks in his blog about how important interface design is in making software a success. Recently I became aware of a major development project that broke many of the guidelines that we use to design interfaces.

A major retailer started implementing a new POS software for their stores that was suppose to revolutionize their operation. You would think that they would work with store employees who will be using the POS systems to design the best solution, run test pilots to make sure that the software met the needs of the store employees, and have a detailed implementation and training plan. Answer NO NO NO. Software that are created by developers who live in a box and never get the customer (users) involved with most likely fail.

Here are a few example of why getting users involved in the interface design is so important:

Since the screen sizes of POS system usually are small you would think that they would be very concerned about font sizes, no. The designers decided to put as much information on one single screen as possible. The fonts were so small that even people with 20/20 vision can barely read the information. In the retail industry, some of the employees are older, retired and need bifocals or read glasses to read like myself. So in order for them to read it, they have to practically put their face against the front of the screen. Not a good image for their customers to see.

The designers decided to use colors like blue and green together, so that individuals who are color-blinded cannot distinguish between different parts of the screen. How much did that increase errors?

The developers decided to use words that were not commonly used in the United States so that the average store employee would not understand what they are talking about. I would not be surprised if the software was outsourced overseas.

The screen is populated with dozens of tabs so that users had a hard time finding things. At least it is not as bad on the one that Chris showed at Lotusphere 2008.

Instead of having trained technicans install the software, they had store employees who have minimum knowledge of computers install the software.

They forgot to train the help desk on the new system so when the store employees had problems and call they did not know how to response.

They did not train the employee how to use the new POS software. I guess they will learn by trial and error.

So as a result, the implement has been a huge drain on the stores and on their resources. Lesson learned hopefully, software has no value unless users can use it. It might be built using the latest and coolest technology, but if you do not have users participate in the development process it will be just a book end and at the very best a bad one. Good planning and training would also help.

Comments

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo