Take the extra 15 minutes with the developers and write a regular expression to take out the dashes and spaces

Somewhere in America, there’s a product manager or client talking to a programmer, and the programmer is telling them, “Yo, it’s going to take an extra day or so to make it so the users can enter in credit card numbers with dashes. Let’s just put in a help message telling them they can’t do it.”

And that client is saying, “Uh, sure. It must be really hard.”

Developers say all sorts of things, and this has to be one of the most insane comments. That’s like saying at a cash register, “You can only use the card this way, and if you don’t, we won’t take your money.”

As bad as conversion rates are, this is one of the worst reasons to limit them. How prevalent is it? There’s a Hall of Shame dedicated to it.

Please.

Fifteen minutes.

Write the regular expression.

Anything that limits the user from completing a form means less revenue, and less revenue means less pay for anyone. Conversion is sometimes about the little details, and this is one of them.

 Comments | Comment

Stolen from Irish Blue in a Running Shoe.

 Comments | Comment

I’m in the process of setting up a few content management systems for clients, and it’s been an eye-opening experience, not because the systems are crude, but because they actually work pretty well. SilverStripe and WordPress are two that I’m looking at using on a consistent basis, but there’s a few resources out there to help you select one:

• Six Revisions has a list of the 10 promising systems it has selected
• Open Source CMS is the mack daddy of CMS lists, and a lot of them have online demos
• CMS Watch is a bit more techie, and is a news portal covering the major systems
• Sometimes a blog engine is just what you need, and Smashing Magazine has reviewed 10 of them

In the coming weeks, I’ll go through some of the implementations I’ve been doing to make WordPress and SilverStripe sing. Stay tuned!

 Comments | Comment

First off, Happy Thanksgiving. I’m going in for gallbladder surgery tomorrow, so the rest of you can eat more for me, but I’m just going to sit here and post about project management.

Why?

Seventy percent of all IT projects die an evil death, that’s why.

Not all of them attributed to to poor project management (some of them are because of too many Starbucks runs), but I would guess that it may be a good part of it. You might be the project manager, or asked to be (because most project managers can be used only in larger projects), or just want to know if a project is in trouble, but it’s good knowledge to have in your belt when you encounter typical project situations so at least you can see the red flags.

We are brought in as hired guns to provide one piece of the puzzle, but what’s usually missing is a holistic view, one where all team members understand the scope of development.

Not all team members want to understand, but I can’t tell you how many times I’ve worked on a project and it didn’t come out any where close to the wireframes because of a lack of understanding of what was to be built. It’s partially my fault because I didn’t followup with the developers consistently to force them to communicate, and I think it’s all our responsibility for literally force communication.

The need for project management

As altruistic as we all are, someone’s gotta be running the ship, and that’s were project managers come in. They’re the one that have the target requirements, report status, clear roadblocks, control scope and at the end of the day, know what’s going on. Many times, they are the information architect’s best friend because they work together on what should and what shouldn’t be built.

Good project managers (and hate to say it, I’ve meet exactly one excellent one, and that goes to Carl Bailey, a project manager I worked with on BidRx) can deftly control the client and the project team with efficient and effective communication. Someone has to be held accountable to make sure the project is success, and it’s not necessarily just the project manager; everyone on the team contributes to getting the product out the door, and everyone needs to be sane about expectations.

The reason most project managers get a bad rap is they don’t have an understanding of their role (are more often than not, are too busy covering their own ass). They get the keys to the car, but many times it’s their responsibility for them to actually make sure everything’s running smoothly, and that means doing a lot of tasks that are menial, like writing down information for communication purposes.

Project managers keep task lists, keep track of progress, understand the budget and estimate productivity. There should be some kind of list that documents exactly what’s going on so communication can go in all directions.

It’s art, literally.

The metrics of project management

Here they are — bet you were expecting more:

• Resources
• Time
• Money
• Scope

Most software development projects realistically focus on three, because most projects have no concept of money (or for that matter, return on investment):

• Resources
• Time
• Scope

When managing a project, you can change two at a time — if the scope increases, you either have to add more resources, or add more time — but if you change all three, that’s a sign of a project in trouble. Run, baby, run.

To determine what’s needed of all three, you can either 1) determine the scope up front and decide how much time and resources you need, or 2) determine the resources, and set the scope and time based on this, or 3) determine how much time you have, and build around that. You ways start with one of the variables (we have to deliver something in two weeks or a month), and go from there.

Information Architects have a great influence of scope and do the project manager a great service by cooperating with them on not only focusing the scope, but discussing with developers on ways to limiting implementation time by making slight changes to the scope that don’t have a significant impact on the user experience.

Project Management Methodologies

Now that you have an idea what key metrics of a project are, how are we going to organize the project?

It’s better to start with some process than to have no process at all, because if you have something to fix, you can alter it to best fit the team i.e. change the requirements gathering process to make it faster or generate more documents for clarify communication.

There over a dozen of different methodologies, most with highly paid authors pitching their own, but two come up consistently in today’s environment: waterfall and scrum. The rest are more for elaborate projects with strict development requirements; you can look those up at wikipedia.

Waterfall Process

Exactly as it sounds, waterfall moves through the phases of requirements analysis, design, implementation, testing, integration, and maintenance. It’s generally used for big, large implementations of an ERP system, software application packages and games that are burned to a CD or have an executable install.

We’re involved in a lot of these because information architects are viewed as a resource that costs money (true) but sometimes doesn’t provide a lot of value if we’re just hanging around to answer questions (not true).

The pros of waterfall:

• A significant amount of time is spent on a design even before development begins
• Scope is fairly well defined, making it easier to estimate implementation time and hence, the cost — companies working with consultants love trying to control the cost
• It’s phases are easily understandable (I mean Fisher-Price easy, really), and roles are defined

The cons of waterfall:

• By the time you’re done, what you’ve designed might be obsolete or the wrong solution because there wasn’t the opportunity to make changes
• It’s very hard to make changes during the implementation phase
• The amount of documentation to communicate an idea is enormous (i once write 1,200 pages of documentation for a project), and there’s sometimes a disconnect between the requirements gathering team and the implementation team
• Teams are forced into silos, and there has to be an encouragement of communication
• Stakeholders have to wait months, maybe even years, before knowing what they are spending their money on is going to work

I’m not a huge fan of waterfall, basically because I don’t get the feedback loop I need to design a better project, and in many cases the stakeholders have no idea what they are designing.

Scrum or Agile Process

The project management flavor of the month, Scrum is a development methodology that focuses on short iterations (two to four weeks) of development time to produce measurable software results, and a very visisble scope of where the developers are in the process. Scrum works great for web development projects because of the single code base, and the ease most code can be changed.

One of the key components of a scrum project is that while everyone’s working in the trees, someone has to be seeing the forest iterations out, and that’s where the architects and project managers (named scrummasters in scrum) come un; it’s about the spirit and direction of the application, little grasshopper.

Software development teams I’ve seen run Scrum or Agile have had a much better time getting software out the door and get a handle on the process than a waterfall approach (who wants to work to a goal several months out?), and it provides a framework to get started.

The pros of scrum:

• Short measurable results and always a product that can be shown to stakeholders, which results in this constant feedback loop (and I love feedback!)
• Great for small teams fo 10 or less, or breaking up larger teams into smaller teams
• Encourages communication of issues without retribution, but does hold the entire team accountable for the process and the results
• The framework allows for changing the project management process for purposes of streamlining development i.e. throwing out what you don’t need and doing only what you do need to keep the ball moving

The cons of scrum:

• The design process up front is very limited; sometimes information architects have only two to three weeks of analysis time before development is itching to get started
• There’s a lot of re-factoring because of changes
• Architecture? Better have a kick ass architect or it’s going to be a mess
• Costs are not tied to scope but to the time it takes to build the project, so companies are uncomfortable with trusting the development team
• Requires a more mature, senior (and sometimes expensive) development team; the idea of throwing someone under the bus has to be controlled, and there should be someone acting at the architect

I’m a big fan of scrum (obviously), because I’ve run it and seen it work very effectively. But I was working in a small development team, and it really depends on your needs.

Resources

• At the very least, if you need a workshop or an evaluation of how to change your project management processes, contact us at pat@usabilitycounts.com.
• Amanda Abelove in Los Angeles is running a non-profit club called Scrum Club. It’s free public education and hands-on training. Pretty cool stuff.
• Paul Hodgetts, a colleague of mine, runs a consulting group called Agile Logic. They do coaching because just handing over a bible of how it works sometimes isn’t enough.
• Joel Spolsky runs something called the Fog Creek MBA, where they teach you about all aspects of software development, including project management. He’s got an even better article called Evidence Based Scheduling.

 Comments | Comment

Need to hire someone that’s a self-starter? Signal to Noise has a great article about hiring people that are self-managing. I hope I’m like that, and a lot of consultant types don’t like being told what to do, because they’ll usually just do it themselves.

 Comments | Comment

Now we finally get to wireframes!

A lot of information architects think the first step of doing a user experience project is going straight to doing the wireframes. I counter that it’s fairly far down the path after doing user research and establishing the use cases, and that wireframes really establish the spirit and intent of a web application; they are the visual framework from which the developers use to build the application.

Wireframes are never seemingly done: I can’t tell you how many projects I’ve been on where at one point or another, we abandoned the wireframes and communicated directly with the developers. Wireframes are a starting point for development and a tool that should be used as such.

What Is A Wireframe?

A wireframe is a visual representation of a single page or screen, and the elements for that page. It is used as a communication tool with developers, designers and the client, and some agencies use them to get signoff from the client. Wireframes contain all kinds of annotations and notes what each element means, and are usually paired with use cases so they are a meaningful guide for software or web development.

Is it possible to illustrate every single step in a wireframe? Yes and no. You can spend the time to do it, but I’ll contend that most developers won’t read the wireframes closely, so when I do them, I usually do just enough detail to get development started but not too much as to overwhelm the developers. Talk to the developers to get an idea of how much detail they need, and refine based on feedback.

Why Wireframes?

The last thing you want to do is let a developer decide the placement of a submit button.

Seriously.

Wireframes are good for two reasons:

• Placement of elements and the visual pattern of the application are important, because they affect the usability and profitability of the application
• Wireframes make great lo-fi prototypes to test your assumptions with users, albeit in an artificial environment

On to the first point: When developing an application, there’s always a process of “does this actually work,” and the best way to develop that visual pattern is to go through the process of making wireframes. Eighty percent of what you are trying to do should fit nicely into some kind of page architecture, and if the elements aren’t working, doing the wireframes will help discover this.

From the wireframes you’ll be able to see design patterns from templates, common navigational needs, and overall site structure. After seeing the forest, you’ll be able to place the trees better. Many times when working with a client, I’ll tape the screens to the wall so I can see the flow of the application and walk clients, programmers and clients throw that flow. When walking through that flow, you’ll find issues that aren’t discovered in simple requirements gathering, and sometimes use cases ill need to be adjusted to fit.

The second point: Once you are done with the wireframes, you can take those wireframes (hide the annotations) to users, and ask them, “so what do you think this button does?”

I’m still on the fence about using wireframes this way, because I think they react much more positively to a clickthrough that involves a screen, but sometimes I take those wireframes and do the lo-fidelity testing, either sitting down or taping it to a wall.

If the users can’t explain what’s going to happen next, it’s probably not obvious enough.

How Detailed Should The Wireframes Be?

It depends.

If you are working closely with a development team, the wireframes don’t have to be very detailed at all, and may or may not include annotations of user interactions. Some development methodoligies like XP don’t even suggest much requirements gathering at all other than writing stories with hand-drawn wireframes as the artifacts.

If the team is outsourced, overseas and 10 hours behind you, you might consider adding as much detail as possible. That includes full annotations, written use cases, process flows and all of the nifty requirements documents to provide the developers as much detail as possible, because they aren’t sitting next to you to ask, “So what does this button do?”

The amount of direction and literal usage to the wireframe depends on the team: sometimes the designers took the wireframes as a literal guide, and in other environments, designers and developers were given some flexibility on how to redesign the screens based on the elements needed.

What Tool Should I Use To Do Wireframes?

The tool used to do the wireframes should be important (Visio, Omnigraffle, Azure, PowerPoint and InDesign all come to mind of past projects I’ve done), but it’s how the communication is carried out. For all intents and purposes, hand-drawn wireframes are effective.

The tools I like are:

• Visio
• Omnigraffle
• InDesign

Now that I’m consulting again, Omnigraffle will probably be the tool I use most often. I’m been contemplating using InDesign, but on the PC side, I’ve found that Visio is portable enough for most environments.

It really comes down to what’s the quickest way to illustrate a concept. Use what you are comfortable with — nothing else.

 Comments | Comment

A few of you know this, but I’ve been going through a health-related issue: gallstones. Me being the normal American male that hasn’t seen a doctor since the first Bush Administration, I had to use the Anthem Blue Cross website to find a doctor consults on internal medicine, and that was a chore.

The worst part about using the website was actually finding the doctor required some dynamic AJAX that (of course) didn’t work on my Mac Firefox 3.0.whatever.

The lesson here? Test all browsers with your application, because not doing so will result in some very angry users.

You might not thing that’s important (who really uses Mac Safari anyways!), but it is, especially if your site or application makes money, skipping one or more browser platforms may mean skipping millions of users, all of whom have credit cards and their “need” to use them.

PC Browsers I would test for:

• Internet Explorer 6 and 7
• Firefox 3
• Google Chrome

Mac browsers I would test for:

• Firefox 3
• Safari

The Anthem Blue Cross site is especially troublesome, because the issues there affect users that have very real health problems, and going to the wrong doctor means an extra cost to the insurance company; how much do you think this adds to the tab on insurance costs in America?

 Comments | Comment

I don’t get it.

 Comments | Comment

That’s a question I always ask when dealing with the clients: do they really care it’s a content management system?

The answer is no.

They’re looking for something that saves them time, backs up their data, makes it easier to share information with their co-workers, and that will work. They don’t necessarily care about the name of it, all they really want it to do is work, and for it to make their life easier.

That’s one of the points information technology departments miss in dealing with end users: the users at the end don’t really care what the name of the software is, because whatever they get, it’s imposed on them. From the email software they use to the word processing software they write up reports in, almost every piece of software is selected and standardized on across departments. Very few end users get to pick what their software is, and if they do get to pick, the information technology departments don’t support it.

So what’s my point?

To the information technology departments, specifically: whatever you do, make sure it doesn’t impose extra restrictions or demands on the end users. Whatever you build into SharePoint, take in consideration that the easier to use it is, the more users that will use it. Imposing extra governance and workflows to it doesn’t make sense.

For example, Groove is a great tool when paired with SharePoint, because you can have files on your local system sync with SharePoint document libraries automatically and seamlessly. What that meant for me is I lost a bunch of files in a system crash, but all of the files were backed up to SharePoint. I didn’t lose anything.

And it was so easy to use, I didn’t even know I was using it.

Can you say the same about your SharePoint implementation?

 Comments | Comment

We’re here to help. Companies still need to do development, and that pesky process stuff should still been done to make sure the development is sensible. Seriously, do you want a .NET or Java developer doing workflows?

We do:

• The normal UX stuff: requirements gathering, wireframes, use cases, etc.
• Section 508 compliance workshops: how do you keep legal heat off your website if people with disabilities can’t use it?
• User Experience process workshops: is your process as good as it could be?

I might be a bit slow about this (I’m taking care of a medical condition), but send an email to pat@usabilitycounts.com telling us what you need. We’ll go to anywhere on the West Coast, and if there’s a contracting job in Vacnouver, Canada, even better.

 Comments | Comment