I’ve been preaching this philosophy for many, many years now and it seems there is no end to the number of ways it can be used and implemented in your everyday professional and personal life.

How many times have you seen someone look like they’re going 100 mph to finish something only to find that they made 5 mistakes and did it so sloppy that it had to be done all over again anyway. The examples can range from laborious tasks at work to a child’s homework assignment. The philosophy still hold true.

Small Business Accounting

Do you know a small business owner who spends a ridiculous amount of time managing invoices, writing checks by hand and running to the bank every other day? I do. And I tell this person (who will know it is him if he reads this) that if he just took 1/2 a day to learn how to use an online billing system (such as FreshBooks) he could spend all those same hours focusing on things such as sales for his business or improving his quality of life. An online billing system could automate nearly 90% of his repetitive, everyday manual tasks and improve his level of service for his clients. Invoices, payments and year-end tax reports – handled at the click of a button. Client billing notifications and payment histories – automatically emailed. Accounts receivables and revenue reports – automatically tracked and accessible on a single screen. Not one trip to the bank. Not one check written. Not one invoice mailed through the post office. It goes on and on.

Yet, spending 1/2 a day to save literally hundreds of hours per year is too much trouble.

Computer File Backups

How many people do you know take the time to learn how to back up their computer files – and actually do it? With all the easy-to-use technology options available today ( Dropbox, CrashPlan, External Backup Drives, Time Machine, etc…) there’s really no reason why anyone should not be backing up their files some how, some way. Yet, there is usually only one sure way to get someone to start backing up and that’s when they’ve lost all or some important files.

The primary reason (excuse) people give for not backing up their files is “I don’t have the time to learn how to do that”. I could not help but hear that ringing in my ear when I was recently asked to spend several hours trying to recover some lost files for someone.

The conversation went something like this:

• Person in need says: “My email says its database is corrupt.”
• I say: “OK. We can first try to rebuild it and hopefully that will work. If not, the worst case scenario is that we may have to roll it back to one of your most recent backups.”
• Person in needs says: “What back up?”
• I say: “OK. We now have a new worst case scenario.”

Computers crash. They break. And files get corrupt. It’s a fact of life when working with computers.

Take the time to learn to back up your files and you will save you countless hours trying to recover or redo all the files you will inevitably loose.

Homework

I am a father of 2 boys. As a parent you are constantly trying to instill good habits in your children that will make them better people as they grow up. When it comes to homework, one of those habits we are working on is handwriting. I try to demonstrate how writing fast and sloppy will make their homework take twice as long for the following reasons:

• Either my wife or myself will make them erase their work and write it again – neatly
• They will have arrived at the wrong answer because they couldn’t read their own handwriting
• It will appear to us or the teacher that they arrived at the wrong answer (even if they didn’t) – so they will have to redo the problem anyway

Software Development

In my position as Director of Creative Operations at Fusionapps, I am always getting on my soapbox to preach the importance of prototyping a software solution before investing hundreds of hours in developing it. It sounds logical enough, if you spend the time upfront to design and prototype a product – it can save you hundreds of hours re-architecting and recoding the software once it has been deployed. Yet, too often we see companies rushing to get a project into development before they even know if they have a good design – let alone a viable product. In fact, more often than not, a company will try to throw a kitchen sink full of features into the first release of a product without taking the time to learn if any of those features will be of any use to their users. A far better approach, which we employ at Fusionapps, is to quickly identify the features of a minimum viable product, design it, test it, measure it, build it, deploy it and then learn from it so you can make it better.

The Bottom Line

Most every task has a beginning and an end – and if you truly examine the full duration it takes to complete a task, more often than not, the task that was rushed will take longer and have a much worse end-result than the one that was done right.

So, “go slow to go fast” and spend a little time to save a lot of time.

Too often design decisions are made during the course of a project that are based solely on opinions rather than the knowledge of an experienced UI design specialist and/or the results of a usability test. Unfortunately, it’s also nearly impossible to convince people to stop relying on their opinions to make good design decisions, which is exactly why you should never argue your opinion over your client’s opinion. Instead, you should purposely tee-up your discussion by coming prepared with facts.

Don’t take my word for it – take your users

The best way to tackle the “opinion” issue is by backing up your arguments with facts. For example, if a usability test concludes that 90% of the tested users did not interpret the navigation menu labeled “Help Zone” correctly, then your argument to change the name to “Tech Support” will hold a lot more water. Card sorting exercises and usability tests are a great tool for getting opinions off the table and start steering the project team towards making decisions based on facts.

These studies show…

Another tool to use to help build you case is research related to the client’s project. Often times, you can find compelling studies that have already been performed that can be used to help build your case for why a design should or should not be a certain way. For example, I recently had a client tell me they really preferred a certain cascading menu because it enabled their users to access any screen in one click. Unfortunately, the menu system design was flawed because once you clicked on a new section, the menu no longer displayed (or marked) where in the application the user was. So, I was able to present research about the importance of wayfinding and having a menu system that clearly marked where the user is at all times. As a result, the client changed their opinion.

If you think about it, there is no good reason why explaining the process and resources used to build a house should be any different than explaining how you build an application or website. For example, take a look at the typical resources used for both and how similar their roles are:

Where it all began

Since the beginning of software development, creating a usable interface has always been a challenge. Before the Internet boom and the wave of web-based applications that followed, technology teams developed green screen and client/server applications with limited UI capabilities and design freedoms. These inherent limitations caused many development teams to overlook the need and importance of including UI Designers in the development process because the perception was that there was only so much “designing” that you could do. Unfortunately, it appears we are still struggling to find a new solution to an old problem. Today, the lack of focus on UI design has been further compounded by the dramatic increase in demand for web and mobile applications.

In addition, during the Internet boom, developers became a very hot commodity because they were the only ones that could get companies up on the Web. During the late 1990’s developers were demanding $200 to $250 hourly rates and some were even getting professional athlete-type signing bonuses. This explosion of demand put IT departments in the driver’s seat and enabled them to control all web-based projects. This ownership is exactly why most applications are still developed using a system-centered approach rather than a user-centered design.

If it’s not “usable” then what’s the point?

Sounds simple, yet the idea of making an interface usable continues to fall to the bottom of the barrel when it comes to the priorities identified in most application development projects today. Many projects start out with good intentions and agree that the application should be easy-to-use. In fact, often times making an easy-to-use application was the entire business driver behind getting the project started in the first place. The irony lies in the fact that the tasks involved with making a usable interface are usually the first to be overlooked or cut out entirely. (The next to get cut is QA/Testing…but that we’ll save for another article.)

Since most application development projects are managed and executed primarily by Information Technology (IT) teams, the project’s priorities are usually focused on developing functionality that “works” according to a set of Business Requirements and Use Cases. This approach can be characterized as a “system-centered approach”. The primary flaw in this approach is that the User Requirements are often left out and never defined. User Requirements help the entire project team understand what the user’s needs really are and how they will perform the tasks driven by the Business Requirements. For example, a Business Requirement may define the need to capture product data into a database, which can be accessed through a web browser. The User Requirements may define how a user will enter the data into the system based on previous learnings and current needs.

Countless articles are published on a regular basis about companies that have lost millions of dollars in developing and deploying failed applications and websites – mainly because their end-users struggle to use them. The unfortunate part about these colossal failures is that many of them could have been easily avoided if the had utilized a more “user-centered design” approach.

The bottom line is making something “work” is never good enough. Making it work and making it usable should always be the goal. Throughout the years there have been countless examples of products that have failed not because they didn’t work but because people could not figure out how to use them. For example how many VCR clocks needed to blink before they finally redesigned the interface to make it easier to set the time? Of course, if you couldn’t set the time you couldn’t record a show – so one poorly designed feature often impacts another. The same holds true in designing an application. If an application is difficult to navigate, chances are many of its features will go unused because the users can’t find them.

The value of using UI design specialists

A great deal of a UI design team’s time is spent on educating project teams and clients on the value of involving UI design specialists from the beginning and throughout the entire lifecycle of any application development project. Often times the education process involves a presentation, which may include:

• A walkthrough of the user-center design methodology.
• Sample deliverables so clients know what they are paying for and technology teams understand what will be delivered to them and how they will need to be involved in the process.
• Samples of applications that did not utilize a UI design specialist versus ones that did.
• Research that demonstrates compelling facts about the importance of usability and UI design in the words of industry experts, instead of your own.

Let the developers develop and the designers design

The most successful application development projects are those that utilize resources for their strengths and do not stretch them into something they are not. Obviously some projects with smaller budgets cannot avoid using resources that need to wear many hats but making the database engineer design the UI should be avoided at all costs. In my experience even a little help from a UI design specialist can have a tremendous positive impact on a project’s success. In one project, the budget did not account for a UI designer at all but halfway through the project the Project Manager could see that the interface was not coming together so they found a way to involve a UI designer for 2 weeks so the developers could at least be given some templates to apply to all the screens of the application. In this case, the project went from a path of certain disaster to one that the customer praised and more importantly the users could easily use.

A growing issue in usability and UI design deals with the fact that there are so many different, conflicting usability studies and so-called UI standards that lead to many misinformed design decisions. It is important to know that, while some standards are true, not all can be applied to every unique project. The bottom line is that there is no “one size fits all” rule in usability. The best way to decide what is the best design decision is to research your designs and conduct tests with actual end users (period).

Some myths and misconceptions include:

1. UI design is the graphics or aesthetic display of the interface.
2. All users read left to right.
3. Everything in the application should be no more than 3 clicks ways.
4. Scrolling is bad.
5. The design should always fill the screen – at any resolution.
6. Drop down menus are bad.
7. Links within the content are bad.
8. Everyone knows the company logo always links home.
9. The total page size should be less that 70K.
10. Users will not wait more than 5 seconds for a page to load.
11. Usability issues should be handled with user training and help documentation.
12. Usability testing is a time-consuming and expensive effort.
13. Changing a design from a previous version will confuse users (even if it’s easier).
14. We don’t need a UI designer because we already have a UI Style Guide.
15. What sells this software is its functionality – not its interface.
16. Usability Tests and Focus Groups are the same things.
17. QA/Testing, User Acceptance Testing (UAT) and Usability Testing are all the same thing.
18. Client/Server application projects don’t need UI designers.

Feel free to leave a comment and add your own – I’m sure I missed a few hundred.

Ask any Small or Medium Business (SMB) where they get most of their business and they’ll tell you “word-of-mouth”. Then, ask them how much they invest in local marketing and advertising and they’ll tell you “too much”. The irony lies in the fact that far too many SMBs do not view word-of-mouth as marketing or something they should invest in – yet they cite it as the one sure thing that actually gets them new business.

Be Smart
Now, more than ever, SMBs need to be smart and creative with how and where they market their business. The one mistake a lot of small businesses make during trying economic downturn is to stop all their marketing efforts. Being smart means taking a good hard look at what you already know works and figure out ways to make it work even more. If word-of-mouth is the number one way you get your business today, then look for ways to expand and maximize its effectiveness by getting it in front of as many potential customers as possible.

Smart businesses, such as 54 Main Bar & Grille in Madison, NJ, have recently discovered exactly how much the Internet can impact the success of their business. They recently stopped buying ads in local newspapers, magazines and the Yellow Pages and, instead, shifted all their efforts to Internet Marketing. In addition to revamping their own website, 54 Main started using BuzzHub.com to help them expand their existing word-of-mouth network and to help them get found on Google. 54 Main now includes, with each bill, a card asking customers to post a review for them on BuzzHub. In return for posting a review, customers receive an incentive or discount on their next meal, which encourages repeat business. 54 Main’s owner, Joe Iossa, says “we’ve had record breaking business recently – even in this economy – and I can only attribute it to our recent focus on Internet Marketing and, specifically, what we’ve done with BuzzHub.” In addition, 54 Main’s V.P. of Marketing, Todd Gieger, says, “In the past, we’ve tried every other form of traditional marketing but nothing comes close to the direct impact that this has had on our business. Ironically, and perhaps more importantly, this is also the least amount of money we’ve had to spend on marketing.”

Change is Good
Research now tells us that the primary way people find local businesses today is by searching on the Internet. So if your spending most of your marketing budget on local print ads and coupon books, it may be time to rethink that. Consider the difference between getting an ad seen in a local newspaper and getting a business found on Google. Newspaper readers are primarily motivated to read about the local news – not seeing an ad. However, Google users are primarily motivated to find what they are searching for. In other words, if a Google user is searching for a local business, it means they are already motivated to buy from a local business.

There are lots of ways to help get a business found on the Internet. You will find tons of companies that offer Search Engine Optimization (SEO) and Search Engine Marketing (SEM) services, which all claim to get a business “top placement” in Google. In reality there is only one guarantee when it comes to getting a business found on the Internet and that is doing a little helps a lot and doing nothing hurts a lot. The trick is to not only get a business found – but get it chosen, which leads us right back to the power of word-of-mouth. Nothing is more powerful than having a business’ own customers say how great the business is. So if you’re a great business with happy customers, be smart and start expanding and maximizing your word-of-mouth network.

————————————————————————————-

Chris Gieger | President & CEO, GIEGER Visual Communications, LLC

First, determining which to use:

1. What knowledge do we expect to gain?
   a) User’s aesthetic preferences, functionality needs, expectations = Focus Group
   b)How users: perform tasks, interact with functionality and interpret label names = Usability Tests
2. What will you expect to have the test subjects look at or use?
   a) Mockups, competitor sites, color schemes, graphics = Focus Grou
   b) Mockups, wireframes, paper prototypes, on-screen prototypes = Usability Tests

Focus Group Goals and Expectations:

1. Use the focus groups to reveal user needs and what they “want” from the site/application.
2. Expect the focus groups subjects to concentrate what they like, dislike and why.
3. Keep focus group studies separate from Usability Tests.
4. Realize that focus groups can only assess the way user “says” they perform certain tasks and not the way they actually “perform” them. Knowing this, avoid asking questions in a focus group that involve performing a task or whether the user “prefers” one navigation system versus another. People either love things, hate things or feel indifferently about them…and none of these have anything to do with whether something is usable or not.
   For example: A question might be posed to a test subject asking “Do you ‘like’ dropdown menus?”. The answer to this question would not provide any beneficial data. The answer you really want to know is whether “These dropdown menus, with these items, and this wording in the context of this page create are clearly understood and easy to use for most people who are likely to use this site”. The only way to determine this is by observing how a user uses the dropdowns.
5. Expect focus group test subjects to compare your site to other competitor sites.Run more than one focus group because the outcome of any single session may not be representative and discussions can get sidetracked.

————————————————————————————-

Chris Gieger | President & CEO, GIEGER Visual Communications, LLC

The Problem with Use Cases

Use cases have become a staple in many software development methodologies, yet many development teams do not write use cases that provide enough value to their intended readers. Software engineering expert Ivar Jacobson originally documented use cases in his book “Object-Oriented Software Engineering: A Use Case Driven Approach” as “a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system.” The problem is that over the years too many different use case styles and formats have emerged, which has led to a general lack of consistency and purpose for their original intent. Use case writers are now mixing “concrete use cases” with “essential use cases” with “narrative use cases”, etc. In addition, many use cases are also often written with too many words and not enough meaning for their most important readers – the client.

I have been involved with numerous projects where the Business Analysts and Development teams spent several weeks (even months) writing hundreds of use cases only to find that the client couldn’t understand them. In fact, often times the uses cases (usually kept in huge 3-ring binders) were never used – even by the developers. Rarely do clients need to (or want to) fully understand each and every system response documented in use cases. What they usually want is to “see” the interface that will provide them or their users with the functionality that they want to have built. The bottom line is, if the client is footing the bill for the project then they will most likely want to approve each of the deliverables. If the client cannot understand the deliverables, chances are they won’t approve them.

Tip: Show your client some annotated screen mockups or wireframes and you’ll see a client that can quickly and easily understand its intended functionality.

Real World Experience:
I once had a client tell me that he was able to define more requirements from a 2-hour presentation of preliminary UI mockups then he was from 4 days of Joint Application Development (JAD) sessions. The reason he stated this was obvious – he could visualize the elements of the interface and therefore define how they should function. He was also able to then realize what was missing, what he hadn’t thought of during the JAD sessions, and prioritize what functionality should be built for the initial release.

Use Cases Should Never Define the User Interface

Use cases are intentionally focused on the system needs, not the user’s needs. Yet, use cases often blur that line and include UI requirements without any input from the end-users. This seems to be an area where many software development projects begin heading the down the path to an end-product that may function properly but is not usable, sellable or marketable to its end-users. Use cases are inherently too system-oriented to determine UI requirements, thus use cases should never define or be used as UI requirements. Ideally, an Information Architect and/or UI designer capture User Interface requirements with input from end-users at the very beginning of the development process.

Often times use cases will be written to include things that are not appropriate for their purpose, such as:

• Use cases often define user task flows based on system or functionality needs instead of involving end-users to help determine what flow would be best for them.
• Label names are often stated in use cases that end up becoming concrete without testing with users first. For example, a use case should never define a label name such as: “user selects ‘Submit’’’. Instead, the use case should simply state the system need, such as: “system stores data to database”. The user should help determine the best label name for the UI with the help of an IA or UI designer.
• Development teams will often feel that the use cases tell them enough information to build the UI and so they proceed without the help of UI designer until the system is built and tested—at which point they will look to a design team to “dress up” the interface. I sometimes referred to this as “putting lipstick on a pig” or making a bad UI simply look aesthetically better.

A Picture Tells a Thousand Words
The best possible use case is one that helps all its intended readers understand what it is trying to communicate so that all project team members and the client are on the “same page”. In the high-level use case diagram below, all the major pieces of system functionality are captured.

In the Use Case scenario template example provided below, the following key elements are used to help the reader understand the Use Case:

• A Use Case Title that clearly labels the Use Case.
• Short and clearly segmented topics and content on the right so the reader can quickly scan the Use Case and understand its intent. Note: the usual term “Actor” is purposely replaced by “User”.
• Visual wireframe layouts on the left to help the reader visualize and follow the Use Case scenario and understand how the words apply to an actual interface – even if it won’t be the final UI.

References:
Ivar Jacobson – “Object-Oriented Software Engineering: A Use Case Driven Approach
Constantine & Lockwood, Ltd – Structure and Style in Use Cases
Sari Kujala, Marjo Kauppinen and Samma Rekola – “Bridging the Gap Between User Needs and User Requirements”

————————————————————————————-

June 2003 | Chris Gieger | President & CEO, GIEGER Visual Communications, LLC