There’s a few people that are more adamant than me about their dislike for Basecamp, but I finally decided to take a taste of the Basecamp Koolaid. It’s been a quick and dirty lifesaver, because it’s something I don’t have to maintain, and if something goes wrong, I would hope file recovery would by their responsibility.
It’s one of those tools that I wish did more, and while it’s simple, it’s too simple. By the time you figure that out, you’re kind of stuck, because migrating files is a pain in the neck.
Look, you can drag and drop!
Look at the nifty hover-overs!
Look, wiki’s, but not really!
It’s cool for us web types that love that kind of stuff, but have you ever tried watching a corporate user use BaseCamp? It’s painful. They don’t get most of those little features and touches because 1) they aren’t Web 2.0 experts, and 2) the features aren’t documented in a way that any user would really know how to use them. It would be nicer if they spent some of that time on the next point…
This is a discussion that a friend of mine and I have about the product. We’re using it, and it’s a nice little file sharing tool, but there’s a lot of features we wish it had. Like…
…and the list goes on.
Seriously, a few of these features would be really, really easy to implement, and wouldn’t take a full feature release.
Simplicity is one thing. Limiting your feature set and telling the users it’s good for them is another.
I’m using Basecamp on a few projects, and am paying the $24.95 a month. That might not seem like much, but hosted, that’s roughly $300 a year. I can write that off (and I do) as part of running a business as a consultant, but still, that seems like a lot, and I’m using it on really small projects.
For example, here are some prices for SharePoint (which is the same pricing plans with more features as BaseCamp). Outside of some configuration issues, is a much superior product, and is gaining more acceptance in the corporate community. There’s some great templates to get you started, and quite frankly, I could set up a template in a week that replicates much of the functionality of BaseCamp. I’m lazy because I have more important things to do (like bill clients), and MOSS doesn’t have very good Apple support.
That said, if I were working in an environment that was mostly Microsoft, and had time to setup a SharePoint instance, I’d be all over it in a heartbeat.
Sometimes marketing and a cult takes over. Good examples of this are Apple and eBay. Apple products are wonderful (I own enough of them), but they aren’t the most usable in the world. Same with eBay. eBay’s gotten much better over the years about user experience, but the reason it’s big is that they provided a marketplace, had that cult factor and marketed effectively, not because it ws the best product on the market.
The same goes here. If you tell the right people how good you are, and you have the right public relations professionals, you’ll get sales. It’s about the cult, sometimes, especially in the Web space.
This post is kind of old, but still, why did they publish this?
I’ve been a product manager, and laughing at your customer base was something that you did over a couple of beers with your customer service representives, not in a blog post. We all agree users in the end are stupid, but you aren’t supposed to make them feel that way.
I remember the days of the users doing something stupid, and then correcting the issue through a better feature development or more help text. This is like airing your dirty laundry, and what’s a bit more troubling about this is that it’s not like this is a free service — users are paying for this product.
They don’t hesitate to take shots at other sites — and yet seems reticient to deal with listening to their users. Let’s face it, the only person that can get away with that is Steve Jobs, and I don’t see him working anytime soon at 37signals.
I just recently appeared on a panel talking about Agile development and User Experience, the benefits and the pitfalls. It was fun to have a discussion with people of other thought processes about agile and waterfall, but I’m a huge proponent of doing development and User Experience this way.
My first experience with Agile was April 2001, and I’ve run several projects with it since. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).
The result? A profitable company with a profitable product.
Three of the projects I worked on went by the wayside. There’s no accounting for issues with company culture. However, five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.
This first thing I’m going to do is define Agile development so we’re all on the same page.
Agile methodologies, or cultures, generally have the following:
It’s also key to note that I used the word “generally,” because the process is defined by the teams that use it. So, some may only use elements of Agile and Scrum.
I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.
But for the web, where everything is changing, it’s great.
Here’s how to convince most User Experience teams that Agile can work:
One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.
I’ve run a Scrum-like process over the phone (I’m doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.
If there’s an issue of the design not working the way you want it to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.
Waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before developing wireframes, or user stories, and that’s okay. Unless you’re inventing the new iPhone, why would you want to do that?
Usually you develop a lot of areas with stubs (i.e. “We’ll do that later, but just put a page there.”) and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt; and, in some ways, it doesn’t allow you to over think a feature.
From Agile Product Design:
User experience people working on Agile teams become masters of development time travel, nimbly moving back and forth through past, present and future development work.
You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.
Since the team decides how to build the process, that means the requirements can take whatever form the team wants them to take. If you can’t do wireframes or HTML mock-ups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it, beacause how many times do we need to redesign a lost password process?
I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format; talking through a feature instead of looking at it in a PDF is a much more effective way of communication.
To mitigate direction issues, what I did was develop a really high level style guide to make sure we had a holistic view of the system, then did not annotate wireframes. The developers knew just the form or text elements; and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.
Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.
If there was particular communication that we felt wasn’t needed, we would cut it out of the process. Who reads all the requirements, anyway? Usually just the User Experience folks do, while arguing with the developers. That’s an important distinction. If management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools; it’s about the people using them.
While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing. That means you have to bring in or find some test subjects to throw against your ideas. This does not mean you should write formal reports, (there’s not enough time for that) but it does mean you should do enough testing to make sure your product is going in the right direction. You won’t spot every issue, like rocks and sand: you’ll catch the rocks and have to worry about the sand later.
It allows you to fail quicker. If there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.
The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s worth of work or less.
Smart Agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development. Developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on. They spot potential issues even before the developers do.
On a few projects that I’ve been on, we saw a 50 percent drop in defects reported and had fewer reworked features.
That’s huge.
One of the biggest frustrations of working in software development is waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show results, developers can agree upon delivered features after the first iteration.
This creates a sort of washing machine effect to gathering requirements and software development. You keep moving toward a common goal of building the final product. Instead of seeing huge leaps of functionality with possible huge leaps in missing the target, tasks are built in bite-sized chunks so you have a better idea of meeting your goal. You also get an idea of whether or not your estimates for building the product are on base, and what you have to adjust before.
It’s about making it to the finish line, one inch at a time.
One of the rules we had at Escrow.com is that no one worked over 45 hours a week; and if they did, I kicked them out of the office. Two similar projects that I worked on had the same approach.
This was very important from a few standpoints:
The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? How good was that product, really?
Doing estimates well is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.
At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.
That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.
One of the greatest things about Agile development is that everyone has a voice. That means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.
There’s always a user advocate in the process of building the product.
Agile isn’t for everyone; however, when it does work, it works well. It does require a different mindset, and there are flaws to overcome.
Random Thoughts mentions the following downfalls:
I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.
Blog posts:
This was a thread over at LinkedIn, published in CIO. My submission is number three.
Here’s a few of my favorites:
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.
You probably thought that it was going to stop at one part.
Clever Workarounds has published parts 2, 3 and 4 on their blog, and I’m sure it’s going to continue for some time. My favorite of the Part 4 is the square peg, round hole illustration.
Here’s the complete list:
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.
