UX Dreams

I awake from the dream excited. Finally, that dazzling opening paragraph, the catchy series of well-crafted phrases that will entice readers to follow my blog for evermore has arrived via a dream. It is perfect. I quickly open the blog writer on my laptop positioned strategically next to the bed, ready for this moment of insight because I knew it would come, it had to come. I begin to type quickly for I must record my inspiration before it is lost.

Suddenly, the phone rings loudly, startles me. I frantically search for the Save button on the blog writer so that I can answer the phone and not lose my prize blog creation. There's the button, Save as Draft, presented in dull gray letters. I click on it, nothing happens, nothing happens, its disabled..., oh no, quick, why isn't it enabled? Panic. I click madly about the screen, the phone continues to ring and the dog begins to bark. Why can't I save it? And then come the famous words of every frustrated user, "why doesn't it work"?

Flash to blank white screen, I've lost my prize winning paragraph, the best opening lines of all time. Nooooooo! I can't remember it at all. The phone no longer rings. The dog watches sadly.

What had gone wrong? Everything was set just right. I had written many blogs before, always starting by writing a title, even if I would change the title later. Then I would begin to write freely, not stopping to rewrite. Write the title, write the story, write the title, write the story, a hundred times over I had performed this ritual. The TITLE! In my haste and excitement to record the first awesome phrases of the opening to my prize-winning literary masterpiece, I had not entered a title. AND THAT IS WHY THE SAVE BUTTON was disabled.  You couldn't save anything you had written unless you entered a title first.

Bad UX! SHAME!
I just lived this bad UX, although not quite as dramatically as related. But I am just as angry and frustrated. I had written a few sentences and tried to save what I had written. Noticing that the Save as Draft button was disabled, I searched for a way to save, and got interrupted by a colleague asking a question. Not sure what I did then, but I lost all that I had written because I had not entered a title for the blog when I started. Typing only a single letter in the title field enabled the Save as Draft button. Even though it is likely that a sizable percentage of users start to write the text of a blog without entering a title, the text in the body section could not be saved without a title.  And this may not be a major UX problem, but small problems like this add up and reflect an approach to system design that will ultimately lead to larger failures.

How many users have become frustrated due to this design flaw? Wasn't anyone thinking about the user when this blogging writer was designed?

Well, if I was the UX designer I would have thought about the user. The main focus of my job is to help hapless users like myself avoid frustrations like the one I just outlined.  Blogging should be a positive experience and a poorly-designed blogging tool can quickly flip this task into a very bad UX. I work to help software designers and developers become conscious of the needs of users when building a system, at every step of the way, from when the software system is nothing more than a concept to when the software is completed. I teach User-Centered Design (UCD) to allow developers and designers to engineer a quality UX into their software system.

Can you acquire UX Design Skills?
Now, can you as a designer or developers engineer a great UX based only on training? Perhaps not totally at first, but training is the first important step and even though you might not engineer the UX perfectly after a training course, I do know that you will be now conscious of the user as you build the system and possess a handy set of best practices to meet a host of design challenges. You will be aware of tried and true UX patterns and can quickly assess the quality of your system's UX throughout the development cycle, constantly identifying improvement areas based on customer feedback. With continued practice and knowledge of UX design principles, I know you will be able to engineer a good UX for their systems.

So, what does UX training consist of?  Well, there are many topics and rather than repeat what's already available on our UX Services page, http://www.infragistics.com/services/ux/course-syllabi/compendium.aspx#CompendiumCourse, I'd like to just relate a short story about an ill-fated project that convinced me of the importance of engineering a quality UX into software systems and the value of designing a system that focuses on the user. I, and everyone else who worked on this project (an army of system engineers, developers, testers, and technical writers) learned the hard way that software can only be successful if the real users of the system are involved early and often, at every stage of the development cycle.

Learned my Lessons Well
One of my first jobs after graduate school was as a systems engineer in the telecom industry, working on a system that allowed engineers to plan a telecommunications network from scratch or develop enhancements to an existing network. We thought this new system would be especially useful for third world counties that found their populations expanding at an exponential pace, and needed to develop a communications network to support the burgeoning population.  Our project was headed by an engineer who had worked for a variety of the telecom operating companies and there was no doubt she was an expert in the field. Little did I know it at the time, but the leader's expertise at network planning would lead to the project's downfall as ultimately the system was designed based on the requirements of this project leader, not the requirements of the users. 

Yes, we met with "user representatives" every quarter, who reviewed our work and plans for the next quarter. We showed the user representatives prototypes of new functionality and conducted elaborate walk-throughs of requirements. But the user representatives were not the real users. We worked on this project for a year and 15 million dollars was spent by the customer on development costs.

When the project was completed, only 1 person could figure out how to use the system, our expert project leader. She had designed the system for herself! She thought the system was great. Unfortunately, the system was never used by another living soul, a sad testament to the project's reliance on an expert with no input at all from the real target users of the system.

So, I learned a valuable lesson, albeit at a high cost.  Understanding the user and constant, frequent involvement of the user in system development became a fundamental principle in all of my future work. This principle is also a foundation of our Engineering the UX  training course. I show how to involve the user without incurring high costs and why user research is instrumental in system design and can actually save development costs.  After the course,  anyone can begin  to practice  this principle, resulting in a software system that is usable, appealing, useful, and functional.

If I had heard this story at the start of my career and knew the importance of user research and user involvement, I may have been able to prevent the waste of a lot of time and money. But life is for learning.

Of course, there are a lot of other concepts and best practices that contribute to the quality of the UX for a given software system.  I'll cover these in future blogs.