Monday, March 09, 2009

It's All About The Whole Package...Designing for the User Experience

While the title of this site is Interface Matters (because I thought it had a good double meaning to it and it reflects an area where many Notes applications have issues), I'm really more inclined to think about the entire user experience (UX). Now certainly, the user interface is one important aspect of the user experience, but UX is much more than just what the screens look like and what the user sees. I'm an advocate of taking a holistic approach to the art and science of application design. I want every aspect of the process to be all about the user...making them happy and productive. Let's be honest here. If you are reading this blog, it's most likely because you are a developer in a corporate capacity in some shape or form. And that means that the users don't necessarily choose to use your software. They may request that it be written for them, but not because they are looking to have fun. In many cases, they are unwilling victims that must use it, no matter how bad it is. If that's the case, then I think we have an imperative to make the user experience the best it can possibly be.

I think I'm going to explore this in more detail in subsequent posts, but let's lay the foundation for what user experience is all about. In my definition, the UX is every interaction that a user has with a software application, from beginning to end, cradle to grave. Thus, the user experience encompasses:

- The project request

- The initial meetings with the customer (business/requirements gathering, proposal)

- The design phase (prototyping, usability testing)

- The actual software itself (the deliverable)

- The implementation phase

- Post-implementation (bug reporting, feedback, enhancement requests)

As you can see, using my definition, we're talking about the entire lifecycle of the project. And how you engage and interact with the user at those times when you are not even dealing with code is just as important as when they are sitting in front of the screen. In some cases, those events are even more important. The reason for this is simple. Our brains are great at associating events. If you start out a project on the wrong foot, even the best deliverable in the world might not be able to keep the user from thinking that the application is not that great. I've seen this happen in my own experience. I used to have a co-worker that was quite arrogant and rude. This person thought they had all the answers and subsequently alienated every customer we talked to. While the project this person engaged on was delivered ahead of schedule (and was quite good, I begrudgingly admit), the adoption of the application never took off. After this person left, I inquired as to why when the project was eventually resurrected. It turns out that the people in the department knew there were going to be other phases and more enhancements, but they didn't want to deal with this person! So here you had money spent, people's time invested and an inefficient business process that could have been much better, but people rejected the application because they didn't like working with the developer. That, my friends, is a breakdown in the user experience and it has absolutely nothing to do with bits or bytes.

I know that many traditional application developers claim that they don’t "do UI” almost as a badge of honor. As such, the idea of designing for the User Experience is probably even more foreign to them. However, I think it is vitally important to start to overcome these challenges. This will come about only through an organization making the necessary cultural change. Before app developers can actually start making progress in developing a good user experience for corporate applications, the process needs to support this objective. This means that designing for the UX needs to be injected into the design methodology. Whether they use traditional methods or an agile methodology, thinking about and designing for the user experience needs to be woven throughout the process. When your organization steps up to embrace this idea, it's amazing to see the transformation that takes place.

Have you followed a user-centric approach in your design process? Has it changed how you work? If so, I'd love to hear your story. I plan on sharing some more of my ideas in this space next time.


Keith Strickland said...

Great post! I'm experienceing something a little different. Yes I agree that developing for the user experience is good and needed that it is the whole experience, not just the part of writing code.

But another part here is developing in a box... I inherited an application that is getting a major overhaul, the requirements gathering were done before I was employed here. Collaboration with the customer has been to a minimum because mainly the customer doesn't want to deal with all that is required to get an application to market. Go figure... So, we write what we "think" the customer wants, only to find out at the end of the project that it's not what the customer wanted.

I think the customer has to be willing to collaborate with the developers, test on the cuff, make contributions other than criticizisms at the end of the project and participate more in the entire development process. Since I'm fairly new here, talking to the other developers, this is the norm and I can't figure out how that can be and the team still be successful.

So I agree as the developer you need to ensure all the stuff you mentioned happens, but it's also up to the customer to something more than provide a list of demands and then just wait to see what comes out of it. It sets everyone up to fail.

Chris Blatnick said... nailed it! That's exactly why it has to be a cultural transformation that not only moves through IT, but through the entire organization as a whole. Before you get to that level of maturity where everyone is on board with the vision, you'll be getting suboptimal results. You're doing the right things, so keep at it and keep selling the vision! :-)

Tony Palmer said...


What you are describing about customer and developer collaboration and also the cultural transformation of how you do software development sounds a lot like Agile and Scrum methodologies.

These are changing the way in which all stakeholders approach software development and its gaining traction and credibility.

I would suggest having a look at Agile(and Scrum) in a little more detail - it might help you formulate a process that you can follow and explain to the customers as a valid approach for them to get the system they want.

BTW, I've have a Agile post that has been continually in draft. I have been hesitant to publish it as I'm not sure that it would add any value to the Planet Lotus readers - maybe I'm wrong and I should just hit publish already.

I don't recall anyone talking about how they build solutions from a SDLC point of view. Clearly, as Chris points out, how you reach a solution is as important as the solution itself.

Chris Blatnick said...

@Tony...please do post your article. I think it would be very valuable to everyone! Cheers.

Tony Palmer said...


Done. finally...

Nate said...

Related to methodology, here's the process I try to approach every project from...

What is it that the user wants to DO while using the software? 99% of the time, the answer is not "use the software." The answer is: "close more sales" or "shorten cycle times" or "pay more attention to patients."

I find that when you think of the process this way, you understand that the goal of the software is to become transparent to the process. It should predict the contextual needs of the user. It should imply a flow-state where the software already knows what the next step the user might take is.

I've run into this a lot recently when talking to analysts who focus more on data flow than human flow.

Chris Blatnick said...

@Nathan...hey, you've stolen some of my next post! ;-)

Yep...that is dead on. Apple didn't set out to invent another mp3 player. They decided to focus on how to make it easy for people to buy and enjoy their music. The ipod was just the result of them trying to solve that problem. Great comment!!!

Tony Palmer said...

It should imply a flow-state where the software already knows what the next step the user might take is.

You mean - make it easy to use.


Maria Helm said...

Chris - 100% agree on making the experience positive all the way through. For a long time, I've had the split role of Domino Admin/dev AND HELPDESK Admin. So I'm going to focus on That Implementation Step. Good help screens within the application and a good "roll-out" process to get the users started are important. But I cannot stress enough the need for everyone answering the Helpdesk to be able to support your Domino application. They don't have to know it inside out, but they should have some idea of what it is and how to get further information to assist users. Communication between developers and helpdesk when rolling out a new application is key, and can make or break the user experience of the application.

A user calls the helpdesk with a "how do I" question, and gets a quick answer "click on the link that says...". The user thinks: "oh, that was easy and I just didn't see it". If they get responses along the line of "the what? I didn't know we had one of those... I don't know, I'll have to call the developer...", the user gets the impression that it is more complex and difficult, and they can't easily get help, and they dread using it in case there is a problem.

So it is key to communicate with the helpdesk, provide them with information to support the end users, and have a helpdesk staff that give a confident impression and useful, timely results. A lot of develoeprs wouldn't think of the helpdesk as being part of their application, but it is a big part of the UX.

Chris Blatnick said...

@Maria - Fantastic comment! Thanks for adding your thoughts. You're right...the help and support structure of an application is vitally important, as that is often the part of the user experience that is encountered most over the lifecycle of an application. It is definitely important to include your help desk into the flow so that they know how to assist your users with business process questions.