Because I'm a big fan of code reuse, I'm going to shamelessly copy and paste an essay I wrote when I first moderated a forum for LotusUserGroup. It's about why I think UI design in Lotus Notes is necessary and I believe it's an important talking point. I'm finding that as organizations are getting serious about deploying Notes 8, more developers than ever are interested in the concepts of usability and interface design. I've noticed an uptick in the amount of mail I'm getting from people who have just found my site, so this also serves as a good introduction to what this place is all about. Cheers!
If there is one question I have been asked most often by Notes developers, it is "Why do you spend so much time designing the interface for your applications?". The one line answer to this is "Because to the user...your interface IS the application". Because of the very nature of our jobs as developers, we tend to get wrapped up in the technical details. We love to come up with innovative new tricks, revel in writing a particularly efficient block of code and geek out when it comes to the latest and greatest technology. All of this, however, pretty much means squat to the guy or gal sitting in front of the screen trying to actually do something with your masterpiece. Users don´t really care about what´s behind the curtain. Rather, they are interested in one thing when they are using your application..."How can I get my job done quickly, efficiently and easily?!"
The goal of any good interface is that it should be unobtrusive. You´ll often hear designers talk about "getting the interface out of the way". This is your ideal to strive for. When your user can enter a flow state and accomplish the task he or she set out to do, WITHOUT having to think about how to USE the application, then your job as a designer has been highly successful. To put it another way, the developer is given the task to make the product transparent to the user. The goal isn´t to get people to like your application...it is to make it so that they don´t really notice the application at all. In the end, a clean, usable interface means happy users.
"OK...enough with the touchy, feely stuff", you say. "My users are business professionals...they don´t care what it looks like as long as it gets the job done!" Boy, have I heard this more than a few times. In a few special cases this might be true, but believe me, for the most part your users DO care. There are many benefits to designing a good interface. Although somewhat hard to put an ROI on, good UI design often saves money, since the users tend to request fewer changes. User acceptance of the applications is almost always higher than when the interface is ignored and users report greater satisfaction with the end result. Remember that it is human nature to want to use things that are functional and attractive. This fact is what makes the iPod such a spectacular hit. It´s just one of many MP3 players, so what makes it so great? The combination of aesthetics and usability (it´s so easy even grandma can use it) help it stand out in the crowd. To bring it closer to home, if you´ve ever had a user choose an inferior product over another more robust one simply because "it looks better", then you´ve experienced why interface matters. Perception plays a huge part in satisfaction.
So...if you are convinced that designing a good, usable interface is important, how do you go about accomplishing that task? There are many ways to start learning about usability. There are several great books on the subject and many websites that are great resources. I´ll post a listing of my favorites in a separate thread. My main point of advice for Notes developers would be to practice what I call an "interface first" design methodology. Basically, I use a pretty typical RAD approach to Notes development, but I have factored in UI design as a major component of that. The initial efforts that take place with an interface first design approach focus on determining what the user will see and do in the application. I am concerned at the very beginning with what the UI will actually look like because how the user will work with the interface elements usually has a direct impact on the code you have to write. As an example, I had a complex application in which multiple "child" documents had to be created for a given "parent" document. I could have simply used the standard Document and Response type forms with all the functionality that Notes provides for me, but in doing the initial UI design work, we came up with a much more elegant and simplified solution...at least simplified from the user´s perspective. In the end, the design used an embedded view/embedded editor model, which was harder to code but made the UI extremely easy for the end users, who were all new to Notes. Had we not focused on the interface in the beginning design stage, the application would not have been nearly as successful.
Employing an interface first approach takes a little getting used to in the beginning, but pays huge dividends in the end. How many times have you gathered specifications from a user, built the functionality and delivered it, only to have the user tell you that it´s not really what they wanted? Be honest...it´s probably more times than you´d like to admit. Have you ever thought up a cool design feature that you were sure they would LOVE, only to find out that they don´t use it, or worse, don´t LIKE it? I´m sure this has happened to the best of us. By using an interface first design method, you can avoid many of these problems. It´s not fool-proof, but it gets you a lot closer to the desired end result a lot faster than traditional methods.
So what does using an interface first approach actually mean? By using this method, you actually build the interface for your application BEFORE you write a lick of code. This can take many different forms, but essentially involves drawing out what all of the screens will look like as a first step. I use low-fidelity prototyping for all of my projects. This is just a fancy name for sketching out the interface on paper...using pencil, pen, crayons...whatever you have handy. Some people prefer to use HTML or a graphics program to design screen layouts. This is fine too, but takes more work. After I have gathered enough requirements so that I feel I have a good grasp of what the user is looking for, I grab a stack of fresh blank paper and jump into the design process. I draw out the fields, sections, graphics...everything that I expect will be a part of the application interface. This doesn´t have to look good. In fact, I encourage you to not spend a lot of time drawing these screens. They´re very likely to change and you might have to do this several times.
After your paper prototype is complete, schedule another meeting with your customer. Ask them to look at the screens and give you feedback. This can be formal (conducting a full-fledged usability testing session) or very informal...whatever you are more comfortable with. Take time to explore different scenarios. If your database is for entering customer complaints, ask the user to take the role of a customer service representative and have them walk through what they would do while looking at your paper prototype. Ask them to talk out loud as they do this, explaining each action. You´ll be amazed at the insight this gives you into the mind of the user. When you find something that doesn´t belong on the form, cross it out with a marker. Need to add some new fields? Just draw them in with a new color. See why it´s good not to spend a lot of time tweaking your prototype? You´ll end up changing them a lot.
When you come back from your initial paper prototype session you may be surprised at how much has changed. If you nailed it the first time, good for you! More often than not, however, you´ve got some changes to make. Quite literally, you should go back to the drawing board and build the next iteration. For a typical application, I will build about two or three paper prototypes. This may seem like a lot of work, but in reality doesn´t take too long.
So...you´ve built your paper prototypes, gone through some iterations with your users and have a pretty good feel for what the interface will look like and how the application will function. Now what? Now, go about your business...doing what you do best. Start slinging your code, basing it not only on the business requirements, but also on the interface requirements that you´ve collaboratively developed along with the user. By designing the interface first, you are already halfway to user acceptance and in my experience, have also made the users more passionate about the application. They feel invested in it much more than in traditional programming methods, where you may have only met with them once or twice. When you finally deliver that application, I guarantee it will be almost exactly what the customer asked for...and that, my friends, is exactly why we do this!