Be Careful What You Wish For
Wednesday August 24, 2005 / 5 CommentsA post today over at Signal vs. Noise about making one person responsible for each todo item indirectly reinforced the point that what people ask for and what they really need are two different things.
It’s not at all uncommon for a client to request a feature without thinking about the consequences of that feature. As developers or designers, it’s our responsibility to listen to the request and understand the problem rather than just nod our heads and say yes.
Often, you’ll find out that the request is a symptom of a deeper problem. In those cases, patching the symptom may just cause more problems. Part of being a good developer or designer is looking beyond the request in order to provide the correct solution.
Take the Basecamp request for example, users want to be able to assign todo’s to multiple people. That completely erodes any concept of accountability. Sure a team of five may be working on one item, but in that case there are really two solutions. Appoint one person as ultimately accountable for that item, or break the item into 5 smaller items that can each be assigned to one person.
Building an application is about understanding your users and their problems and helping them solve those problems. Knee jerk feature addition involves little to no deeper understanding and can be very harmful to the success of an application.
Featured Stuff - Resources: Wireframes & Page Description Diagrames
Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates
As developers or designers, it’s our responsibility to listen to the request and understand the problem rather than just nod our heads and say yes
But as designers, it’s also our responsibility to communicate the reasons why we don’t think that the users’ requests should be implemented — that’s where I think the emphasis should be; not about why the clients are ‘wrong’, but about how they can be shown different and perhaps better ways of doing things.
Careful communication is essential — for me, the ‘helping them solve those problems’ bit is the most challenging part of working with clients. Peter Parkes
Peter – Absolutely. I would never advocate not communicating. In fact, I would advocate quite the opposite. When you receive a request, your immediate response should be to ask more questions in order to understand the situation.
Naturally, the pros and cons should be discussed, but the only way to arrive at the real root of a problem is by communicating and asking questions. Garrett
‘Your immediate response should be to ask more questions’ — I always just end up sounding like some sort of military interrogator, but you’re right; asking questions is often not only useful in terms of the answers you get, but also in terms of the way in which you can steer the discussion of the clients needs.
Client says: “I want this”; you say: “Okay”. Job done.
Client says: “I want this”; you say: “Okay — but why? And have you thought about this?” Job done better. Peter Parkes
The company I’ve recently been hired by is painfully learning this fact. We’re going to be re-doing a project from scratch because the company at certain critical points in the past just nodded their head. Not to mention the client really didn’t know what they wanted in the first place.
The analogy I’ve been using to my boss is building a house room by room. Each with no windows or doors. So we’ve been re-routing electrical when they want a new outlet, making holes in walls for windows and doors, creating whole new hallways. Oh that room is a bathroom now? Great, the plumbing center is on the other side of the house, hrm… JohnO
Actually, It’s a perfectly reasonable request that points out a significant design flaw in Basecamp: there isn’t a good way to capture team organization and work.
While assigning a single person accountability is the usual mode du emploi, it’s not the same as answering the question “who’s working on this?”. The question is: what is Basecamp supposed to accomplish?
There are two other solutions that maintain the “one task, one owner” relationship (assuming it’s a valid assumption, of course), while responding to the user request for functionality that fits the way they work (which isn’t that out there, by the way):
a) Allow the creation of a workgroup item, to which people can be assigned. Also, allow tasks to be assigned to the workgroup.
OR
b) Create two roles: accountable party, and involved (or responsible) party. While Tom, Dick, Harry and Jane may be responsible for performing the work, Jane is the team leader and is accountable for the results and making the schedule and budget. Eric Sohn
Comments are closed for this entry.