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!

Forgive the rant, but I'm speaking from experience.  When it comes to technology in business, I believe do it right or don't do it at all.

Over the years, and especially in recent months, I have encountered many proprietary applications not ready for their debut and falling short of their expectations.  Good intentions are there but the applications rolled out to the end-users with much fanfare, who are expected to use them and leverage them to their advantage in their daily work, fall flat.  Instead of full functionality, speed and efficiency, end-users encounter bugs, slow downs and errors.

Sadly, bugs and inefficiencies in applications get passed off as being acceptable and part of the design, development and deployment process.  It's not fair to make your target audience or end users unknowingly be your beta testers.  They shouldn't have to put up with such frustrations if they are being asked to use what really boils down to be a prototype application to do their work.  They should be able to use the application with minimal or no bugs and it should work the way they expect it to. Applications should support work performance, not be a barrier to work performance.

I understand that it may be nearly impossible to release a flawless application.  However, rather than put the end users through this trouble developers and stakeholders should take the time to conduct user-centered design, do quality assurance and build an objective usability test where beta testers can contribute in a meaningful way to find the bugs that are "show stoppers".

Find he bugs, fix them and release.

In the end when a fully functional, working application free of major bugs is released it will work as intended and boost productivity and performance in the workplace.

The Web 2.0 world we live in has been beneficial in creating a community of users that share their thoughts and opinions on the quality of just about anything ranging from websites, books and music, to services provided by vendors in their local.

The power is in the hands of the end-user and they now have a voice. Even more powerful and more prevalent on the web is the power of groups. A fundamental paradigm has adapted itself online in the world of Web 2.0: People tend to buy, use, do and think the way their peers do. In other words, there is a human need to fit in and be among people much like ourselves that we often follow the trend so as not to be left behind or seen as out of touch.

Ratings are often the means of expression of preference in the Web 2.0 world. It's easily understandable by all. Something rated "1-star" is often deemed as bad while something given an "A" or a "10" is deemed as good or excellent.

If you intend employ a ratings system in the design your software, website or web application be sure to choose a system that is not only understandable, but objective.

The more common system is referred to as a Likert Scale. It's a 5-point scale similar to the following:

1. Strongly disagree
2. Disagree
3. Neither agree nor disagree
4. Agree
5. Strongly agree

Anything more than 5 points tend to muddy the waters of objectivity. The more choices, the less absolute the values will be. For example, in a 10-point scale where I say "1" is bad and "10" is the best, I may interpret "7" to be OK while another person may say "8" is also OK. Well, which is it?

The Likert Scale is the better choice when implementing a rating system, but it does have it's pitfalls. I find the 5-point Likert Scale to lack objectivity when you give the end-user a list of many things to rate. The trend usually produces a traditional bell curve where most of the choices fall under the rating of "3" - neither agree or disagree.

If you want your end-users to commit to a choice, do a 4-point scale such as the following:

1. Strongly disagree
2. Disagree
3. Agree
4. Strongly agree

By removing the middle choice you avoid neutrality and create greater objectivity. Greater objectivity means better usability to the community of users.

On Tuesday night I had the opportunity to attend TechBoise's networking event featuring a guest panel consisting of Chris Blanchard from Pronetos, Ryan Woodings of MetaGeek and former Idaho Statesman reporter Ken Dey, now with St. Luke's. While the gentlemen discussed their respective businesses, work and views on technology in the Boise area, the event turned into an open forum where the guests and panel participants had a healthy debate on the state of technology in the Treasure Valley.

I mostly listened to the discussion and took some mental notes that I decided I would use as source material for the post you are reading now. For the uninitiated: basically, the situation in Idaho and the Boise area is that the tech community is frustrated by the Idaho state government and what is perceived to be a lack of understanding and support for their industry.

Based on the discussion, here are my thoughts (albeit random):

Why Government Involvement Matters
Prior to the meeting, was very opposed to government involvement in Idaho's tech industry. My attitude was simply. "Forget about it, move on. If they don't understand or care about it, the people in the industry are smart enough to figure out a way around them."

What I did learn was it is necessary to have government involvement, but it should be very limited at best. The two things they can do to ensure the tech industry thrives in Idaho are:

1. Provide a solid infrastructure with minimal obstructions to the movement people and exchange of data.
2. Establish sound economic policies that will allow business to thrive.

If government involves themselves in these two areas, and these two areas alone, the rest will work itself out. It's a win-win situation for everyone involved. Talented workers move and are retained in the state, jobs will be created and the tax base will grow.

Defining Technology
Technology or "tech" is very hard to define. It has different meanings to different people and it is often associated to anything having to do with computers. That may have been true 30 or 40 years ago, but today technology is tied to fields like healthcare, environmental science or aerospace.

Because technology is hard to define, its tangible results are even more difficult to show or to demonstrate. The same can be said about innovation, which I understand is the way our tech leaders are trying to position tech as to our state leaders. Innovation is another fuzzy word because it has different meanings and is often intangible.

It's very hard to define tech to a group of people who only think of tech in terms of Micron, HP and call centers.

Software IS the Answer
A guest at the meeting went into a lengthy diatribe (sorry - that's the only way I can describe it) about how software is not the solution to growing our technology industry. He said it's in innovation, but as I just mentioned innovation is an ambiguous term. What does it really mean?

As many in the room agreed, the Treasure Valley is heavy in the hardware side of the tech industry and when those jobs go away, the skills of the worker laid off or downsized tend to be less transferable. Software is different because many of those skills are transferable. In the long term, software is not the answer but in the short term it is. Software, like most technology is a means to an end. It's what will get us to the next generation of tech that are (today) in the furthest reaches of our imagination.

20 years ago, software was king. Today, software is on the decline and with the advent of the Internet and web 2.0 tools the average person can do just fine in their work without ever purchasing a single piece of software. It's because of software we have the innovations (ah, there's that word) in internet technology and web 2.0 applications. Without it, we wouldn't be where we are today therefore we need it in the short term to take us where we want to go in the future.

Education
Education is the key establishing a relationship between the Idaho tech industry and state government. As I learned last night, Idaho has the oldest state legislature in the country. Not to disparage the older generation - I have a lot of respect for them - but tech is something they are not interested in. Each of them have their own reasons as to why. Perhaps they don't understand it because for most of them they were brought up in agriculture or perhaps they don't see how it can be useful. Another reason, possibly, is that their support for endeavors must be apparent to their constituents. Tech, again, is not one of those things that is immediately apparent.

The problem, as I stated before, is that tech and innovation are intangible. The solution is to show the tangible results of technology in order to speak the same language as our state leaders and garner the support we're asking for. If it's bio-tech, show what is produced or what is a result of a recent bio-tech innovation. If it is clean-tech, green-tech or enviro-tech (whatever you want to call it) show how positive change in air or water quality resulted in the recent application of this science. Whatever the technology, show the most recent usable product or usable service result then you can help stretch their imagination to what can be created.

If there is one thing I have learned as a trainer, the more concrete the example, the easier it is for people to learn and understand the concept.

----
The tech community in Boise and the state government can't be friends until there is a clear channel of communication and understanding between the two. Once the barriers to communication are torn down and there is full and complete understanding between the two parties will we see true progress.

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.

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.

I never considered myself and early adopter. Everybody seems to have one in their life, either among their circle of friends or within their family, but I'm not one of them.

A little more than a year ago, Microsoft released its Vista operating system. When the product launched I didn't run out right away and install it on my company's PC's. I waited on the sidelines like a lot of other people and stuck to what I knew worked for me, met my needs and what I was familiar with. I didn't want to change to something that was unproven and had little to no guarantee that it will work with my software and other hardware devices.

Late last month, I upgraded one of my computers and chose the Vista OS. Actually, I had no choice with the box I purchased. It was either Vista or nothing. After a year in service, I thought it was time to give the OS a try. To me, the change was inevitable. Eventually I would have to make the change because Microsoft will quit offering XP and will no longer support it in the near future.

A recent PC World article titled Why Users Hate Vista explained how change in an operating system is more emotional (to the end-users) than technical (for the IT personnel). When it comes down to it, any technical change for an end-user is emotional. It's human nature to resist change. Just ask my friend who wrote a recent post on his blog about change. Bottom line: people are creatures of habit and will prefer to keep things status quo. At minimum they will be very selective about the amount of change they are willing endure.

In business and the IT world, change is unavoidable if you want to remain competitive. I don't recommend change for the sake of change, but if it improves your business processes it should be implemented with thought and consideration for the end-user. After all, it is they who will be leveraging the technology to drive the business processes that bring about success.

How does one implement a technology change despite the emotional reaction people will have to it? The answer is Change Management.

Here are some tips and thoughts I have on this subject:

• Focus on the people - consult with the end-users. Include them in the decision making process when making changes to the technology they will be interfacing with. Work with them to identify their needs, the obstacles they wish to overcome and their overall objectives.
• Communicate strategic messages - discuss the reason for the change and solicit feedback. Clarify how everyone will be involved in the change and give them ownership in the implementation strategy.
• Communicate and train - provide ample notice and support for the new technology measure the results. Above all, maintain open lines of communication to allow end-users to ask questions and voice their concerns. Address them promptly.
  

If you take careful consideration into what you are doing and who you are doing it for, you can be confident that the change will be embraced and implemented as it was intended.

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

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.

One of my favorite websites, BNET, has put together a feature on Web 2.0 and how it can work for you in your business.

Not only are you able to find out what it is and what specific tools are at your disposal, you can also learn how to put it to use in your company. I encourage you to read this article as well as others in the feature if you are considering using Web 2.0 technologies in your organization.

Here are some highlights from the article and some thoughts I have on this topic:

• Web 2.0 - simple deployment, simple management and lower overall costs. There is typically no software to buy and configure on a network server or desktop. Management and maintenance of the application is often minimal. Somebody else is usually responsible for the "dirty work".
• Implementing Web 2.0 in an organization should be done out of a need to improve performance, productivity and communication. It shouldn't be done for the sake of the technology or just because "everybody else is doing it." The solution the technology provides should be to evolve current processes and practices, not to revolutionize what is currently being done. The key is to have minimal pain and minimal resistance during a time of change. Otherwise, your initiative could be rejected by the end users. Find a champion for your cause that people respect and are willing to follow. It could be you or it could be someone else.
• Some Web 2.0 applications have poor usability or counter-intuitive interfaces. This is a young field and there are bound to be many bugs, glitches and overlooked features that may be important to you. In this day and age, beta is the new "final release". It just comes with the territory.
• Be willing to experiment. Find the root causes to performance problems and identify whether or not a technology solution is the answer. If so, choose an application and see if it works for you. If not, you are out very little due to the nature of the technology. Simple deployment, simple management and low cost make it affordable to try on different hats until you find the one that is the best fit.

I would be very interested in learning what you discover in these articles. Perhaps you'll come to the same conclusions or arrive at your own. Enjoy!

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.

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.

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.

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.

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.

I’m always interested in finding ways to reach new customers and keep the one’s I have happy through my website or blog. One way to do this is to make sure my website and blog adhere to tried and true usability standards.

I always learn something new each time I find an article or blog post on the subject of usability. I’m not perfect and I haven’t applied every tip and trick I’ve encountered. One thing you find as you begin to focus more on usability, it’s an ongoing process.

Recently I found this blog post discussing usability as it relates to websites, mostly e-commerce sites. I encourage you to read the post, but I thought I’d take the same five points and adapt them to a reader who may be in the business of designing and developing software and web applications.

Here we go:

1. You just can’t afford not to – the user experience is what keeps your end-users engaged and continuing to use your applications. If it doesn’t meet their needs or is difficult to use they’ll find something else to replace it.
2. The user experience is more important than your brand or pricing – the most popular software companies in the world can make all the software they want and sell it for a good price, but if it doesn’t meet the needs of the end-user they will likely reject it. I don’t want to name names, but your company name, your pricing and distribution strategy has very little to do with how your application will be received by your target audience. It’s about meeting needs and helping people accomplish tasks to their expectations.
3. Gain a competitive advantage – usable software and web applications have a greater loyalty among end-users. In the e-commerce world this is identified as conversion rates and repeat customers.
4. Focus on the standards – stick to usability standards outlined by organizations like W3C or ISO. When standards are employed, end-users encountering your software or web applications know what to expect and can grasp key concepts quickly.
5. You are already spending on design – why not continue the process? Business needs change as well as the processes that are part of the business. You’ll likely make changes to your application so budget accordingly. Focus on the usability of the application first and the design & aesthetics second.

As I said, usability is an ongoing process. If you make the commitment to usability now, changes you make to improve your software and web application in the near future will be minor compared to monumental changes if you had not focused on usability at all.

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.

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.