Dumb way to do requirements gathering : So uhm, what do you want?
Effective way to do requirements gathering : Tell me what you’re trying to accomplish.

Key Devices

While requirements gathering, I always like to utilize devices such as Personas and User Stories. They can be a tremendous help in helping you decide on the overall feature-set of your products.

Personas

When building out your product, you need to come to terms with the fact that no matter how much time you spend and how much coding you do, you will never build a product that solves everyone’s problems and meets every single scenario. With that in mind, you need to narrow your focus to key people and make sure you do a brilliant job in meeting their needs.

Personas are “a technique for capturing the important learnings from interviewing users and customers, and identifying and understanding the different types of people that will be using your product. The persona is an archetype description of an imaginary but very plausible user that personifies these traits – especially their behaviors, attitudes, and goals.”

Depending on the size of your product, you don’t necessarily have to write out a detailed persona, but at the very least, always keeping the persona’s goals, attitudes and behaviors in mind will lead to a better product.

User Stories

User stories are essentially requirements written out in the everyday language of the user to non-technically describe a specific process.

User stories are most effective when they are broken up into chunks and focus on specific parts of a product instead of the product as a whole.

The stories should be written after you first Q&A session with the user.

It serves two specific purposes: 1. To help convert your notes to an actual document 2. To take back to the user for review and to find things that you may have missed.

With a recent product I worked on, after talking to several people, I wrote out a user story on a particular workflow all of them did. Not surprisingly, after showing the User Story to the people I talked to, we were able to find a few more requirements that were critical to the process that they had forgotten to mention in our earlier conversations.

Principles

Armed with your new found devices, here are some principles that you should follow to effectively gather requirements.

Know the difference between the user and the customer.

The business owners that approve the shiny project are usually the customers. However, a devastating mistake is the tendency to confuse them as the user. The customer is usually the person that recognizes the need for your product, but the user is the person that will actually be using the solution (and will most likely complain later about a requirement your product did not meet).

Go to more than one person

Because we’re all human, and we tend to not remember every excruciating detail. You increase your likelihood of finding missed requirements as you talk to more people and cross-check.

Avoid specials

When a user asks for something very specific, be wary. Always question the biases and see if this will really make your product better.

Prototype

Don’t wait till launch to show what you have to the user. Do frequent prototypes (you can even call them beta versions) and get constant feedback throughout the development process. You’ll probably find more requirements as you do this.

What is a Location Based Service (LBS)?

According to the Wikipedia article on LBS:

A location-based service (LBS) is an information and entertainment service, accessible with mobile devices through the mobile network and utilizing the ability to make use of the geographical position of the mobile device.

In other words, it is what an address book should have been since day one. A typical LBS service today will show you where your friends are on a map, along with a one-liner describing what they’re up to.

The biggest problem with LBSs

LBSs today are facing an identity crisis: They don’t quite know what the right combination of services should be to achieve a profitable business model.

Since all of them are subject to the network effect, no service has truly gained traction by meeting the common needs of a large base of users.

Instead of identifying this as a truly different experience that solves a real-time problem, most LBS services have instead jumped onto the Social Networking bandwagon, touting as me-too services, except with location, except on your mobile phone. This is dumb.

LBSs are not stepping up and providing the users a brand new experience. They are trying to fit themselves into the mold of existing social networking paradigms.

My ideal LBS

Alright, enough complaining. I think the core features that are important in an LBS app already exist out, however it is the extra crap that get in the way that really bother me.

If I were to create my own LBS app, here is how I would design it.

Top Use Cases

1. Post my location
2. See where my friends are, and what they are doing
3. Find places near me
4. Coordinate a meet up

Navigation

By the way, I am a huge fan of paper prototypes, so I will be using some sketches to illustrate my points.

Confusing navigation is one of my biggest gripes with existing LBS apps. Cutesy tab labels like “What’s Up?!” and annoying navigation that go three levels deep make these apps very difficult to use.

No matter what I am doing in my ideal LBS app, it falls under three high-level categories:

Me — Post my location, Post a picture, Update my status, etc.

My Friends — See where my friends are, and what they are doing

A Place — Find places nearby, and once I do, contextually schedule a meet up.

My LBS app will only have 3 “tabs.”

Me

This is the “Me” tab. This tab only has one purpose: enable me to tell my friends where I am and what I’m doing.

It shows some basic things: 1. My profile picture 2. My current one-liner “status” 3. My last posted location (on a map) 4. Some indication showing me how long it has been since I have posted my location

The only action that you’ll see in this tab, is “Update Location.”

When you tap Update Location, you’ll get still be in the “Me” tab, but you will be able to update your status. This includes: 1. My current location on a map (this is automatic, thanks to GPS magic) 2. What I am up to (simple text, think Twitter) 3. Attach a picture (from my cameraphone) 4. And a simple checkbox stating “Alert my friends.”

Friends

Onto the “Friends” tab. This is where I find out where my friends are, and what they are up to.

Another gripe I have with today’s LBS apps is that they keep insisting on showing my friends on a map. I find this to be useless for a couple of reasons: 1. That location marker is probably out-dated (i.e. he posted his location 2 hours ago and is no longer at that exact location) 2. The map view limits me to find out about my friends in my proximate location, whereas what I really want is to get an idea of where “all my friends” are regardless of how far or near they may be.

With that in mind, my ideal LBS app would give me a list of my friends ordered by “proximity and freshness.” Proximity meaning the closer they are, the higher up they’ll be on the list. Freshness meaning, the more-recently they’ve updated their location, the higher up they’ll be on the list.

Also, my list also shows me my Friend’s profile picture (or the latest picture from their latest updated), and it even tells me the general location of where they are right now.

Where’s Alok?

We’re still in the “Friends” tab, but I wanted to see more about what Alok is doing in Palo Alto.

So, in my ideal LBS app, when I tap on his name, I get a similar screen as the “Me” tab, showing me details about Alok’s whereabouts and what he’s up to.

In my ideal LBS app, there is also a simple “send message” link which will let me send Alok a SMS right from the app.

You could also imagine adding a “Call” link here as well.

Places

The “Places” tab is where it all comes together. You know where you are, you realize a couple of friends are nearby, why not meet up and grab lunch?

The initial “Places” screen shows you a list of your Favorite Places, and then helps you find other places nearby if you’re looking for something new.

Another powerful idea here are the contextual links. Being able to find a place nearby, and clicking “Call” or “Get Directions.”

I think being able to link across applications to leverage other competencies is going to be a strong trend (especially on the iPhone) in the near future.

This means that my ideal LBS app will not be collecting reviews, but you can imagine my contextual link for “Get Directions” will link to the Google Maps app, or the “Read Reviews” link going to the Yelp app.

Want to meet up?

This is the true value add for LBS apps, but none of them have truly cracked it yet. Once you know people are nearby, and your favorite hangout spot is nearby, the killer feature for the LBS app will be to quickly coordinate a get together.

You can even imagine a feature saying “Hey, 3 of your best friends are nearby, want to meet up at your usual hangout, which is also nearby?”

I purposefully didn’t sketch this one up. I’ll leave it to your imagination, or for the LBS company that offers me a consulting gig to help fix their broken LBS app

This is not a subjective viewpoint that I am presenting here. Just look at the millions of dollars and manpower spent on Support, Training and User Documentation. Those artifacts are direct crutches for bad design, and the smoking gun evidence that the industry as a whole could care less about putting in the upfront cost of building a delightful product.

This article presents some simple principles for Enterprise GUI design that can help craft a better experience for your next application.

Yes, I can empathize with you. Enterprise software is hard. There are a million use cases, a hundred features and a ton of variation from user to user, business to business. How can you possible create an elegant design that caters to all of the various uses?

Follow these simple principles, and while you may not be getting design awards for your Real-Estate application’s design, you will certainly earn the love of your users.

Collect Requirements

First of all, let me just say. I’m a huge follower of the Getting Real movement. Although I think writing detailed requirements documents is a waste of time when it comes to a startup, I think they are absolutely required when it comes to Enterprise Development.

I look at Requirements Documents as a contract. When you are building a tool shed on your own backyard, it becomes a bit silly to put in the upfront time of drawing up a contract with yourself, or creating a detailed project plan, or even setting a line-by-line budget. However, when you are building an actual house, that has dependencies on the city for zoning restrictions, interfaces with the utility company to get power and water, and the phone company to get the Internet, you absolutely need to have a plan and contract in place.

Poor requirements gathering and scoping is probably one of the main reasons why most Enterprise Software fails, but that’s for another article.

So, don’t kid yourself. As the first step of your design process, get some requirements down on paper.

Write down your top 3 use cases

Why 3? From my experience, aiming for 3 forces you to zoom out of the line-by-line details of your requirements and think about your product from the user’s point of view. Thinking about your product in terms of it’s top 3 use cases allows you to craft an actual user experience.

With 3 use cases, you’re not thinking about every action that the user must make and adding a button to it, you’re thinking about why the user is there in the first place; what he or she is trying to accomplish as a whole; and most importantly, you are thinking about how best to help the user achieve that task in the most effective way.

Sketch the experience

This is where you do your first design. It’s really up to you how you do it. This can be a series of paper sketches, a wireframe, or it can be actual prototype. This prototype does not have to go into all of the details of your application, but should focus on the three modes of the application that cater to the three key use cases you identified for your product.

Once you have sketches or prototypes catering to the three high-level use cases, start going through your requirements and sketch out more of the details. At this point, it is OK for you to get into a few details.

Throw it out

Well OK, don’t throw it out, but set it aside. This is where you challenge yourself. Start over. Make it a goal to achieve the same outcome with less.

Less means a simpler flow, fewer UI elements, fewer knobs and levers. The goal of this step is to strip down your UI until it has the bare minimum. Challenge yourself to reduce the amount of data you are showing. When you are down to just the essential pieces of data, you’ve gotten closer to the true user problem that you are trying to solve.

This step also gives you a good opportunity to scope out your product. Do you really need to meet all of the requirements that you’ve written down?

Can your grandma use it?

I always like to picture my Grandma as the user when I am trying to design a product’s interaction.

Now obviously, if I happen to be building out some shiny Real-Estate listing application, I don’t expect my Grandmother to truly understand what is going on; but that is not the spirit of this step. The spirit is once again to challenge yourself. Challenge yourself to think past your own engineering mindset and put your self in the user’s shoes. Don’t just assume that your user will know to right click on Item X and then click on Item Y and then double click on Item Z to do Use Case #4.

The goal is to make it so that your user can intuitively figure out how to do the various tasks in your product without having to rely on manuals, tutorials or user guides.

Divide and conquer

Your user never performs all of the use cases all at once. A majority of the time, your user is in a certain mode. For example, in a Real-Estate application, your user can be in any one of these distinct modes: * Entering or Updating a house listing * Entering or Updating her clients list * Searching for the perfect house listing

It is important for you to be able to split up your application into these sub components. When you do this, you can simplify your UI in a task-oriented manner, and only show the things that are relevant to the task the user is performing.

This may seem like an obvious principle, but I am shocked at the number of applications that try to create one giant multi-function interface that let’s you do everything.

If you successfully identify and segregate your product into separate tasks, you can substantially reduce complexity and visual noise from your application.

How many clicks does it take?

OK, so by now you should have quite a few sketches. You’ve hopefully iterated on it a couple of times, slowly stripping away the excess. You’ve also identified the different modes your application has and have divided them up into sub components.

Once you’ve done all this, you need to gauge how far you’ve really come. The best way that I’ve found to do this is to measure the # of clicks.

Make a list of common tasks (not the high level use cases, but actual tasks). Load up your application (or run through your sketches), and perform each of the tasks that you have identified so far. How many clicks do each of them take? Is it 3? Is it 8? Is it 20?

There is no golden rule as to how many clicks it should take on average, but attempting to reduce the number of clicks it does take to the bare minimum (without returning to a huge multi-function interface), is an important exercise.

Yes, this does take a while.

This is certainly not an easy thing. Then again, neither is writing documentation or tutorials for your software. This sort of exercise certainly takes away from “just code and get it done time,” but it will result in a better product when you are done with it.

Need help following these principles for your product? E-Mail me: hello at tawheedkader.com

After much introspection, I found that while I banged out certain tasks very easily, I consistently kept on putting off certain tough tasks day after day. As I drilled in a little deeper, I really came to face the fact that I was simply scared of taking on some of those tasks.

Doing a project with a team of one is tough. In actual startups with teams, you can usually turn to your partner to talk through certain things that you get stuck on. This does not happen when you are trying to think through problems and pain points in your head, regardless of how good of a problem solver or thinker you are.

Faced with this problem, I came up with an aide to help me think through these tough tasks. The whole idea is to drill down into a task that I’ve been putting off in a systematic manner. Whenever I find something that I’m scared of tackling, I pull up my MacJournal and start writing a journal entry with this template:

What’re you trying to accomplish?
This is where you put a simple one-line sentence describing your intent.

What do you need to accomplish this?
Usually, I write out a list of what needs to be done. Think of these as sub-tasks. Don’t think so much about how these will be done, just focus on what actually needs to be done.

What’s easy to do?
Simple enough right? Take the stuff you need to do, and list out the things that are easy to do. Try not to regurgitate the items on your sub-tasks list, but make it more of a free flowing thought process.

What are the roadblocks?
Start reading through what you’ve written. At this point, it really should be becoming clear in your head why you’ve been putting this task in the first place. But don’t stop now. This is the section where you just start listing out all of your roadblocks, all of the things you’re scared about, all of the things you don’t know (how to do). Again, don’t worry so much about how you’re going to solve these problems; instead, focus on the what the actual roadblocks are and list them out.

What are some possible solutions to each roadblock?
Alright, if you’ve been diligent so far, you should be feeling a lot better about this task now. Hopefully you are already feeling excited about truly understanding this task and at this point your mind is flowing with ways to solve the roadblocks you’ve identified. List them out, don’t worry as much about whether they can actually be executed on, but focus more on possible solutions. You don’t want to go completely out of touch here, so I’d recommnd you list possible solutions in the order of feasibility.

Action Items
This is where it should all come together. You should read over everything you’ve written, digest it, and finally come up with some real action items for yourself to tackle this task for real.

This technique has been working amazingly well for me. I’d love to hear from you if you decide to try it out.

It’s amazing how much can change over the span of a year (different job, different place, different coast) yet how some things can still stay the same. The same passions, still the same good friends and no shortage of good ideas that are probably going to be as popular next year as social aggregators are becoming in 2008.

Last year’s SXSW

The best panels from last year were held by industry mavens who had gone up on stage to show the battle scars they had just incurred from their recently successful startups and businesses. They talked about how they fixed scalability, how they increased clickthroughs, how to improve design and even talked about perfectly executing on your idea as if it were a heist. It was great… and I think that is one of the key things that’s so great about the conference (as opposed to random boring MSFT conferences)… it’s run by humble people that have real concrete experiences from the real world to reflect upon.

This year

This year, certainly felt different. There were definitely a good number of panels held by people who thought they had real battle scars, but really all they had to show was giant pictures of hearts in different shades and blabbing on about how websites should have tactile feedback. And then, there was the Facebook fiaso. I thought Zuck would be the one to screw up trying to quote exactly what his PR team had prepped him. Instead, it turned out the interviewer herself upped him in screwing up and stealing the limelight. Either way, I was smart enough to skip the Zuckerberg interview, but only after being subjected to a million different shades of powerpoint slides showing just Hearts (what? That’s how you get your users to love your products… didn’t you know?).

Next year?

All was not lost. It was still a worthwhile conference in my book, and probably the only conference I’ll go to this year. In fact, I’m pretty much ready to book my tickets for it as soon as they announce SXSW 2009. Here’s why:

Jason Fried’s “10 Things We’ve Learned at 37Signals” was quoted and referenced again and again through the many lunch, dinners and happy hours that I attended. That’s no surprise either right? He perfectly fit the ideal SXSW presenter’s profile: someone with actual battle scars with experience to reflect upon. But what about the humble part? I’d say that was one of the best things about his talk: people accuse Fried and DHH of being arrogant, thinking their principles apply to everything and people are stupid for not following it. On the contrary, Fried, with the utmost humbleness completed each and every one of the ten things by pretty much saying: “this worked for us… it may not apply to you, but we think this is a pretty damn good way to go.” Humbleness. Love it.

Another awesome panel was one held by Bijoy Goswami of Bootstrap Austin: “Bootstrapping 101.” I went into the panel thinking “I know everything about Bootstrapping, hell I’ve helped in doing it atleast twice and succeeded.” Well, I was wrong. Once again, not only was he a guy with real battle scars, he brought along a couple of people from his network that also had scars. Even better was the fact that he brought on bootstrappers that were creating businesses that had nothing to do with technology! I think the most impressive thing was the fact that Goswami was able to break down the seemingly straight forward concept of Bootstrapping into individual stages each with it’s own set of guiding principles.

Finally, a real surprise was the keynote delivered by Frank Warren of PostSecret. Not only was his presentation incredibly touching, he even hooked up a guy by helping him propose to his girlfriend on stage.

In conclusion

Sure there was a lot more crap to sift through, but the few goldmines were certainly worth it. I’m very glad, and for those of you that have yet to discover SXSW Interactive, I really urge you to check it out.

Shop For Bangladesh

Honestly, when I first started using Kayak, I asked to myself, what else could you possible need (short of complete transparency into when prices will fall)? But I pretty much left it at that since I knew that was next to impossible.

Well, Farecast not only scoures the web to find you all the deals on flights, it also tries to predict where prices are going to go. And as if that wasn’t enough, you can sign up for Farecast alerts that notify you on when is the perfect weekend to take that trip to Buffalo, NY.

On a sidenote, yes, I know this blog is horribly out of date and I haven’t posted in over a month, don’t worry, yet another re-design is in progress.

The post was literally up for 20 seconds (stop and count 20 seconds). As I loaded up my Wordpress blog, and logged in to delete the entry, Garret said “Wouldn’t it be funny if Pulse picked up on that entry and aggregated it already?”

We laughed.

Just a few minutes ago, Garret sent over a screenshot of Google Reader, showing the jibberish entry that I had up for those very 20 seconds. Damn Google, you’re good, maybe a little too good…

Sometimes, it’s easy to forget exactly how much more connected the Internet is today. Probably five years ago, you could post some random ramblings to your dinky little blog and no one would ever notice. But today, with the power of crawlers, feeds, and all this openness, 20 seconds is all it takes for the information you create to spread everywhere.

At the same time, I was also starting to plan out my crazy summer activities, and was dying for some way to show it off to my friends.

So, one random night, I decided to just go for it. I planned out a quick little app that would let me list my Summer Plans so that I can show it off on my Facebook profile.

About Summer Plans

After about 6 hours of coding (most of which went toward learning the Facebook platform and finding the documentation for the multiple friend selector) I had my very own Facebook Application called Summer Plans.

I could not have made it any simpler, for each summer plan, you say what you are doing, when you are doing it, and you can list out up to 10 of your friends that you are planning the event with.

The end result is a listing of your summer plans, your friend’s pictures and a simple countdown to each plan.

In fact, I kept it so damn simple (and lazy), I didn’t even include an “Edit” feature.

The true test of the Social Graph

Aside from my self serving goal of showing off my Summer Plans, the one other thing I really wanted to find out was whether the “Social Graph” really is as powerful as it claims to be in spreading a simple web application.

To figure this out, I purposefully left out any and all viral features. This means that your summer plans did not show up in the mini-feed. It didn’t notify your friends if you included them in your plans, hell it didn’t even send a single email out to anyone.

So, essentially, this was a simple standalone app. And don’t worry, I didn’t cheat. I didn’t blog about it, I didn’t send out massive emails. The only thing I did was tell 5 of my friends to kindly install the app, so that Summer Plans officially got listed in the Facebook applications directory.

The Outcome

The outcome was, well, satisfactory. Without any of the viral features, and even with the lack of an “Edit” function, Summer Plans amassed a whopping 449 users that installed the application and added a Summer Plan. As of this moment, there are 302 active users.

Not bad for an app with ZERO viral features.

More Stats

I’ve also heard some horror stories about small Facebook apps getting released and then spiraling out of control, while racking up bandwidth costs and bringing the whole service down to a halt.

Needless to say, at only 303 users, I had no such problems. But, it was pretty interesting to check out how my server stats were affected by the app being deployed.

I have no idea why the Bandwidth usage actually went DOWN. I think it may be the effect of setting up Akismet on my Wordpress install (Note that these stats include hits to this blog, which gets little to no traffic).

Need for Analytics

One thing is for sure, there is a clear need for an analytics package that will help measure the performance of a Facebook app. Being able to figure out realtime statistics on which user installed the app, didn’t install it, and what went wrong where can be the critical thing missing for building successful Facebook apps.

Although, one could argue that the Graffiti app (which, to me, seems to be the most popular Facebook app) will never need such analytics.

Conclusions

As soon as things settle down, I think I want to give Summer Plans another rev (ofcourse, I’ll have to rename it to Weekend Plans, so that it fits with the season). I’ll start adding some of the notifications, emails and other such viral aspects that can perhaps drive Summer Plans to rock star levels. And oh yeah, maybe I’ll add that ‘edit’ feature.