Making of a Web App: Write User Stories

Cordell:

People don’t use a computer to enjoy the operating system; they don’t care about setting their system preferences, nor do they care about choosing what kind of scrollbars they want. They use a computer because they want to create something; they want to communicate with somebody; they want to express their own personality, everything from writing a novel to balancing their checkbook – some more fun than others, but it’s all about accomplishing something that really doesn’t have anything to do wtih using a computer. The computer is just a tool.

As interaction designers, we need to remember that it is not about the interface. It’s about what people want to do! To come up with great designs, you need to know who these people are and what they are really trying to accomplish.

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.

4 Reasons To Simplify

Here is my kids’ school’s mission statement.

Acres Green Elementary provides a positive safe environment where best teaching practices are used to educate the whole child while honoring individuality and creativity.

Here’s another area school’s mission statement.

Copper Mesa Elementary is dedicated to excellence in education and is committed to being an exemplary community of learners. Every child is worthy of a positive, successful learning experience. Our dedication is to create a child-centered environment that encourages risk taking, embraces diversity, and validates the whole child. To promote educational excellence, we will share in the responsibility to foster curiosity and a love of learning. We will model, encourage, and inspire all learners to explore the possibilities of the world around them. Guiding students to reach their personal best, we will provide positive, supportive, challenging, differentiated opportunities for students to demonstrate understanding. We are committed to recognize, value, appreciate, and take pride by celebrating the achievements of all. As a community of learners, leaders, and partners, we are united in our goal to enrich the lives of each child, as he or she becomes a life long learner seeking to reach their fullest potential.

huh?

This post is not about mission statements, but about simplicity. Specifically, simplification by reduction. Here are four things we can learn by comparing these two mission statements.

Simplify to Reach Your Audience.

Raise your hand if you read the Acre’s Green mission statement? I see most hands up. Now let’s see the hands of those that read the other mission statement. Not many hands up now I see.

Simplify to Be Believed

A simplified approach does not pretend to be everything to everyone so the message seems more honest, geniune, and relevant to those that it is meant to address.

Simplify to Demonstrate That You Value Your Audience

When you simplify by sticking to a core message, you do the work for your audience – whether that audience is reading your writing, listening to you speak, or using one of your software applications. When you throw everything on the table, you make your audience sort through to figure out what it important. And they probably just won’t do it. Or if they do they will not have a great experience that keeps them coming back.

Acres Green put more work into really thinking about what is important to them and how to communicate that as succinctly as possible. The other school’s mission statement is a statement by committee.

Simplify to Demonstrate Focus

Whether in mission statements or software design, those that follow a “let’s put in everything we can think of” approach show little understanding of their core mission, product, or audience and are, in effect, asking others to figure it out for them. The “more” approach demonstrates fear – fear of leaving something out. The work it takes to simplify demonstrates focus.

I’ll pick focus over fear any day.

Making of a Web App: Choose a Small Feature List for V1.0

In this, the fifth entry in the Make a Web App series, we build the v1.0 feature list. The key points are:

• Write down a big list of features.
• Cut the list in half.
• Cut the list in half again.
• Version 1.0 will be only this 25% of the big list – these are the essential features.

Also, read on to find out how this approach can help good web application designers exceed user expectations.

How to Choose Features

So far, we have:

• Identified the single activity (sales team collaboration) the application is designed to support.
• Described the users’ roles, responsibilities, and needs.
• Helped set expectations and focus
  by describing a related activity it will not support

Now we’ll build our version 1.0 feature list.

First, Include The Kitchen Sink

I’m a fan of brainstorming. All ideas in brainstorming sessions are captured. Assessment of ideas happens after the brainstorming sessions. This process brings about useful ideas because it keeps thoughts flowing. Instead of stopping a creative impulse because of a “bad” idea along the way, brainstorming sessions allow the best ideas to evolve.

Use the brainstorming approach for the first take at a feature list. Ask “what features would someone like to have in this type of software?” After a short while you will have easily captured pages full of nice-to-have features. Yet most will never see the light of code. At least not in the first version of the application.

Even though you will tuck it away somewhere, it is important to keep a record of the entire feature list in order to

• Boost creative thinking, and
• Provide a platform for the first step toward simplification: reduction.

Then, Reduce

Reduce
is John Maeda’s first law of simplicity.

”The simplest way to achieve simplicity is through thoughtful reduction.”, he says.

“Thoughtful” is the key word there. It’s easy to throw features off the list. It is difficult to thoughtfully determine what to through off the list. Determining what to reduce is as much art as science. This is where domain experience becomes valuable. This is another reason to build what you know or to “scratch your own itch”.

It’s probably a misnomer to entitle this article “How to Decide What Features to Include”. Every situation is different. What makes sense in one app, would not be a good decision in another. The actual decisions have to be made by those with domain knowledge in the app.This article provides a framework within which to make those decisions.

Start With the Big List

Pick up a copy of Designing the Obvious, A Common Sense Approach to Web Application Design and jump to Chapter 3:Build only what is absolutely necessary. That is the approach we’re taking here and this is what it looks like.

Let’s call the brainstormed list of features the big old everything we could think of list – or the big list for short.

Here’s the Big List

Here is a readable “big list”.

This is actually a short big list. These lists grow by the minute. Yet the most essential features probably found their way onto the big list early. So don’t spend forever on this thing. It should be relatively quick.

Reduce to Essentials

Now, go through each item one by one asking:

• If this feature were not in the application, would the application still function and still support the single activity it is meant to support?

If the answer is “yes – without this feature the app would still function and still support the activity”, then strike it off the list. Here is where we need to be ruthless. Remember that additional features can, and will, be added later. Remember that “simplicity” is a key feature of this application and one of the easiest ways to simplicity is by thoughtful reduction. Remember that too many options thrown at new users at one time makes for a frustrated user and a poor user experience. Continue removing items until the list is down to at most half its original size and ideally 25% of its original size.

There are other questions you might ask to qualify a feature for the short list:

• Is this feature self-evident or is it difficult to explain? If it takes an explanation, it probably is not a good feature for version 1.0. You’ll be busy enough rolling out the app to keep you from promptly and adequately answering questions about advanced features. Also, the first time the world sees your application, it is more important that the application meets the expectations of those that use it than it is that you have thousands of users attracted to a long feature list. Said another way, it’s important that the first impression leaves no head scratching.

• Does this feature give the app the personality we want it to have? We’ll talk about an application’s personality in a later article.

The Big List with Non Essential Struck Out

What you are left with is the feature list for version 1 of the application.

The Essential List

Here is our sales team collaboration software “essential” list.

Everyone Loves Upgrades!

It’s literally human nature - to want more, not less. So looking at our short little list, it’s easy to become discouraged at this point and say “that’s all?”. Yet remember that by constraining ourselves to less initially, we get a quality product, released earlier, and are more likely to offer a good customer experience. We also create an opportunity to over deliver by following up with enhancements.

Items on the big list that did not make the essential list become instant candidates for enhancements. In determining the release 1.0 feature list, you have also started to build an enhancement path. Shortly after launch, go ahead and add in that one feature that was most difficult for users to let go of. With a successful initial launch followed by a surprise improvement, you’ll instantly be a hero.

Additional Criteria

Don’t implement the feature set of your competition is good advice from Ian Landsman. The big list should be built from your understanding of the users’ needs, not from your competitor’s feature list. Just because a competitor has a feature does not mean it provides value – in fact users may not like or even use the feature – you have no way to know so just avoid it all together.

Other criteria for feature selection might include:

• What are your strengths?
• What can you most quickly deliver?

I like the “essential” test and it has gotten us to this point. We now have our version 1.0 shortlist.

Next

As we move forward let’s give our app some personality and an identity by giving it a name. That’s just what we’ll do in the next entry.

Click here to read the next Making of a Web App entry.

Safari on Windows

Apple announced a Windows version of their web browser, Safari beta version 3. Apple continues to blur the line between “PC” and “Mac”, giving those that prefer or are required to use PCs an option to experience Apple software. Safari has only about 5% of the browser market, but with Safari on Windows that share is sure to grow. Here in Apple’s words are some reasons to switch. Another reason: if you are thinking of getting an iPhone, Safari is built in, giving you a seamless experience between using an app on the phone and on your laptop (as long as your phone is “on the web”).

Making of a Web App: Choose a Font

Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. This is the eight article in the series. In this article we get a little bit ahead of ourselves and talk about choosing fonts. Key points:

• Fonts reinforce an application’s personality.
• Fonts reinforce the attributes of an application.
• PlaybookIQ’s personality is “friendly” and its primary attribute is “simple”.
• The Swiss Style fits perfectly.

People dedictate careers to the study and development of fonts and font styles. This entry is not a study of fonts, but a quick entry about general font choices for PlaybookIQ.

First, Understand the App

Refer to the “personality” you desire for the application, as well as the attributes of the application you wish to reinforce.

Simplicity

For “simplicity” there is no better place to look than the International Typographic Style, also known as the Swiss Style. Developed in Switzerland in the 1950s, this style is known for a clean, simple, and easy look. Features include:

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

By trial-and-error we have choosen Century Gothic and Geneva for the primary fonts. Combined with a grid layout and left-justified text, this makes for a clean look that lets users know they should expect an easy experience.

Here are some other tips for choosing a font for a web application.

Corporate

Fun, Youthful

Want more than ‘because it looks good?’

Take a look at Michael Bierut’s article on deeper aspects to consider when choosing a font. One of these “Thirteen Ways of Looking at a Typeface” may appeal to you.

How to Choose Colors

Blue

Blue means stability and history. Blue means everything is ok. Think of terms like “blue chip”, “blue blood”, “blue shield”, police cars, and what color is the first place ribon – blue! (I’m not sure about “code blue”…let’s forget about that one for a moment.)

Green

Green means action and growth. Something expected happened and you can move onto your next task. Think of ‘green light’ and ‘green grass’.

Red

Red means stop – something unexpected happened.

Yellow

Yellow means help. Yellow does not indicate any activity or action like green does, and does not mean stop like red. Yellow is informative feedback that provides background and help information, not directives.

Grey

Grey is used for information that need not stand out, but provides some value. Typically used for informative or instructive text that does not often change.

Black

Don’t Write Specifications, Do Write Help Files

You have to write help files anyway, so as you are designing the application, write definitions of key terms in html that can become your help file. Write descriptions of how the application works (aka use cases) in html that can become part of your help file.

Process

”The notion of drawing as the core skill within Fine Art has been the subject of a challenging and contentious debate within recent years in education. The commercial galleries have never promoted drawing as a significant activity, and sometimes artists themselves have contributed to the mystification of the subject, collaborating with markets and the media which place a high value on the ‘immaculate conception’ of art works, which means that intermediate stages in the conception process are hardly ever seen, only the finished piece. … This..gives a false view of what really happens in the studios of artists around the globe.” – Complete Art Foundation Course

Though software is not art (or is it?), “Process” should not be a dirty word. Designers and developers should own up to intermediate work that it takes to design a great web application. Regardless of what the tool vendors and framework proponents would have you think, making a great web app requires as much work as ever. It’s just that now that work can be put into the more creative aspects of design. And that means it will not always be right the first time, even if it looks to be so. Picasso had no fear, in this regard. Do you?

[Though I’m no Picasso, I hope our Making of a Web App series, which shows one way how to make a web app, removes some ‘mystification of the subject’.]

Making of a Web App: Set Expectations

This is the fourth entry in the Making of a Web App series. Key points are:

• Use user profiles to reinforce understanding of the single activity release 1.0 is meant to support.
• Maintain focus and set expectations by distinguishing the activity the app supports from another closely-related, yet different, activity.

Ask a Project Manager about their greatest challenges and “scope creep” is sure to top the list. It’s easy to mentally expand scope to add that “one more thing”. Yet after “one more thing” is added another “just one more thing” comes up. This cycle can continue indefinately and v1.0 never arrives or arrives “late and over budget”. There are many techniques to keep this phrase from applying to your project. One is to state early what the project will not be.

A Closely Related Activity

Now, of course you cannot state everything the project will not be. The project will not be: a fashion faux-pas fixer, a pet pamperer, a widget waxer…you get the point. Instead, pick one closely related yet clearly different activity. For example, if “invoicing” is the primary activity the application is meant to support, you might agree that estimating will not be part of version 1.0. You might write that “inventory management” is not part of the new “shipping” application. That “customer care” is different than “billing”.

Maybe the related activity will be added later. Maybe it never will. The point is that you want an application early that supports the single activity it is meant to support. And though there may be obvious integration points and features for v.2.0, v1.0 of the app should provide value standing alone.

Relationship Building vs. Campaign Management

For the Making of a Web App subject application, I’ve defined what v1.0 will not be by comparing it to campaign management. Our app is a relationship builder. It is not a compaign management tool.

Campaign management (CM) tools take a “top-down” look from the perspective of the campaign. CM efforts identify a product or service that an organization wants to publicize and attract customer to. A CM effort then develops offers that promote the product or service and builds large lists of prospects that are most likely to respond to such offers. CM tools are more about the campaign and less about the contact.

Instead, users of v1.0 of this app look at building a customer base from the contact perspective. This app flips the campaign management funnel on its head. Instead of pouring contacts into a campaign, users pour campaign steps and milestones onto a contact. Each contact is a potential opportunity. Each contact should follow similar treatment, yet will have their own time schedules and differing flavors of relationships.

Another Foundation Builder

Like user profiles, this exercise provides a basis for making scope and design decisions. Now that we are armed with this information, determining the feature list of the application will be the next step.