PinPoint Performance Solutions Blog (Legacy Content)

The lack of posts on this blog have been due to some recent projects taking up most of my time. Because of this, my blogging has suffered. Perhaps I need to heed the advice of this blog post, set up my own blogging regimen and work it into my schedule.

Until I get a regimen developed, my blogging will be more spontaneous. When an opportunity where people can learn about good usability and design techniques presents itself and I can quickly write about it, I should take it!

A current project where I deliver training on a content management application to groups of new end-users presented such and opportunity.

I didn't design the interface of the application - I just train on it. It seems when the application was designed, the developers didn't fully understand the end-user and how they understand the content they manage. The application I teach allows end-users to set up metadata for their document and then upload their document (file or files) to the system. To do this, the button that activates this function is labeled "Add Content".

Sounds easy enough.

If an end-user wishes to upload a new version of the document, the button to activate this feature is "Add Rendition". This has been a source of confusion for many end-users. During the training sessions I deliver, I usually find myself spending more time explaining what the developers meant by the word "rendition" rather than demonstrating the actual functionality.

Note: the functionality of adding content and adding a new version of previously uploaded content is the same.

The reason for the confusion is the naming conventions end-users reference (in their minds) when they wish to work with content. Adding content is easy to understand. They upload a file or files to the system if it has not been added before. Adding a rendition is not so easy to understand. I'm not sure why this is confusion and I need to investigate it further. Rendition must have a completely different meaning to the end-users than the word version. Given the opportunity I will mention to the developers that the labeling of these functions is in need of review. We might have a simple fix on our hands, such as renaming or relabeling a button, that will reduce a great number of support calls and e-mails.

Through my training I have been able to uncover a usability stumbling block and it all stems from improper labeling and lack of understanding the end-users. The lesson learned is that developers need to understand how their end-users think, especially what they call things. Say what you mean, be literal and match what the end-users think.

Rik Catlow of Rikcat Industries posted to his blog 5 Ways to Make a User Interface Intuitive.

I completely agree with Rik and wish more developers of software, web applications and websites embrace simplicity in the design of user interfaces. I'm sure if you take stock of the applications you use on a daily basis or applications you have used in the past, you'll recall how most of them are confusing leaving you to fumble around just to accomplish a simple task.

Much of this is common sense and when simplicity is chosen over complexity it is not about compromise. It is about being targeted and precise in your intentions and purpose behind your application.

Here are Rik's suggestions on making a user interface intuitive along with some of my own commentary:

1. Eliminate Redundancy: most applications have different ways to accomplish the same task. Reduce the redundancy and simplify the tasks to a select few.
2. Nomenclature & Contextualization: I sum this up as a controlled vocabulary and proper labeling. Don't be cute with titles linking to other pages or sections in your website or web application. If you have a section with a list of links to other websites or links to e-books and presentations, don't call it "The Pit" or "Library". Call it what it is. Call it "Links". This is about knowing your audience and you must speak their language in your application's interface.
3. Consistency: the overall look and navigation of your application must be the same throughout, no matter where a user is in the application.
4. Protect Screen Real Estate: if you work with many people on a project, there is a tendency for others to jockey for position to take up space on the screen for their pet projects or areas of interest. Make it clear that it is about the end-users and what is relevant to them.
5. Testing: make sure you test your application or website with actual end-users. Run a series of tests from paper-based, wire frame prototypes to functioning prototypes. Testing need not be complex, but it must be objective.

Along with these 5 suggestions, here are a few books and a link to a useful web article that will help you create a intuitive user interface:

Books

• Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville
• Don't Make Me Think by Steven Krug

Web Articles

• Why You Only Need to Test With 5 Users by Jakob Nielsen

In a recent post I talked about integrating Web 2.0 in your organization. One of the statements I made was that when you implement Web 2.0 technologies you should expect to encounter bugs, poor interfaces or poor usability. In other words, beta releases will most likely remain in beta or a work in progress (WIP). It's simply par for he course.

BNET recently published Perfectionists Despair: Digital World “Always in Beta” to their website. It's a nice, quick little article that hits the following points:

• Speed will trump perfection. Time to market is crucial in the digital world and a "not ready for primetime" software or web application won't necessarily be held against you (author's note: BlogRush is a prime example).
• The pace of business is so fast, there's really no way you can release a flawless product if you expect to make any kind of significant impact.
• Consumers (end-users) aren't really consumers any longer. They are now your beta testers or your usability test subjects. Learn from them and engage them in a meaningful conversation. You'll learn more about your product and how it relates to them than you'll ever know.

I for one am glad that the acceptance of betas are in the digital realm. Imagine if betas were acceptable in the cars we drove or the household appliances we used. Life would be more exciting, but much more dangerous than it already is (depending on your lifestyle).

While taking my blog break last month, I had a little time to do some research and find two very interesting articles on how to use Adobe Acrobat and Microsoft PowerPoint in creating user interface prototypes that are interactive. This is goes way beyond paper prototypes and basic screen captures and gives people a sense of how a website or web application will behave when a user interacts with it.

Here are the articles:

• Interactive Prototypes with PowerPoint
• PDF Prototypes: Mistakenly Disregarded and Underutilized

I'm always fascinated when we find new uses for applications beyond what we commonly utilize them for. The greatest advantage to using these two applications for interactive user interface prototypes is that you can be confident that almost everybody you work with, who needs to see these prototypes, will have these applications or at the very least reader versions on their systems.

If you have any other suggestions for uncommon uses of software that we may take for granted, I welcome them.

A fundamental principle in usability design and interaction design is something called an affordance. An affordance is a term made popular by Don Norman in his book The Design of Everyday Things. Essentially, an affordance is the way an object looks, how it is designed or how it is presented to suggest a certain action or usage.

For instance, the angle or shape of a chair suggests that you use it to sit on. The rounded, softer and curved portion of a knife or hand tool suggests this is where you handle the instrument. Just take a look around and you’ll be surprised all of the affordances you see in the design of everyday items you use.

It’s even present in our technology.

Most software and web applications have affordances built into their interface to suggest certain actions or usage. Your typical web browser most likely has left and right arrow buttons near the top to suggest your web surfing experience is much like reading a book. If you want to turn back to the previous page you were viewing, you would click the left arrow button or “turn the page to the left”.

Good user interfaces will have these intuitive features built in. Still, there is a need for support systems to be in place in order to guide new users who may not hold the same paradigms or mental models of the persona you developed your application around. The support provided, usually through carefully designed tutorials or quick start guides, will give the user a sense of what is this (the application), what do I do with it and how will it be relevant to me.

That’s good support for any application.

If you keep up with the latest news and trends in technology, it's hard to avoid anything being reported on the Apple iPhone. Since its release it has captured the hearts and minds of many hard-core Apple users and mobile technophiles.

Recently some news has sprouted about usability and quality issues associated with the Apple iPhone. The device is touted as being very user-friendly and intuitive, but some performance issues leave much to be desired. You can see what one group reported in their own usability study.

A recent article on the web reported how use of the Apple iPhone on the Duke University campus has caused issues with their wireless network. Subsequently, users see poor performance in their web browsing with the device.

This leads me to some important questions:

1. Did Apple test the iPhone in the field to make sure web browsing on the device would meet user expectations?
2. Did they anticipate what the performance would be when more phones are on a given network?
3. If Apple is fully aware of the issue, are they using the device as a tipping point to force the infrastructure it resides on to adapt to them versus them adapting the device to the infrastructure?

It's hard for me to believe that Apple didn't anticipate or test for this condition. However, stranger things have happened. Besides, Apple is in the process of gaining considerable market share in the mobile computing area. Once they do they can quite possibly call the shots, hence the reason for asking question number 3.

The lesson we can learn from this is usability testing and field testing is crucial to the success of any piece of consumer software, website, web application or hardware device. Testing the product under actual conditions an end-user would use it can yield a wealth of information that may not have been considered in the design phases. Once you learn this information you can apply what you learn and make the appropriate fixes to the final release of the product.

What's a technophile to do with a device that's not fully meeting their expectations? Word is a new version of the iPhone is already in the works.

PinPoint Performance Solutions has published a white paper on Search Engine Optimization (SEO) and Usability (PDF, 75K).

Abstract
The design and functionality of a website does not have to suffer just to receive a high ranking on a search engine results page. Search engine optimization, the practice of optimizing the code and content of a website to make it easy for search engines to index and for end-users to find and usability, the practice of making something easy to understand and learn are actually two sides of the same coin. Both practices are a lot more similar than you may think and lend to enhancing the user experience for websites and web-based applications.

Here's a very interesting post recently made on UXmatters about Audio and the User Experience. Appealing to as many of the senses as possible is crucial in creating a good user experience and a quality user interface. Still, it is important to consider the context or environment in which people will be using your application be it software, website or web application. One person commented that most folks keep the volume low or turned off completely in office settings in order to avoid embarrassment or annoying their co-workers.

If a task is critical and uses audio cues to help facilitate action, it might be a good idea to also show visual cues as well to compensate for self-imposed limitation users might make. Nevertheless, the post linked above is very informative. Enjoy!

PinPoint Performance Solutions has selected ABD Insights, a Boise-based web development firm as its preferred user interface development partner. The partnership is mutually beneficial to both companies whereby PinPoint Performance Solutions strengthens their user interface design and development service offering to their clients and ABD Insight increased their market reach.

According to PinPoint Performance Solutions’ President, Justin Beller, “We chose ABD Insights as a preferred user interface design and development partner because of their commitment to functionality, usability, user experience and compliance.” The visions and missions of both companies are seen as very compatible due to the divisions between programming interfaces for desktop software, web-based applications and websites are becoming less apparent. ABD Insights’ President, Aaron Day says that, “the line between these different mediums is quickly disappearing. New technologies make it possible to deliver a very similar user experience on the web or for the desktop.”

Back in December I had a conversation with a CEO from a software company. During of our conversation he said user interfaces tend to be a manifestation of what the programmers are coding. In other words, what the end-user sees is the programmer's vision of what they think the interface should be. When that happens, the interface becomes far too technical and doesn't take the end-user's needs, preferences or goals into account.

I certainly don't mean to stereotype and neither did this CEO. Programmers are good at what they do, which is implementing the requirements and architecture of an envisioned application. They also work hard to test and deploy the application upon completion. If they do all this work, is it fair to expect programmers to be user interface designers?

Designing interfaces encompasses a range of disciplines that I don't feel many programmers are all that interested in. It's the Someone, Someplace and Something model I revealed back in February. Taking this into account will help develop a good user interface. How one arrives there entails things such as user analysis (identifying needs, constraints and objectives) and information architecture (the flow or process of information that enables the end-user to accomplish their goals and tasks).

It's all about what's in front (the interface that the end-user sees and interacts with) and what's below the surface (the coding that makes the application do what it does). If an application is crucial to a business process, leave the programming to the programmers and let the interface designers have a crack at contributing to the production of a usable product.

Note: Content for this blog post has been drawn from Usability First: Consulting.

Usable systems such as software and web applications should seem intuitive to the end-user, but getting there is not always as intuitive for programmers and developers.

What Do Usability Consultants Do?
Usability consultants work with designers and developers to analyze how an application meets end-user needs so that they can improve upon its concept to enhance productivity, increase overall end-user satisfaction, and minimize end-user errors.

If a usability consultant is brought in before a website or software application is created, they can help developers achieve consistent, usable results. This is the preferred model for development, as usability is built into the application rather than as an afterthought. Usability is not about making a user interface attractive. It encompasses issues such as information architecture, design, writing, and quality assurance. Usability goes way beyond the surface elements.

If usability is brought in after production, it can evaluate the usefulness of a website or software application by using one or more usability evaluation methods such as focus groups, job / task analysis and end-user testing.

Usability consultants usually offer such services as needs analysis, heuristic evaluation (often conducted through expert critique or usability testing), user interface design, and usability training.

What Are The Benefits Of Hiring A Usability Consultant?

• Increasing the usability of a website or software application results in increased productivity for the end-user.
• Bringing a usability consultant into the design and production process will reduce overall costs as it is more cost effective to build a usable application than it is to repair an unusable one.
• Doing a less than thorough job can cost more than money. It can cost time and customers.
• Usability consultants can evaluate systems more efficiently because they know what to look out for based on their experience with a wide range of systems.
• They can bring perspectives that those close to a project may not have considered. It is often difficult to be objective about your own work when you are closely tied to it.
• Consultants are trained in a range of usability evaluation methods. The advantage comes with knowing which method is best for each individual project.
• Having a usable application will result in satisfied, productive users with lowered support costs.

I found this blog post rather interesting:

10 Tips for Moving From Programmer to Entrepreneur

What piqued my curiosity was this is a programmer who came to his own realization that he must have a business mindset as a programmer in order to be successful. Some of the same things he discovered are the same things I have been long communicating to the IT community when it comes to creating usable software and web applications.

Here are a few quotes that caught my attention and some comments:

Design is everything, relative to the competition. Your product has to be nicely designed. Standard programmer square boxes with gray backgrounds don’t cut it! ...People DO judge books by their covers.

In other words, the user interface is important. Don't let the coding or the programming manifest the interface. The end-user could care less about what is behind the scenes as long as the application meets their expectations in terms of looks and function.

Admit that you don’t understand the end user and rectify that. There’s a good chance that the software you are writing is in a domain you are not an expert in. You need to understand the actual customers. Talk with them. Without talking to the actual end users you’ll never know what features you’re wasting your time on and which ones you don’t have that are critical.

In most cases, it's as simple as a job / task analysis. If you are able to understand what the end-user does, what tools they need to accomplish their tasks and under what conditions they will be conducting their tasks, you are on the road to truly understanding the end-user and creating an application that meets their needs.

Remember to design for ease of use. Even advanced users like easy. Your user interface is no place for fancy technology tricks. Keep is simple. Advanced users love simple just as much as newbie’s.

I think the tendency for most programmers is to use the interface as an example of their skills. This is not the place for it. When it's all said and done, it's about the end-users and their needs - not what you can do as a programmer.

As end-users of technology products, we don't often have the luxury of communicating with the designer to find out what their intentions were when they developed the interface to the software or web application we are using.

The illustration in this post demonstrates the need for good user interface design primarily on the basis that end-users and designers are unable to speak with one another. Designers and developers manifest their model or concept of the technology they are creating through the user interface. This is, after all, how the end-user will interact with the product. A clear, concise user interface that easily communicates how it works what its purpose is to the end-user is far better than one that leaves people guessing.

End-users have the advantage of interacting with the product and receiving feedback. However, if the product is not able to provide feedback in some fashion to indicate whether or not the end-user is using it correctly or if it is not clearly communicating through its visual features how to easily use it quickly and efficiently, they are likely to grow frustrated and reject the product.

Even though we're taught not to judge a book by its cover, when it comes to product design, especially with technology, it means a lot when the designer and developer needs to communicate their intent to the end-user. If you want a good book on this subject check out Don Norman's The Design of Everyday Things.

Recently we saw the new Apple iPhone unveiled in San Francisco, and although I'm not a user of Apple products, I was quite impressed with what I learned about this new device. No buttons - the interface is entirely touch screen. What intrigues me even more is the display of convergence in this device.

Convergence has always fascinated me. In the last few years I wondered where or when the tipping point will be in consumer electronics where all the many devices we have will merge into one. I think we've found it.

If convergence was at a stand still I imagined the average technophile would have the equivalent of a Batman Utility Belt where he or she would have their cell phone, their PDA, their iPod and maybe a GPS clipped on their person. Not very fashionable and I'm sure Mr. Blackwell would have something to say about it.

Some devices have made honest attempts to converge many technologies into one product. For instance, I have a PDA that I've used for almost three years that I can do many things with such as write and edit documents and spreadsheets. It has wireless capabilities so I can send and receive e-mail and it can hold a whopping 25MB of MP3 files for my listening pleasure! Basically, in one unit I have office applications, an e-mail client and an audio device. This is insignificant compared to iPhone's ability to store 4 to 8 gigabytes worth of audio files, display audio and video and provide a web browser that will shows content as close as possible to what we see on our desktop or laptop displays. And one thing I can't do with my PDA that this new device can - I can't place a call from it.

There's much more to this device than I can report here. CNET has a video review of the product. As you watch the video, pay attention to the number of different technologies they have merged into one. Perhaps you will be as intrigued as I was.

Information architecture is the "unseen" portion of a website or web application. It's essentially the structuring of information for a dedicated purpose. Often it is in the context of user interactions, navigation or usability.

There's a great book on information architecture called Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville. In some circles it is affectionately called "the polar bear book".

To most end-users, information architecture is irrelevant to them. In fact, end-users are more concerned with finding the information they want or completing the tasks they wish to accomplish when they encounter an interface to a website or a web application. Remember, as far end-users are concerned the interface they encounter IS the application. As developers and usability specialists it is up to us to provide this unseen structure, much like the foundation or frame to a house, that will enable our end-users to find information or complete tasks they wish to accomplish.

Administrators behind websites and web applications currently in use that are discovering their end-users are having difficulty finding information or completing tasks may want to look to their information architecture. If links or navigation buttons are labeled in a way that could cause confusion or if content is categorized incorrectly for example, some changes may be in order.

Jakob Nielsen is a well-known usability expert and offers his suggestions for fixing an information architecture. Mind you, information architecture isn't necessarily an exact science. It is largely based on user-centered design, which many in this field will tell you that no two end-users are exactly alike. You must do your best to find common lines and similarities among your audience so you can build a conceptual model from.

In some ways, the development of a web applications pose a different set of challenges than those experienced in the development of software. Just the other day I found an interesting blog post on the Five Usability Challenges of Web-based Applications. The five challenges are:

1. Scalability
2. Visual Design
   
3. Comprehension (on the part of the end-user)
4. Interactivity
5. Change Management

Let's focus on the first challenge - scalability. Scalability caught my attention because of the very nature of a web applications - or at least what I understand about them. Unlike software, a change to something like the interface can be made and immediately and rolled out to users of web applications. Most software changes, on the other hand, can be controlled by the end-user. For example, I can control the Automatic Updates feature in Windows by turning it on or turning it off, thus blocking any updates that may do something like change the interface of a commonly used program (such as the new IE7 Microsoft recently rolled out). I bet a lot of people who did download the update recently became confused when the launched the program for the first time to see no menu bar (i.e. - File, Edit, View)

In a web application, any changes made are propagated out to hundreds, if not thousands of users whether they want them or not. The blog posting I linked to provides and interesting case study with the social networking website Facebook.

Two things regarding the challenge of scalability should be addressed. First, you need understand the broad base of users. Not everyone is going to like or understand the changes being made even if they were made with the best intentions. Second, when changes are made users need to have some control over the change and how it will affect them. The same blog post provides another example with the popular movie rental web site, Netflix, regarding user control over wish lists.

A book called Future Hype: The Myths of Technology Change recently caught my attention and got me thinking about why companies choose a technology solution to improve their business processes. Is it because of some mysterious, magnetic draw to having the latest and greatest technology present in their organizations or is there an actual need that must be fulfilled.

In the work I do, I help people identify and validate actual needs as it applies to technology in their organizations. If performance can be improved by integrating a technology solution, then we have a good fit provided the needs of the end-user are considered equally to the needs of the business. However, it's been my experience that the pressure to "keep up with the Jones'" and "because everyone else is doing it" tends to drive most business decisions when it comes to technology.

In a previous post, I discussed how solutions should be driven by a true understanding of the job that is being conducted by the end-user, what outcomes they expect and which obstacles they hope to overcome using a technology solution. Having the latest and greatest when it comes to technology isn't always the answer and will not improve performance if three previously mentioned factors are not considered.

In Future Hype, author Bob Seidensticker breaks many myths around technology. One of those is the value people place on Moore's Law. Some industries that rely on computer technology need all the processing speed they can get, like the banking industry for example. On the end-user level (the interface), where the interaction occurs, it's not so apparent. Remember, it's about the jobs, the outcomes and obstacles people wish to overcome using the technology. It's about the needs of the end-user. If bigger, better, faster and flashier isn't going to improve upon any of the three factors don't believe the hype. Build to what is needed. In the end,your time, money and resources can be saved to when you really do need the increased technological performance.