A couple weeks ago I talked about a new approach we're taking at work where we prepare but we don't plan.  This week we seriously benefited from the strategy and I want to spend some time going over what we did right, what we did wrong, and what I learned from it.

So here's the situation.  We recently released an CRM (Customer Relationship Manager) that our resellers can use to manage all the contacts for their entire organization.  When coming up with the structure, there was a question about how we should handle group permissions.  

For example, maybe an insurance agency has some people selling HRAs and other people selling insurance.  How should the agency control which contacts different people can see and how people can interact with these contacts?  Or maybe an agency has branches in two different states and sales leads should be confined to only the appropriate branch. Suffice to say, there are a lot of different ways people might choose to use a CRM and we needed to support as many of them as possible.

About a week of the initial CRM development was spent planning and implementing this permission structure.  Near the end of that week it became obvious that we just didn't know enough about how the product would be used to make some of the more important decisions.  We ended up throwing together a pretty simple set of features and releasing it.

So to summarize, we released the CRM without really knowing how group permissions should work.  The product was functional but a piece of it was missing.

We've now had two weeks to observe how our clients are using this system and now we feel completely comfortable making the design decision that we previously were unable to make.  It's unfortunate that our new plan makes the week we already spent on this completely wasted, but that makes our decision to wait on this particular feature all the more valuable.  

If we had made assumptions about what we needed, we would have been backing ourselves into a corner and the resulting product would have been crippled for months or years because of it.  By waiting to make any definite plans, we allowed ourselves a couple of weeks to observe our users which in turn gave us real actionable information instead of baseless assumptions.  So sure we wasted a week, but overall the process worked.

There's one important thing that I took away from this beyond an overall sense of satisfaction.  In the future, I should try to be more aware of which early decisions are based off real, solid information and which ones are wild guesses.  I might not always have enough information, but I can at least be more aware of what information I don't have.

It's time to apply some grocery knowledge to UI design.

I spent the summer of 2007 working as an intern at General Mills.  They had a weekly lecture series where some big wig from the company would talk to the interns to help us understand the business.  One of the talks was about how much thought goes into where food is placed in a grocery store.

There were tons of interesting topics, but I bet you don't really care that much about cereal so I'll skip to the good one.  You surely know that the cereal on the bottom shelves costs less than the cereal at eye level.  What I didn't know was that the most sought after spot is at the middle of the aisle.  Apparently people tend to start walking down the aisle of a grocery store and they aren't mentally prepared to buy anything until they've walked about 15 feet.  They spend that time absorbing the fact that they want cereal and then they start actually looking at products.

So all the major players in the cereal industry (apparently) fight over the middle of the aisle.  It's not just about who has their boxes at eye level or who has the eye-catching designs.  It's not good enough to make sure that customers see your product.  Customers need to see a product when they're in the right state of mind.

So now I'm wondering how I can apply this to web design.

A good example of me trying to think like I'm at the General can be seen on the front page of this site.  As I mentioned in an earlier post, I think that my bio is the least important part of this site.  So why did I put it third instead of fourth on the home page?  I basically figured that people are likely to skim across the items and pay more attention to the last item (resume) than the one before it.

I also read recently (sorry, can't find the link) that the two most important parts of a page are the top left (where the user begins reading) and the bottom right (where the eyes stop when they're done).  All the stuff in between is generally just skimmed but most people notice the first thing and the last thing they see.  I guess it's similar to how you can jumble up the letters in the middle of words but as long as the first and last letters are correct, people can generally read the word in a sentence (example: I enjoy swonbraodnig in Park City).

I'm far from an expert when it comes to this stuff, but here's what I'm going to try to do to improve.  Whenever I design a new page, I'm not just going to attract the user to action items by making them big or a different color.  I'm going to try to lead the user to an item through all the other content.

This article from Smashing Magazine has a great example of what I'm talking about (go down to number 6 on their list).  I need to funnel the user experience to the important parts of the page.  It's not just calling out the important things, but it's guiding attention to those important things.  This way the user isn't just seeing the "SIGN UP NOW OMG!!!!1" button, they're approaching it in a natural way that hopefully makes them feel more comfortable and willing to see what the next page is like.

I need to come up with more examples of this.  I must admit that while I've thought about this idea a lot at a high level, I haven't gotten to the point of trying it out a whole lot.  We'll see how it goes.

Here's an issue that keeps coming up both at work and a few side projects I've been working on (including this blog).  When making any kind of decisions, you have to do everything you can to make sure that decision will still make sense a month or a year from now.

The Old Way

Unfortunately, I think the most intuitive way to try to make decisions that stand the test of time is often the worst way.  At first glance, it seems like the way to future-proof decisions is to figure out exactly how you expect things to play out.  If you can predict the future, it's easy to make sure you're doing your best to prepare for it.

The problem is that no one can predict the future so people end up coming up with plans based on false assumptions.  That's a pretty easy way to ensure that your decisions will look incredibly stupid when you look back on them.

I can't count the number of times I've sat in a meeting discussing exactly how the plan will work.  I've spent hours figuring out the exact order we'll build new features, exactly how we'll get new features to market and how we can expect our user base to be affected.  Months later you're sitting around trying to figure out the source of problems.  Most problems can be traced back to a bad decision that was made months ago.

The thing is, I'm not an idiot, and I don't work with idiots.  The decisions are good.  It's the assumptions that drove the decisions that are to blame.

The New Way

For the past couple of months, I've tried taking a new approach.  I don't ever try to figure out what will happen.  Instead I try to figure out everything that might happen and I make sure that I can handle any senario I can dream up.  The key to this is constantly re-evaluating everything I do.

This is harder than it sounds.  When you just spent a week developing something, it's really difficult to look at it and realize that everything you did was misguided.  It's natural to defend past decisions if at all possible both because it really sucks admitting that you just wasted a week of your time, but also because it means you were wrong at some point.

Here's an example.  I don't think that it really makes sense to have a blog with no real name or URL or anything like that.  There's a branding problem with this blog.  The reason I haven't fixed this problem yet is that I have no idea how this site will play out.  Maybe tylerking.net should only be a blog.  Maybe I'll develop a love of gardening and decide to write exclusively about that.  If I made a decision now, it would end up being based on some kind of assumption.  That's why I'm just writing content and assuming that the role of this blog will slowly take shape.

Prepare, Don't Plan

To summarize, I'm not advocating acting without any regard for the future.  I'm just saying that it's arrogant to think you know what will happen.  The best you can do is make sure that whatever you do today doesn't close off any possibilities for tomorrow.  Do that every day, and you'll never back yourself into a corner.

Until recently, I thought that anyone designing software had to balance power with simplicity.  Advanced users want power and beginners want simplicity and your options follow a continuum between the two.

So if this is actually the case, the design has to cater to the type of users that you think might not use your software if you are focused on a different type of users.  For example, Mint.com is a great site but it is very focused on simplicity.  I personally would prefer more features even if it means increased complexity.

Mint makes the right decision by ignoring me.  I don't have any better options than Mint and I'm definitely going to use something which means that Mint doesn't really have to work to keep me as a user.  The people that aren't as tech savvy or math minded as me have another option.  If it's too complicated, they just won't use any personal finance software at all.  Mint needs to cater to these people.

However, I don't think that power and simplicity are necessary mutually exclusive.  I'm starting to realize that there's a new type of design that's becoming popular.  I'll call this design paradigm "educational".  It doesn't lie anywhere on the line between power and simplicity.  Educational design is off in it's own dimension.

With educational design, you include very powerful features but you slowly expose the user to the complexity so that they have time to get comfortable with the system before using a more advanced version.  When done correctly, it's very effective.

Here's an example of how I'm trying to use this strategy:

At work we're designing a new CRM (Customer Relationship Manager) that our resellers will use to improve their sales.  Users enter new contacts into the CRM and they can then enter notes to track communication they've had with each contact.  Additionally, contacts can have Sales Pipelines attached to them which will track specific types of sales (health insurance for example) and assign a status to that sale.  This entire process makes tons of sense once you're used to it, but it could be very confusing for a new user.

Rather than compromise between power and simplicity, we are trying to make defaults on every page that are very simple, but encouraging the user to explore.  When you view a contact, there's a big box saying "Enter notes about John Doe".  If the user doesn't want to deal with complexity, they type something into the box and click a button to add the notes.

However, there's a dropdown list next to the box saying "Enter this contact in: Notes | Insurance Sales Pipeline | HRA Sales Pipeline...".  The user doesn't have to choose anything (it defaults to notes) but if they're curious, they'll check out the dropdown list and see they can enter a note specifically about a sale.  Once selecting "HRA Sale", a new dropdown list shows up letting them choose a status (Lead, qualified, negotiations, sale...).  They will also see a box saying "Remind me to follow up on this sale in __ days".

The idea here is that very basic users won't ever try changing the first dropdown list.  Once they're comfortable, they'll select a pipeline and see more options.  From there, even more power can be accessed but it isn't shown by default.  

Hopefully users will teach themselves how to use this system, but the best part is that they don't have to.  It works for people that have no clue what they're doing and it also works for the most advanced users.  It takes people from knowing nothing about pipelines, automatic reminders and all kinds of other features and it slowly introduces these concepts such that most people will learn the system intuitively.

Time will tell if this particular implementation works, but I'm sold on the idea in general.  I will no longer think, "should this be powerful or should this be simple?"  Now I'm going to think, "How can I teach the user to how the software works without them even realizing that they're learning?"