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.
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:
In the coming weeks, I’ll go through some of the implementations I’ve been doing to make WordPress and SilverStripe sing. Stay tuned!
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.
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.
Here they are — bet you were expecting more:
Most software development projects realistically focus on three, because most projects have no concept of money (or for that matter, return on investment):
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.
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.
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:
The cons of waterfall:
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.
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:
The cons of scrum:
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.
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.
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.
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.
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:
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.
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.
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:
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.
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:
Mac browsers I would test for:
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?
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?
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:
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.
Patrick Neeman is Director of User Experience at Jobvite, a social recruiting platform and runs both the UX Drinking Game and Startup Drinking Game | More | Contact
If you're a UX Designer in San Francisco, ping me at Twitter. I want to add you to a list I have there.
