PinPoint Performance Solutions Blog (Legacy Content)

A reader took me to task on a recent blog post I made where I ranted about how bugs and workarounds shouldn't be acceptable or "a way of life".

Patrick Neeman at Usability Counts made two valid points in his response to my post that resonated with me:

1. Test early and test often
2. We live in a beta test world

These two things, among other strategies, will help mitigate usability issues. 

The best example, currently, of living in a beta test world is Google Chrome.  Companies like Google make no bones about the condition of their applications as they are developing them and preparing them for a final release.  It's clearly in Beta - it even says so on the download page.  I'm even using a beta version of the blogging platform I'm using to write this very post.  Believe me, it's far from perfect.  However, the strategy is to let the users be the testers and give them the opportunity to take a form of ownership in the application's further development.

There's nothing wrong with this strategy and I often encourage it among the people I work with.  My point is if the business conditions allow it, do upfront due diligence to make sure the application you are putting out there has a minimal number of bugs, errors and usability issues.  Having these problems only hurts end user performance, if you are expecting them to use the application right away.  A buggy application only slows people down and keeps them from the work they intend to do leveraging the application.

I appreciate Patrick's feedback and I appreciate his willingness to let me comment to his post.  Lesson learned for me is to not vent and blog at the same time!

I was happy to see a post by Peter Abrahams at IT-Director.com on the Future of Usability Testing. The reason I was pleased to see this post was because it backed up my assertion from what I feel to be a credible source that usability and user-centered design during the conceptual and development phases of software, website and web applications, should be a holistic process.

By holistic process, I mean to say that the usability of the application should be linked to the business need. The business need can mean two things - one for the developer and the other for the customer.

As an advocate for usability, I find that user-centered design and usability applied throughout the development process lowers costs both before and after the application is released. During concept and development, user-centered design and usability under an agile methodology will lead to shorter time frame for the development phase, thus lowering development costs.

If there's one thing businesses love, it's lowered costs!

For the customer, a usable application means less support. Ease of use will allow them to be productive with the application and spend less time trying to train themselves how to do certain tasks. If an end-user can be self-sufficient in their use of the application, acceptance and productivity increases thus making the technology purchase a worthwhile investment. If they are able to complete their tasks quickly and efficiently with the application this can translate into lowered costs for the customer. The same is true for the developer. Money going toward support resources to handle "how-to" questions can be diverted to resources that tackle tough technical issues.

Since launching this blog I have written about this topic extensively. Here are some past posts on this subject:

• Maintaining User-Centered Design in Agile Software Development
• User-Centered Design and Agile: Why Can't We Be Friends?
• User Centered Design, HCI and Agile Development Compatibility

I think it will take some time for business leaders to have a meeting of the minds with developers on the need for usability, as demonstrated by the panel discussion that Abrahams reported on in his article. When that will happen it is hard to say, but the trend appears to be moving in the right direction.

I recently stumbled upon a blog post at BNET.com that discusses how innovation can go overboard. I'm all for innovation. It's what makes living in this day and age exciting. However, too much innovation does little to improve our lives and leaves us frustrated and confused.

When we innovate products, especially software and web applications, we should be asking ourselves a number of questions.

• Will the change or introduction of a new feature or function solve a specific problem for the end-users, address a specific need or help them overcome a challenge?
• Is the introduction of the new feature of function in response to a need or is it for the sake of innovation? In other words, are you trying to "keep up with the Jones'?"
• Are the increased production and development costs that come along with introducing the new feature or function going to pay off in the short-term or long-term?

These are just a few questions that come to mind, but I'm sure there are many more. Overall, the question that should be asked; is the innovation needed? If not, leave it be. As the blog post so eloquently states, if you start playing a game of one-upsman-ship, your competitor will inevitably go back to tried and true methods of simplicity and use that as the primary value proposition of the product. Focus on what made the product successful and the value it creates for the end-user. In the end, that's all they really care about.

As I reflect on 2007, two things emerged that defined the work we did at PinPoint and the causes we advocated or rallied against.

1. Focusing too much on things that are less important.


2. Making things bigger or more complex than they really are.

Focusing too much on things that are less important
In September, I wrote about about how I thought some product developers tend to concentrate too much on a single aspect or set of features and not enough in other areas. Some work with a local company last year reminded me of this post and I was part of the effort in redesigning their corporate website. One of the company leaders who was spearheading the project spent a lot of time making sure the home page looked a "certain way." It was, to say the least, a very frustrating obstacle to get the this company leader to overlook.

The reason why it was so frustrating was the assumption this person had about his audience. It was very difficult to get him to understand that not all users, especially his target audience, make their way to the home page of their website first. Understanding how their audience searches for information was key, and more than likely they would search for the products they were selling and not the name of their company.

Assumptions about your target audience can lead you down the wrong path. In the case of this company, it delayed the launch of the site. When you make assumptions about your audience or focus too much on less important aspects about a product, you delay you chances of success or miss opportunities all together.

Making things bigger and more complex than they really are
In June I wrote a post that was somewhat similar to the previously mentioned post.

It bothers me when I engage potential clients who are reacting to the actions of their competitors. Though it is rarely spoken, it often comes back to "Everyone else is doing it, why aren't we?"

I'll heed my own advice and not make this point any bigger and more complex that is should be. The point is companies and product developers should be doing what works best for them, what they know best and what meets the needs of their end-users.

----

One final note, I'd like to say it has been an pleasure writing this blog since its inception in late 2006 and throughout 2007. This year, you will notice fewer posts on a monthly basis. The focus of PinPoint Performance Solutions in 2008 will be quality over quantity. Thank you for reading and I look forward to your feedback and input on future posts in 2008.

Normally I speak about integrating technology in business processes at an enterprise level, but today I thought I'd speak about startup companies and their acquisition strategy. I'm not necessarily talking about startup companies acquiring other companies or technology. I'm talking about the innovation or product the startup company creates being acquired by a much larger company like a Google or a Microsoft.

PinPoint Performance Solutions primarily focuses on the conceptual stage of product development linking the needs of the end-user to the product being developed. The end result is a usable product meeting their needs and expectations. I met with a colleague this past week who works with clients to identify whether or not their products are viable in the marketplace. In other words, he does the due diligence and research to make sure there is a marketplace for the product. I'll admit some failure on my part. My colleague helped opened my eyes to a crucial compenent of product development.

He told me a story of a client who invested a large sum of money into a custom software application for the construction industry. A well-known software company approached him about acquiring the application, but when the offer came in it was far below what he originally invested in the development of the application. He was in the market to inevitably sell the application, but he never thought he would lose money in the process.

The reason why the offer was low was the software company was unable to purchase the application and market it immediately due to how it was developed. The coding was not compatible with their coding and a lot of back engineering would have to be done in order to make the application compatible with their other applications.

The lesson - if you are in the business to generate revenue off of your work or to potentially sell your application to a larger company, plan for it. I'm not saying that you need to make your product the exactly the same way a potential buyer would make it, but you do need to know what they and the rest of the market will accept and what is valuable to them if the opportunity to sell presents itself. It needs to be usable to them in order for them to find any real value in it.

So, just as you would develop an exit strategy in your business plan you need to prepare for an acquisition strategy in your product's marketing plan to create value in your product when a potential suitor arrives.

Some recent work has prompted me to discuss on this blog contextual design. Contextual design is a process to create user-centered applications. The process was created by Hugh Beyer and Karen Holtzblatt and they have written some very good books on the subject.

Essentially, when you sit down to begin the process of designing a new web application, software application or website, you want to understand the context in which it will be used among many other things. To prompt you to investigate this process further as you work to design and develop user-centered applications, here is a snapshot of what contextual entails. Think of the process as series of models you create to create a single picture of what your application will do for its end-users.

• Workflow model – think of this as the coordination of work and efforts along with interactions and responsibilities the application’s target audience has in their daily activities.
• Sequence model – these are the steps the target audience must do in order to accomplish tasks or complete specific activities.
• Cultural model – the norms, influences or pressures end-users experience in their work? Can your application help alleviate them or help them overcome these obstacles?
• Artifact model – these are the documents, content or products that are produced as a result of the work.
• Physical model – what is the environment in which they work and what are the tools, technology and resources used as part of their work.

As you think about these five models, also think about how one flows into the next. To me, they seem to support one another as feeds into the next. Working to create “models” may seem like a huge undertaking, but in reality much of the information gathering is up to you. Be sure what you have to ask is clear and objective to get to the answers you are looking for.

Mr. Godin hit the nail on the head yet again in his recent blog post:

Seth's Blog: Alarm clocks

In the past I have maintained that some product developers, especially developers of technology products, have a tendency to concentrate too much on a single aspect or set of features and not enough in other areas. In Seth's example, he basically says we'd have better alarm clocks if it weren't for people developing them concentrating too much on marketing.

That's not say that marketing is a bad thing. In the end, it illustrates product development is more about what people want out of their products and what they can do for them and less about how many can be sold. If you give people what they want, marketing will come much easier.

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.

As most of you readers know, my career within the last eight years started with designing training programs. Later, it moved to designing training programs to support software and web technologies. Shortly after that it transitioned to my current career where I know support the design and development of software and web technologies using the tools and techniques a training developer or performance improvement specialist would to create and effective solution.

I was e-mailed a question not long ago where I was asked my opinion on whether or not the ADDIE model of instructional design (a method to develop training) was compatible with user-centered design.

I thought I would share my answer to this question to see if I could garner support for my theory or spur some nice, healthy debate:

I think they are very compatible, but each of their intended purpose is different. ADDIE is targeted toward the development of instructional materials and content while UCD is focused on developing software or web-based applications that are designed around the target audience’s needs (tasks, objectives and obstacles they wish to overcome).

With that said, there is no reason why UCD can’t be applied to ADDIE – it simply would be concentrated in the A (analysis) and the first D (design) of ADDIE. This is provided, of course, the outcome you are trying to achieve is an instructional product delivered in an electronic format (software or web-based). I see that happening quite a bit where a lot of instructional materials and content are being delivered in web-based or electronic performance support systems these days.

The fruits of your labor using UCD in the A and D portion of ADDIE will manifest themselves in the D (development) and I (implementation) portions of the model. E, to me, is where usability testing comes in.

One of the most interesting things about blogging is the mental radar screen that develops when you look for topics to write about. Earlier in the week I wrote about the criteria you should consider when deciding to build a custom software application or going with an off-the-shelf solution. Thinking I would move on to another topic to discuss, I stumbled upon an article in the recent issue of Website Magazine that discussed the same topic.

Here’s what they had to say
If an off-the-shelf solution can handle 80-100% of your business process needs, then you should go with it. Most of the time this is true, but there are some exceptions. Choosing a custom software solution presents several advantages. Chief among them is you get what you want provided, of course, you are thorough and detailed in your expectations out of what you want in terms of functionality and how the application will integrate in your business processes. It is an expensive undertaking, but the more detailed you are with your business and technical requirements through good documentation, the better your chances of receiving a final product meeting your expectations.

Here’s my take
The author of the article did somewhat of a disservice to the readers by not including a crucial component that should be considered when deciding between a custom software solution and an off-the-shelf software solution. That component is the end-user. Who are they? What are their needs? What are the tasks they do that can be simplified through a technology solution? What are the obstacles they are trying to overcome and in what context will they be using the solution? All are important questions that should be answered and documented if the choice is to go with a custom software solution. By answering these questions it will also make the choice between a custom solution and an off-the-shelf solution easier.

Businesspundit wrote an interesting post about Why You Should Get Feedback, Then Ignore Most of It.

It reminded me of user-centered design or those early conceptual stages when you are developing a software or web-based application (what do we make?) or after a release that hasn't created the firestorm you were expecting (what went wrong?).

We all want to know that the work we are doing is valued and meets a specific need, but we often take the customer's voice too much to heart when we're creating new products or finding out why one failed. I've written about this many times before, but usually what the customer wants is not often what they need. The context in which they use the product and the specific tasks they are wishing to do are not fully taken into account.

The Businesspundit post goes on to say that if you were to take every little suggestion the customer offers to improve your product or to create a new one, you'll never make any progress. The old saying is very true - you can't please everybody.

Two suggestions are made in this post when you are in the process of conducting some market research on your product (whether pre or post):

First, look for overwhelming consensus. If the end-users are leaning more in one direction use it to validate or dispel your assumptions. Second, look for a nugget of knowledge you may not have been aware of.

In the end, you'll make sure the product you are working on meets the needs of the end-user in how they use it, when they use it and where they use it.

Recently I became a contributor to Evan Carmichael, a website and forum dedicated to providing inspirational and strategic content and information to entrepreneurs. My main focus will be providing content for their new technology section.

Recently another contributor added an article that caught my attention. The focus of the article was about the criteria a company should use when choosing between building a custom software solution and purchasing an off-the-shelf solution.

The litmus test, according to the author, is to decide whether you need something useful or if you need something innovative.

Useful is when you need something that will help you with normal, everyday tasks such as accounting, budgeting, planning or managing information in a database. Innovative is when your business is so unique it requires an application with functionality that fits your business processes. In fact, the author contends that if by developing a customized application you are able to demonstrate a sustainable competitive advantage and if it is something your competitors will have trouble copying, then your needs call for something that is innovative.

So, if your business needs call for a simple, yet useful solution, then an off-the-shelf application will do just fine. Most businesses who have faced this choice when applying a technology solution to their business processes will tell you that it is hardly worth the headache to create a custom application when a solution that has likely been produced will do the job nicely.

Whether you choose a useful solution that is off-the-shelf or if you decide to go with a fully customized application, the key is to make is sure it fits within the framework of Bailey’s Human Performance Model. If the application doesn’t meet the needs of the end-user (someone), doesn’t fit within the environment where it will be used (someplace) or if it doesn’t help the end-user overcome an obstacle or help them accomplish a specific task (something), then the application will hold little value and likely be rejected. That’s an expense most companies are unwilling to risk.

InfoWorld is reporting on a company who has developed a USB device for employees in companies who are on the go. Imagine having your computer desktop wherever you go.

You can read the full article here.

When it comes to usability, the context (how) and environment (where) people will use your product is crucial. When it comes to personal computers, whether boxes or laptops, the Windows desktop almost always is customized to fit the needs of the end-user. I myself have certain programs at the ready on my desktop as well as documents I need to freqently access.

Whenever you can make the product itself or another product all together portable and accessible, you leverage its usability significantly.

As I was catching up on some long overdue reading, I noticed a few topics emerge that reminded me of a post I wrote back in December on User-Centered Design and the Agile Development Methodology.

The theme among the articles I've been reading is that the two are more compatible than most people think when it comes to the development of software and web-based applications. The fact that it continues to be discussed tells me that a misunderstanding between human-computer interaction (HCI) professionals and programmers still exist.

I don't know if my voice will rise above the noise that has been created as part of an effort to foster a level of understanding between the professionals in user-centered design, HCI and software & web application development. All I do know is I can add my own personal insight and commentary on this subject and provide you, the reader, a chance to learn more about this subject yourself to draw your own conclusions.

My research on this subject took me to a couple of interesting places with their own unique views on the compatibility of these methodologies. This post from InfoQ discussed some comparisons and differences (mostly) between HCI and Agile. Despite the differences between practices, a strong focus on the end-user was common. Also, a whitepaper at the Journal of Usability Studies discussed how to make user-centered design, HCI (in their case they called it "usability investigations") compatible with Agile. Their solution is to adjust the scope and granularity of the investigation to accommodate Agile development, however, again, the end-user is central to the process and is a common link between the methodologies.

The link user-centered design, HCI and Agile development share is their ability to be flexible. In addition, they all share the understanding that the end-user is crucial to the success of the final product being developed. If you are looking to bridge these methodologies together to create a software or web-based product, look to the Contextual Design methodology. According to the developers of this inquiry methodology, Hugh Beyer and Karen Holtzblatt in their book Rapid Contextual Design, Agile and other development methods like XP are very accommodating and flexible enough to achieve the desired results.

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!

Businesspundit reported on how Businessweek revisited Clayton M. Christensen's book The Innovator's Dilemma ten years after it was first published. Has anything changed? Maybe not, but the article describes what end-users say and what they actually do are two different things. This is something that innovators of new products often face realize after it is too late.

When we get wrapped up in trying to build the next great piece of software, website or web application, we tend to focus in on what the customer is telling us to identify what or how to build the product (their needs). What we don't do often enough is take a long, hard look at the context or environment the customer derives their needs from. The situations they face and obstacles they are trying to overcome often tell us much more about the actual needs.

Anthony Ulwick, in his book What Customers Want goes into great detail about how the discrepancy between what customers say they want in a product and what they really need is true. He used the example of Motorola. Rather than creating one product that highlighted all the features and functions of their total pool of end-users, they based their product lines on end-user needs and came up with a number products that satisfied specific groups based on the context in which they would use them.

This is a prime example of user-centered design creating usable products that are true needs - not something driven by market research and demographics.

I’m a very visual person and I like it when people make an effort to illustrate thoughts and ideas. After all, thoughts and ideas by their very nature are abstract and when it comes to something like the user experience, you can’t get any more abstract than that.

What is the user experience? If you were asked to draw it as it relates to your product, your software, website or web application, could you do it?

A book called Sketching User Experiences by Bill Buxton demystifies the abstract and helps bring the design process to a more tangible level. You can read a brief review of the book here. Also, a colleague in the Boise area discusses the book to some degree and explains how he uses sketching in his daily work.

I think one thing that turns off some folks from sketching is the pressure to be perfect right out the gate. They see people they perceive as their competition and fear what they are working on is not innovative enough. In the process of designing a product, most of the joy comes from the journey, answering questions that seem to crop up without warning and discovering new things that may not have been considered before.

Even though we live in a digital age, start putting pen to paper to fuel that new idea.

Everybody else is doing it, so why shouldn’t we?

Today I encountered that paradigm among a group of people that left me concerned, asking more questions than coming up with concrete solutions. Is mimicking your competitor’s products and services the best business strategy? Shouldn’t it be more about what works best for your company and, more importantly, what works best for your customers or end-users? What if you went in different direction entirely? You would think that doing something unorthodox would draw attention because it is not the status quo and not what people expect.

Most of the questions I am asking are rhetorical, but today was a typical case study of how businesses make things a lot more complicated than they really need to be. Whether it is basic services or the tools we use internally such as software, websites or web applications as part of our daily business processes, I think the wrong things are being focused on or they are being complicated because businesses and the professionals that run them are so desperately trying to gain the upper hand or just trying to fit in.

Here are a few observations I have about the uses of certain technologies in business today. Some of my observations are based on experience from years past. See if you agree or disagree with me that they are being complicated or if the wrong things are being focused on.

Websites
Far too much time and energy is wasted on what should go on the homepage of a website. Also, too much time is wasted on visual aspects. Regardless if it is for internal or external use, while it is important to have an attractive, visual appeal to you website, the content (what you are trying to say) is more important. May I submit to you the possibility of worrying about your homepage as the last item on your list of web development tasks? Here businesses concern themselves far too much with what should go on a homepage when they haven’t built or collected the content for the rest of the website. How would they know what to put on it if they don’t have the supporting content in place? By placing too much emphasis on the homepage you are shifting your focus away from the end-user and the overall purpose of your website. Businesses make a huge fuss over visuals because their competitors have a snazzy looking website. That may be true, but is it turning visitors off? Does it lack substance? What kind of message is it sending? Better yet, are they people they are trying to reach the same people you are trying to reach? There may be no way to tell with your competitor’s website, but just because it looks good doesn’t mean it is effective. In this case, this is a prime example of placing focus on the wrong things.

Software and Web Applications
I have encountered software and web applications that have been made more complicated than they really need to be. In some cases, features and functions are implemented just for the sake of features and functions. The prevailing philosophy sometimes is, “We may need those features in the future.” That might be what is said, but what is not said is less apparent. Sometimes (and this is my own personal opinion and observation) but features and functions placed in some software are put there to justify its existence or creation. This is not the fault of the programmers who ultimately create and implement the features. It’s usually at the direction of someone else. Unfortunately, unnecessary features and functions are placed in an application without consideration and fully understanding the needs of the end-user or how they intend to use the application. This is an example of making something that should be simple too complicated in order to justify it.


I’m not saying that we should abandon visual appeal for the sake of content and nor am I saying we should weed-out unique and interesting features for single-function solutions. Visual appeal and multi-purpose solutions are what make technology exciting and fun to use. Unfortunately, the temptation is present to go a little overboard because we see other people or other companies doing it. Style, presentation, as well as content and function have their place. The solution is to keep everything in context and not lose sight of the end-user, their needs and expected outcomes while using technology in their daily lives.

Last Tuesday I had the pleasure of being a panelist at Capital City Communicators' Spring Seminar. The topic of discussion centered on how businesses have been using new media to build community and I was there to represent both PinPoint Performance Solutions and my business organization, Treasure Valley Consultants' Network. The panel included representatives from small to medium sized businesses in the Boise area. Large corporations such as Micron (NYSE:MU) and Hewlett-Packard (NYSE:HPQ) were represented as well.

The conversation turned to how blogging has help our respective businesses. Two key points came from the representatives of the larger corporations during the discussion:

1. Blogging has allowed them to focus on specific market segments. For example, Micron services many industries and they've created multiple blogs to appeal to multiple audiences. One particular blog is targeted toward the automotive industry while another is targeted toward the imaging industry. Blogging, to them, is about reaching vertical markets. These are the customers in the "long tail", so to speak. By taking this approach they know that the readers of their many different, yet highly focused blogs are customers most likely to buy from them.
2. Blogging has provided a new channel for product development. For example, HP pays close attention to the number of blogs they have written by people within the walls of their company. They have what is known as an open blogging policy. Anybody within the company can write about anything provided they monitor their blog and respond to readers accordingly. Ideas for new products or product improvements has emerged out of these blogs.

I think the second point is a positive step toward new product development or product improvements. Blogs are a new avenue to gather user information such as needs and preferences. Support forums are another great tool to see where folks are having problems and learning from other users how they solved the problem.

A word of caution - if you think blogs and forums will take place of any user-centered design phase surrounding the development of your software or web applications. It's only a small part of it.

You still have to go out and talk to your end-users, observe them and find out how the jobs, tasks, work environment and context of the problem/obstacle they are trying to overcome fits into your overall design. Blogs and forums can't take care of this task for you. They are merely a resource and help point you in the direction of where you need to focus your user-centered design research.

I've written about this book before, but Anthony Ulwick's What Customers Want strongly discourages product developers from taking anything the end-user has to say about your current product or new product at face value. No offense to your end-users, but they probably don't know what they really need. They only tell you what they want and what they prefer, personally. They can't speak for the rest of your customers.

Blogs and forums hold a lot of potential for new product development, but remember they are just a small component or tool in the user-centered design process.