Making of a Web App: Interlude – Importance of a Blog

In Startup Marketing: Big Bang vs. Darwinian Evolution, Dharmesh Shah highlights the importance of getting feedback early in a Darwinian evolution approach compared to the “stealth mode” approach with a big-bang launch. His insights are well stated and recommended reading to show the design and development of a new product should be accompanied by, or even preceded by, a regularly updated blog that reaches your intended audience. I recommend you read it, and if starting a new product, create and regularly update a blog about the product.

Making of a Web App is Synap Software’s blog about our upcoming web-based sales team collaboration app.

Making of a Web App: Part 11 – Technical Interlude

For people with an interest in the technical side of the project, here are notes on the configuration of our development, test, and production environments.

For those who couldn’t care less if PlaybookIQ is powered by mongrels or mice – don’t run away yet. Later this week, I will have the beginnings of actual product on the “production” server where anyone interested can follow along in real-time as updates are made throughout each development day. I would love ongoing feedback from the “live” site. Stay tuned because some real stuff is starting to happen.

Environments and Tools

My environments look like this:

Development and Testing Platform

• MacBook Pro running OS X
• TextMate editor
• Ruby v1.8.6 programming language
• Ruby on Rails v1.2.2 open source web framework
• mySQL open source database
• web-brick web server
• Subversion version control system
• net-ssh for password-less connectivity to remote server
• Dreamweaver and Fireworks for working with html and graphics
• CSSEdit for working with .css
• Capistrano to automate deployment
• a few other little goodies

Remote Host

• VPS slices at Slicehost.com
• Ubuntu Unix
• Rails v1.2.2
• mySQL database
• Apache2 web server
• mongrel cluster as an http load balancer
• svn server for source code control
• trac for project management and source code management

The local environment setup was actually done some time ago. The great news for Mac fans is that when OS X Leopard is released in October you will be able to write and deploy Rails apps “out of the box” with Rails, Mongrel and Capistrano pre-bundled into OS X 10.5. Awesome.

Deprec

Once the local install of Ruby and Rails was complete, the rest was easily configured and deployed using deprec, deployment recipes for Capistrano. I first read through the info from the deprec site, then followed a combination of instructions from here, here, and here and now can easily deploy updates using these few commands and without manually logging into the server.

svn commit -m 'new update'
cap disable_web
cap deploy_with_migrations
cap enable_web

Anyone running Rails on Slicehost, drop me a line and I can send you the step-by-step details of what worked for me to get the complete stack setup with deprec.

SSL

All PlaybookIQ users will have SSL, so I wanted to get that built out from the start so that all code would handle it properly. While the setup of all other components was straightforward thanks to deprec, configuring Apache, mongrel, and the Rails app to use SSL took way too much time. The key to anyone looking to use SSL with Apache is to understand VirtualHosts. More details on the exact steps I took to deploy SSL on Rails and Apache will be in a future post.

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 9 – Why I Hope No One Reads My Use Cases

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 why, despite best attempts by the anti-paperwork crowd, I like written use cases.

Use cases:

• Contribute directly to the final, deployed app.
• Expose risks to simplicity.
• Expose the level of development work required.
• Are the easiest way to iterate, collaborate and communicate.

Use Cases

Briefly put: a use case can be anything that documents how a person will accomplish a task with your application and how the application will respond. In this article I use the term to mean written use cases (as opposed to diagrams or sketches).

Click here for an example.

Some developers do not write use cases because doing so feels too much like writing documentation and documentation is not the purpose of building a system. So, in an effort to work only on things that directly contribute to building the app, people skip over the use case step and jump right to visual design or sketches (or even just start hacking out code). I have to say that back in my developer-only days, I was that way too. I saw anything but code as wasted time. Now, I don’t. Here are four reasons why I don’t skip the use case step.

1. Use cases contribute directly to the final, deployed app.

Use cases become user documentation (aka help files).

If done right, use cases are not thrown away work that gets shelved after the project is complete. There is at least one part of the final delivered app to which use cases contribute directly. There is a part that is often forgotten or saved until the very end and done as time allows. It’s the part of an app that I hope no one ever uses. It’s documentation and help files.

Typically, a development effort completes and then everyone scrambles around trying to figure out how the documentation is going to get written. Just like writing test cases first, writing the use cases first is good practice.

Unlike test cases though, use cases in the form of help files are, honestly, something that I hope people don’t read. If people are referring to the help files, that means the design is not clear. If people stop their work and have to look up what to do next in a help file; then the design does not communicate the intention of each screen and button clearly enough.

So here we are; even though I hope people do not read it, people still expect documentation and documentation ups the level of professionalism in an application. How to solve this dilemma? By writing use cases from the perspective of people using the app. This way I can use them as both a design tool and part of the delivered app.

Here’s an example. Instead of writing:

1. User selects the playbook dropdown.
2. User selects a playbook.
3. User clicks ‘Save’.
4. Milestones are copied from the playbook template to the opportunity.
5. Tasks are copied from the playbook template to the opportunity.
6. A history record is created with date, time, and username of the current User.

I wrote:

When you select a playbook in the Playbook field and save the opportunity, a few things happen:

1. Milestones and tasks are copied from the playbook into the opportunity.
2. A history record is created recording the date, time, and current username.
3. Any milestones and tasks assigned from previous playbooks are not affected and remain unchanged.

For fans of agile development or Getting Real methods, this seems dangerously close to written documentation. Yet, as I said before, people will expect some form of documentation anyway and using this method ensures we are not running around after the fact trying to figure out how documentation is going to get written.

2. Use cases expose risks to simplicity

In moving from conceptual to concrete, the devils in the details come out.

PlaybookIQ is a great example of the ability of use cases to expose complexity from its favorite hiding spots. At the conceptual and task-flow level, the relationship between contacts, opportunities and playbooks seems quite simple.

• A contact is a person.
• An opportunity is a chance to provide products or services to one or more contacts.
• And a playbook is a series of best-practices to follow when pursuing an opportunity.

Simple.

Except it’s not. It was not until trying to write down the relationships between contacts, opportunities, and playbooks that the complexity was revealed. I won’t go through the details here because this series is not about the app, but rather the process and experience. The short version is that writing use-cases exposed a decision that needed to be made. I found I need to decide: is a playbook applied only to opportunities, only to contacts, or to opportunities and contacts. (If you have thoughts on this decision – let me know because I am still working it out.) Drawing the three with arrows between them all makes it look simple. Writing use cases describing the interactions shows there are more questions that need answered.

3. Use cases expose the level of development work required

One screen is not like another.

If I find myself dreading another sentence when writing the short use cases, I know I will have an even worse time being motivated to write the code. (And an unmotivated coder is one of the worst risks to a project ever. Studies have shown that motivation has a larger impact to programmer productivity – both positive and negative – than any other factor.) A screen sketch just does not capture the depth of interaction and decision-making that an application will be asked to perform. By better understanding the scope and level-of-effort a feature will take, I can better plan the project and make smarter decisions on what should be cut.

Why not just write code now then? It is easier and quicker to change words than it is code, and it is easier to communicate to other stakeholders in words than in code. That’s why.

4. At this stage in the project, use cases are the easiest way to iterate, collaborate and communicate.

Everyone can read, understand, and edit a text document.

ConceptShare is a popular online design collaboration tool, and paper and pencil work well for teams working in the same room. The tools are there, yet people are still more familiar with editing text documents than they are with editing others’ drawings. Some people communicate and learn better with visuals, some with words (and some are audible learners – but no one I know is a “scent learner”, go figure). So while there are visual communication tools out there, they are better put to use when the visual crowd gets their chance later on in the project.

Communicate: Use cases communicate much more than just what screens and fields are required and how they will interact. Use cases are also a great place to write down definitions of key terms and overall expectations of the application. For example, this is from the use case for PlaybookIQ opportunities:

An opportunity is a chance to provide products or services to one or more contacts.

Where would someone put that in a screen sketch? Short descriptions like these help ensure the development team and clients are on the same page and, as mentioned earlier, this same document becomes help material. As final bonus, this document can also be marketing material or at least information that goes on a product site.

Back to Reality

Now, back to reality. I cannot write all day without visual representation is being written about. So, in reality, I sketched up some rough task-flow diagrams and then iterate between use cases and task-flow diagrams.

I draw with pencil on 5” x 8” index cards, then spread those out on the desk, floor, or white-board to visualize the relationship between each major component. Each iteration aims to simplify and clarify how tasks will be accomplished. Because it’s not in soft copy, I need to take some pictures to show what that looks like and will discuss them in a later post.

Enough of this evil documentation work already.

I hope you can see that written use cases are not part of the evil tree-killing conspiracy, but are a useful communication tool that also becomes part of the finished product. And to clarify, like all entries in this series, I cannot tell you how to build your web-app. I don’t know your technical, environmental, or political situation. I’m just sharing what I do. That’s why it’s called “Making of a Web App” and not “How To Make a Web App”. Either way, I know most of us will be glad to move onto something a little more visual and closer to what people think of as the application: screen sketches.

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 2 – Update

Making of a Web App follows the design, development and deployment of a web application. This is the seventh article in the series. In this entry we pick a name for Synap Software’s new sales team collaboration application. Here’s the steps we followed:

• Wrote down the categories, benefits, and differences that describe the app.
• Used thesaurus.com to find words relating to these categories, benefits, and differences.
• Found word combinations that made sense, sounded right, and met all our name search criteria.
• Picked a few favorites and experimented (i.e. played around) with them.
• Picked a name, slept on it. Woke up and still liked it.
• Now we are sharing it for feedback.

Final Two Candidates

It came down to zPlaybook or PlaybookIQ. This blog entry shows how we arrived at those names. I’ll write more details on the in-progress logo development, but for now here is a sneak-peek.

Thanks to Michael McDerment

How to Name Your Company was the basis for our thorough product name selection method. We used different selection criteria, but similar methodology to that presented by Michael.

1. Reviewed the Criteria

In the previous Synap Software Blog article we outlined our criteria for choosing product name. That turned out to be the easy part.

2. Reviewed the Application

Next, we wrote down basic information and selling points about our sales team process application.

3. Discovered Applicable Words

Then, using thesaurus.com, we searched for appealing words related to the application’s concepts. Now we had a list of candidate words for the product name.

Our finished worksheet shows what this looked like.

Yes, some of these words are descriptive even though one of our criteria is to avoid a purely functionally descriptive name. In combining words we hope to create a name that is more than simply functionaly descriptive.

4. Combined Words

Next, we simply started combining words from the word lists, looking for combinations that made sense and matched all of our criteria. Not surprisingly, I quickly found that most of the word combinations we liked did not have .com available. So, we decided to move forward to choose a two syllable name regardless of .com availability. Then, the strategy was, we would use a third syllable to make the name unique and the .com available.

5. Picked a Favorite Combination Anyway

This is where the rigorous process started to fade and the creative, free association activities kicked in. After going through several rounds of combining words, we picked a favorite pair that individually worked well and happened to also combine into a meaningful word.

With the .com taken and in very active use, we looked at adding to the front or back of the name. We considered adding “iq” to the end or “sales” to the front of the name. I considered adding “e” or “i” to the front of the name, but the resulting .com was taken and in active use (no chance they would sell to us). In the end, I added “z” to the front of our original choosen name and here it is:

6. Added Flair to Make Unique and .com-able

Introducing “zPlaybook”. I like the name because:

• It meets all name selection criteria.
• “Play” gives a hint of a positive user experience.
• “Book” demonstrates roots in building your (book of) business.
• A “playbook” shows team members the big picture of each play as well as each individual’s responsiblities.
• Extensible: e.g. A playbook is situational. Our reports could be called “scorecards”. Common use of “team”.
• I like the shape “z” makes in reference to a starting point, a path, and an ending point. Fits nicely with our sales process software.
• “z” makes it unique. Before today there are zero Google results on “zPlaybook” (and 2.4 million on “playbook”).

UPDATE:

Upon further review, we have another favorite. The likely name is now: PlaybookIQ.com. The “IQ” suffix seems a bit more professional than the “z” prefix. Also, the “intelligence” component of “IQ” ties nicely into our company name, Synap Software – Smart Software Fast.

And finally, the “IQ” after Playbook indicates something follows the playbook. There is a result – specifically “intelligence” – that derives from using the playbook. Specifically – sales managers will be able to gather “intelligence” about their sales information from PlaybookIQ.

What do you think?

A Sidebar of Spontaneous Publicity

The new phone book’s here! The new phone book’s here!

Boy, I wish I could get that excited about nothing.

Nothing? Are you kidding? Page 73 – Johnson, Navin R.! I’m somebody now! Millions of people look at this book everyday! This is the kind of spontaneous publicity – your name in print – that makes people. Things are going to start happening to me now. source

Now that we have our name in print and ready for public scrutiny, let us know what you think of it by sharing a comment below.

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.

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.

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.

Making of a Web App: Sales Team Collaboration Software

It’s difficult to talk about web application design in this Making of a Web App series without first describing the application. Other designers have hidden their plans while sharing their process by offering vague design decisions and small, blurry screenshots. The results are less than satisfactory so in this series we’ll share the details of the actual application. Here it is: in Making of a Web app, we are building sales team collaboration software. Here is some context as to why.

1. I have a need for making the most of sales opportunities. This means I can be my own use-case and user which comes in handy when making user-driven design decisions.

2. Others have a need for simple sales team collaboration software. According to an Aberdeen research study, fifty-nine (59) percent of respondents indicated that developing a well defined sales lifecycle is their number one priority. Users I have talked with have tried other lifecycle products and found them too complex, making them too difficult to explain or start using.

3. It’s what I know. I can leverage years of marketing and sales support experience to design a great product. And again, I can make quick design decisions without constantly consulting back to experts. Finally, we can leverage lessons learned from LeadsOnRails. Whether this new application is LeadsOnRails v2.0 or is a seperate app has not yet been decided.

Isn’t the Market Crowded?

There are dozens or hundreds or CRM, sales, lead management, etc. apps out there. Without going into the full business case here I can summarize our difference in one word: simplicity.

Most users simply want to see the big picture while also understanding the specific task they need to complete next. The big picture helps members of sales teams collaborate with one another. The focus on the next task to complete helps ensure business gets done.

Isn’t the ‘Simplicity’ Market Crowded?

There are dozens of applications that claim simplicity. Yet many of those do so by leaving out features that are important to sales teams. We aim to retain simplicity without moving toward generality.

Simplicity Starts with Focus

To design an application with a focus on simplicity, it is important to understand the single activity the application is meant to support. “Sales team collaboration” is the activity that this app will support. There will be lots of tasks that an application can perform. Yet each one of those tasks should be in support of the one activity – “sales team collaboration”.

But What Exactly Does it Do?

Now that we have a high level idea of the application and have narrowed the purpose of our application down to a single phrase, it’s time to determine the simplest set of features required. Let’s get to know our users better first though. That is the subject of the next blog entry.