User friendly CRM for all!

In working to revamp the Import feature of PlaybookIQ, its becoming increasingly clear there is still a gap between the developer and the ordinary computer user.  For the technical partner, its easy to throw terms such as CSV, parsing, and “plain text” around (even in a single sentence!).  As the non-technical partner, it feels like a research project trying to keep up.

So in comes the user friendly application.  But what is user friendly to one is not to the next.  So how do we serve both?  How do you avoid insulting the more technical users while not leaving the not-so-technical behind?

We’ve decided with our import feature, which has admittedly caused the most user errors in our system, to begin the process with a basic “1-2-3″ step process without much upfront instruction.  Import should really be a simple function, and for the user who is familiar with imports and CSV files, this approach should work well.  However, alongside the easy 1-2-3 process, we’re linking to more in-depth instructions and information for those who are unfamiliar with imports and CSV files and need additional help.  We’re providing this further information in easy-to-understand verbage and concepts, in an attempt to not only help our users use our system, but also to educate them.  Oftentimes, this is by providing links to the help section of the current systems they are importing from, systems that have already discovered the best way to explain converting data from their system to a CSV file.

Our goal is to make importing contacts easier than ever.  However, even for the technical savvy, errors with CSV files that cause an import to bomb out.  A missing comma, missing quote, too many quotes – can cause the whole file to fail.  In this case, we’ve decided that more eyes are better, and after our users have examined their file and tried again, we’ll invite the user to send the file to us and try to help resolve the problem.

Our more user-friendly Import feature will launch this week.

Making of a Web App: Part 10 – UI Evolution and Screenshots on Flickr

Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article I share one iteration of an evolution of web application design layouts for PlaybookIQ.

I set up a flickr photostream to show screenshots as they evolved. Read the rest of this blog entry first, and then go check it out.

Key points of visual design for web applications stated as expectations from people using your application:

• Proximity: items near each other are related to each other..
• Relative size: larger elements are more important.
• Relative position: elements to the top and left are more important. Elements to the bottom and right are subsets of ‘parent’ elements above and to the left of them.
• Consistency: consistent fonts and colors make an application feel more reliable and well constructed.
• Inconsistency: an occasional inconsistency should mean that something is important or needed to be called out for some reason (e.g. red text when all other is black).
• Persistent elements like ‘home’ or ‘search’ provide confidence to roam around knowing they can always get back to familiar territory.
• Sign posts: let people know where in the app they are.
• Alignment: an application in which elements line up neatly vertically and horizontally feels more professional, is more trustworthy, and easier to use.
• Whitespace is easily understood as way to separate elements that are not directly related, while a line, shading or other elements must be processed by people scanning a page.
• Context is critical. Metaphors like tabs, sign posts, and grouping help people understand what to expect at a given point in the app and helps people focus on one thing at a time.
• Choice is painful and slow. People simply want to get something done. People do not want to be asked to perform the work of making choices. Keep navigation and activity choices to a minimum.

Refreshing But Professional

In a B2B app such as PlaybookIQ, my design goal is to offer a refreshing, yet still professional experience. I do not want to get too innovative or revolutionary and design and development time to create a wow factor could be better spent on additional features that make people’s professional lives more productive. So, you should expect to see common design decisions here.

A Case Study

This series could be subtitled ‘A “Designing the Obvious” case study’ because it follows along with suggestions made by Robert Hoekman Jr. in his book. Click here for details on the book and here for his blog. [Full disclosure: when I write reviews or references to books, I usually link using my Amazon affiliate link. If you do not want to visit my affiliate link, simply do not click the links in my blog to books and instead search for the book directly at Amazon or your favorite source. Note that so far in this series I’ve made a whopping $5.15 from this practice – early retirement, here I come! ]

Screenshots on Flickr

For the rest of this blog entry, I have set up a flickr photostream with a description on each photo in that outlines the thought process behind the incremental change from screen shot to screen shot. I put the screenshots on flickr because I like the way you can page through them and it is easy then to pick out the changes from screen to screen. If I just listed them here, readers would be scrolling up and down to compare one screen shot to the next.

Click here for the photo stream. You can leave comments on this blog entry or on flickr.

Making of a Web App: Part 8 – Styleguide

Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article we get a little bit ahead of ourselves and talk about styleguides.

Early PlaybookIQ Styleguide decisions:

• Use of the International Style
• Tab-based navigation
• Persistent search box

A styleguide communicates an application’s look and feel, including fonts, colors, element sizing, spacing, navigation, and everything else that contributes to an application’s interface; especially its visual implementation. I don’t yet need to define the look-and-feel details for PlaybookIQ. Yet I am ready to sketch the high level concepts of each screen so I needed to make some early decisions on overall style, on navigation, and to account for some persistent objects on each screen.

The Swiss Style

The International Typographic Style, also known as the Swiss Style, was Developed in Switzerland in the 1950s, and is known for a “clean, simple, and easy look”. The clean, simple, easy look is recognizable in today’s web 2.0 apps. For communicating information and clearly setting context, I like it.

Some see International Style – and any modernist style, for that matter – as worn and lacking in creativity. For them, there’s always the Myspace style.

Features of the style include:

• asymmetric layouts
• use of a grid
• sans-serif typefaces
• left justified/ragged-right text

The PlaybookIQ styleguide will also call for ample use of whitespace and large, easy to read fonts.

Tab Based

In LeadsOnRails I avoided tabs in favor of a left-hand navigation column which I liked for speed of navigation. Instead of choosing “Setup” and then “Message Templates”, for example; people can simply click “Message Templates”.

I’ve since seen the light and my new products such as PlaybookIQ have tab-based navigation. I like tabs for the way they help set a context around each screen.

Persistent Search Box

PlaybookIQ is all about ready access to information about contacts and opportunities so most of the time people will see a “Search” box somewhere on the screen. I’ll need to keep that in mind as I sketch the rough layout of each screen and plan for navigation.

Let’s Sketch

That’s about all we need to know in order to sketch each screen and think through how people will use the application. And guess what – that’s what we’ll do next.

Making of a Web App: Choose a Name, Part 1

In this, the sixth entry in the Making of a Web App series, we take a look at choosing a name. There are two steps: pick criteria and then pick a name that meets those criteria. In this entry we look at the first step: what makes a good web application name. Key points:

• Descriptive names are a wasted opportunity to be different and memorable.
• Emotive names rock.
• The first choice of name probably will not work, because:
• you need the .com.
• A chance to verbally repeat the name to someone is ok.

Everyone will have their own criteria for what makes a good web app name, depending on industry, target audience, and personal preferences. Here are the criteria I used for Synap Software’s sales process app.

A good web application product name is:

• short
• available as a .com
• associative
• emotive
• unique
• not functionally descriptive
• memorable
• ok to repeat
• one that you like and like to say

Let’s look at each of these criteria in more detail.

Short

One or two syllables is best, and three is ok. A shorter name is easier to remember, harder to misspell, and less likely to be mistyped into a web browser.

The WebWare100 is CNET’S “user-generated awards program for Web 2.0 sites and services”. In other words, it’s a popularity contest for web apps. I don’t know if a web application’s name contributes to it’s success, but let’s take a look anyway. Excepting those apps with billion-dollar brand names (Google, Microsoft, Yahoo); most names are two syllables, some are three and very few have more than three.

Available as a .com

There will be times when the application name is given in print or verbally, yet the url is not. Or, if the url is given, people will forget what it was and only remember the product name. Now, in these days of search-based navigation, users will eventually find the application’s url. But why make them go through that step?

Campfire at campfirenow.com and other 37signals apps show that an application can be successful without owning appname.com. But there is no reason to have the url be different than the product name. There is no name good enough to warrant it.

A final note on this topic: .net, .biz, .org are also not recommended because it is the habit of many to simply type or assume .com for the site name.

Associative

Associative means that the name and the application make sense together. The name is not descriptive, yet when taken in context the name makes sense to users. An associative name reinforces the application’s purpose and makes it easier to remember.

Be careful with this one though. Associations differ. For instance, an expensive naming firm picked “landslide” for the name of a sales force application. To them it meant “landslide victory”. To me, living in Colorado, landslides destroy homes, cars, roads, and trails when giant boulders come roaring down the mountainside.

Emotive

Similarly, an emotive name gives a hint as to how users should feel about the application. The name helps set user experience expectations and should match the actual user experience.

Unique

We are in a search-driven world now. People use search for everything, including navigating around the web – even to places they’ve been before and even if they know they url.

I like product names that, when typed into Google, return zero results (prior to your picking the name, of course).

When people search for you online, why have the possibility of your potential customers getting sidetracked by something else. A non-unique name like “Clear View Accounting” leaves searchers sorting through listings for accountants when they search the web for your tax accounting software. A unique name prevents this.

Not Functionally Descriptive

Similarly, a name that describes your applications functions only invites people to happen upon your competition on the way to see you. Also, in using a descriptive name you lose the chance to leverage the other purposes of a good name.

In an earlier article I said competition is a good thing. And it is. Yet there is no reason to make it easy on them. A non-descriptive name means they will not happen upon “Better Accounting” when looking for you at “Best Accounting”.

The product name will rarely be used out of something that gives it descriptive context. Let the context that it came up in be the descriptive component. Use the two or three syllables you have for a name do the work of making the product different and memorable.

Some people like descriptive names as a way to improve search result hits. For example, if I produce accounting software, wouldn’t it be great if Google searches for “accounting software” brought everyone to my product – AccoutingSoftware.com? Well, the truth is:

it doesn’t work that way.

AccountingSoftware.com does not show up in the top 100 results for “accounting software”. Same with “lead management”, “lawn service”, “candy shop” or many other descriptive searches. For most product descriptions, a product named after the category does not show up in the first page of Google results.

Again, drive search traffic to the site by other methods and let the product name do identity work for which it is ideally suited.

Memorable

The most memorable names are short, distintive, and emotive. So a name that meets the other criteria – it turns out – is more likely to be remembered by your target market.

It’s OK to Repeat Yourself

I love to verbally repeat my product names any chance I get. Why not? A name that bears repeating for clarification (not for initial understanding) gives you an excuse to repeat it. Here are two verbal scenarios:

“Visit us at blueday.com. That’s blueday.com”. or,

“Visit us at igetit.com. That’s the letter i, getit.com”.

The second statement gives you a chance to repeat the name without sounding like you are simply drilling it into folks. It also helps people remember the name because they are building a mental image of the word, not just hearing it repeated.

One that you like and like to say

You’ll be repeating the product name all day, every day. So even if a name seems textbook perfect, but you just cringe for some unknown reason when you hear it or say it – then it’s not the right name. It just has to feel right.

Next

Now that we have decided on criteria for a good web application name, let’s find one. Picking a name that meets these criteria is the topic of the next article.

Software Design: Grant Peace of Mind

I understand about indecision

But I don’t care if I get behind

People living in competition

All I want is to have my peace of mind

- “Peace of Mind”, Boston

Avoid Indecision, Grant Peace of Mind

If you are a software designer, your goal should be to have every page have one purpose. This way you minimize user indecision, you find that the application is easier to explain, and by going through the excercise of this constraint you gain more confidence that your design achieves the primary purpose of the app.

Yet in constraining user options and tasks available on any given screen, it is easy to get concerned about falling behind the competition. You think someone is going to look at a competitor’s screenshot and say “Wow – look at everything you can do from here. This is power! I want that power!”

Yet the problem with falling into that trap is that users usually find out what they really want is peace of mind. They want to know that they are doing the “right thing” and that the application is doing what they expect. There are a couple great ways to grant the peace of mind to software users. (With apologies to Boston for twisting their words to fit this scenario).

Where am I? – Street Signs and Breadcrumbs

Though Steve Krug points out that his book “Don’t Make Me Think, a Common Sense Approach to Web Usability, ” does not discuss web applications, most of his approach is relevant to web apps.

One important feature to usability is what Krug calls “Street signs and breadcrumbs”. These features give browsers, and web-app users, something to hold onto – something to not feel lost in their virtual visit. There are several ways to implement street signs and breadcrumbs such as ensuring that in a tab-based navigation the “current tab” is highlighted.

What am I Doing Here?

Yet with web applications we take that a step further and make sure users of Synap Software applications know not only where they are but also why they are here. Both a ‘you are here’ and ‘you are doing x’ signs are needed. For example, with the lead management software, LeadsOnRails, most screens reinforce to the user their reason for being on that screen. When they click “New Track”, the new track page appears and the blue-bar heading changes to “Create New Track”.

Some designers might say that this is wasted space – that users know why they went to a screen and it only causes more reading to have to see “Create New Track”. On the contrary, such notices act as reinforcement to the user that they are, in fact, using the application the “right way”. It helps users feel comfortable and confident in the application.

Other applications have used the area of a screen typically used for notifications such as “Record Updated”. Wherever it is, web applications should have a persistent section of the screen that continuosly reinforces the purpose of the screen. Don’t just remind users where they are. Remind them of the single activity they are here to perform.

One Screen, One Purpose

When you explicitly label screens, you find that you need to narrow the focus of some screens. And this is a good thing. Designing an application so that each screen has a reason – and one reason – to exist really helps you focus on the core purpose and activities of your application.

Grant Peace of Mind

So, if you are a software designer, give it a try. Don’t overwhelm users with options in an attempt to show off the application’s powerful features. Don’t make them decide – that only causes indecision. Don’t worry about getting behind. Don’t worry about your competition. Customers that need complex software requiring extensive training and support will stick with your competitors and are not the ones you – as a small software company – want anyway.

The customers you want are those that try your competitors and find that they simply do not enjoy using their software, or that it is is too complex, or that too much time is spent trying to explain to their teams what to do next. These are the customers that will come to you – and stay with you – when they see the continuous affirmations they receive from your app.

Design Decisions: Persistent Link to New Lead Screen

The Emergency entrance to our hospital is different than the medical building entrance. As with all hospitals, there is a big red EMERGENCY sign with an arrow directing you past the medical building entrance to the emergency entrance.

What I noticed today (on a scheduled trip to the doctor’s office – not the emergency room!) was that if in your rush to the emergency room you miss the big red EMERGENCY sign and turn anyway into the medical building entrance, there is immediately another big red sign that again directs you to the emergency entrance from the entrance to the main parking lot. And if you somehow miss that one, around the next turn is yet another big red sign pointing the frantic driver to the Emergency entrance. They are everywhere on the campus and around the parking lot.

You Can Always Get There from Here, Quickly

There is a main, direct route to the Emergency room. But even if you get off that route, you can always easily find it – no matter where you are.

Well designed software is the same way.

What is the main purpose of your application? What is the most urgent reason a person will be in your app? Answer that and put that one purpose always only one-click away.

That’s what we did with LeadsOnRails lead management software. Anchored in the top left corner of every single screen in the application is the “Add a Lead” link. This way a LeadsOnRails user never has to say “hold on a second while I access the screen to take your information”. One click – they are there.

What would your big, red, “Emergency” link be?

Placing a persistent, anchored link in an application also reminds users and app designers of the primary purpose of the app. In our case, to capture leads. In the case of a ticketing system, there should be a persistent link to “enter new ticket”. In the case of a mapping application, a consistent and persistent box to enter an address. A purchasing system, a link to “checkout”. If you cannot decide on a persistant one-click link, then perhaps the app is trying to do too much.

What Disney World, Five Man Electric Band, and Good Software Design Have in Common

Post No Signs

It is very tempting to try to influence behavior by posting signs. On the surface it makes sense. If we want someone to do something, simply post a sign that says so. Yet on a recent family trip to Disney World, it struck me that Disney parks have very few signs posted. And for a park that size there are practically no “do not” signs.

Disney evidently knows the same things I do about about signs. First, people ignore them. People just do not take time to really read anything: including signs, error messages, or user manuals. Second: signs, especially “Do not..” signs, make any experience less enjoyable. The signs are not the experience, so by definition they only detract from it. Software developers can learn from this example.

Cut words from software

There are alternatives to extraneous signage. Let’s look at some signs you will not see at Disney parks, the alternatives, and how these alternatives relate to good software design.

”Keep off the grass”

Disney keeps people off the grass by providing walkways wherever folks are likely to want to go and discrete barriers between the walkways and the grass or flowerbeds.

Likewise, well designed software keeps users off the grass by predicting what they will want to do next, offering a clear path to do so, and disabling the ability to go the wrong direction.

“Do not run”

Disney keeps folks from running by offering gentle, positive reminders from park staff. Anytime I tried running to quickly get a Fast Pass, I heard a Disney cast member firmly say “Walk Please”.

Likewise, instead of telling users why they cannot perform a task, good software design shows users how to accomplish the task they are trying to perform. For example, instead of saying “You can’t create that user before creating at least one group”, an app should say “Let’s create a group first, then we’ll create the first user” while directing them to the new group screen.

“No littering”

Disney does not insult you by thinking you need to be told not to run through a crowd of thousands (until you prove them wrong like I did and actually try to run through a crowd of thousands – a large percentage of whom are pushing strollers). Similarly Disney also doesn’t think most people need to be told not to litter. Disney keeps folks from littering by trusting guests’ better judgments and by keeping the parks clean with a huge maintenance staff.

Well designed software is the same. Instead of blaming users when they do something “wrong”, good software design simply cleans up the mess and moves on without major complaint.

“Do not enter”

There are many areas on the Disney parks where guests are not to go. There are many doorways between the magical guest areas and the backstage workings. If you watch, you will see Disney cast members coming and going through these alleyways and low-key breaks in the fence. What you do not see is big “Do Not Enter” signs. Why? Because the entry/exit points for Disney cast members are simply not marked. In fact they do not even look like they go anywhere. By hiding the employee only access points, Disney need not put up “Do not enter” signs.

The best way to prevent someone from doing something is to not even make that “something” an apparent option. For example, instead of responding with an error message like “This customer record cannot be deleted because there are unpaid invoices”, an app should not even show the “delete” button or link for that customer record.

“Do not sit on the sculpture”

Actually, I saw this sign at the St. Louis Art Museum some years ago. It was on a piece of brushed aluminum modern art that had a wide, flat, bench-height surface. This piece was placed in the lobby where people are naturally milling about talking or waiting to meet others in their party. What better place to have a bench! But, this art was no bench and the sign let you know so. I don’t think the artist had envisioned his or her piece so negatively overwhelmed by the “Do Not…” sign. Disney has no such sign because if something looks like a bench, it is a bench.

In good software design: if something looks like a button, it better be a button. If something looks like it should be clicked, dragged, dropped, slid, entered, or pressed; it better respond to a click, drag, drop, slide, enter, or press.

“Do not do back flips from this ledge”

I saw a teenage boy doing back flips off of a ledge and onto the concrete below it. Evidently corkscrew roller coasters and haunted mansions were not excitement enough for him. Sometimes there is just no accounting for teenagers. Disney had nothing in place to predict this behavior or to discourage it. How could they?

And there is certainly no way to predict everything users might try with a computer or with software. So, when something unexpected happens, well designed software simply says so and offers an easy way for users to contact the vendor for help.

Post No Signs

Five Man Electical Band expressed a proper disdain for signs.

Sign Sign everywhere a sign

Blocking out the scenery breaking my mind

Do this, don’t do that, can’t you read the sign

Take a hard look at the software you write and use. Are there unnecessary signs posted around the app that could be torn down and shredded if an alternative design approach were used?