DonnaM » Blog Archive » Designing in the dark, part 2

Designing in the dark, part 2

I wrote yesterday about an interesting discussion I had with about a development process that has no user involvement, and mused on how it would be possible to create a good system in a situation like this.

I had some interesting comments here, so I thought I might expand on some of my beliefs – it’s good to question your own rhetoric sometimes ;)

Although my post implied that I thought programmers should have some involvement with users, I’d like to clarify that. I think that it is very important that programmers gain an understanding of the user group and their needs. Even if they have a good set of specifications (yeah, right) or a prototype or good design to follow, that understanding will help with many of the small decisions.

However, I do not believe that programmers should be doing the requirements gathering process or the interface design.

Now it’s not that I think that programmers can’t talk to users. I believe that programmers think in a *very* different way to the users (unless they are writing a product for other programmers, and that isn’t terribly common). Programmers are fabulous at solving problems – the cognitive capabilities to create code are similar to those that we use to solve problems. They are so fabulous at problem solving that they see a problem and think of a solution, immediately. What they aren’t so great at is seeing lots of conflicting problems, determining the underlying cause, thinking about it some more, and then designing a solution. That’s an entirely different way of thinking. Every programmer I have ever personally known collapses at this point – conflicting priorities and individual differences frustrate them to no end.

So how do I think it should be done? Requirements gathering and design are one process, not two (which I probably should elaborate on further another day), so should be done by one person (or one team in a big project). The most difficult issues for this person is then communicating the important parts of the requirements or the design to the people who are going to implement it. There are lots of documented methods, many of which I have never managed to get to work. The things that do work for me are:

  • involving programmers in some representative user contact
  • doing lots of sketches for people who can understand my diagrams
  • lots and lots of discussions (not arguments)

Actually, on thinking about it, the thing that works best for me is respect. I show respect for the abilities of people that I work with, and they usually show respect for me. This means that we discuss ideas, problems and solutions rather than arguing about *my* design. I don’t know how you build a methodology on that!


  • I stole today’s post title from Opposable Thumbs, because it was far better than my original title
  • I’m not the first to say this – many people have put it more eloquently than I
  • I know lots and lots of incredibly talented programmers, and recognise that they think very differently to the way I think, so this is not an anti-programmer post

7 Responses to “Designing in the dark, part 2”

  1. Thomas Lockney Says:

    First, thanks for the attribution and good re-use of the title. :)

    Second, I agree with you that in general programmers should not be directly gathering the requirements from the users. However, at least in most development projects of any substantial size, there is usually at least one technical type involved in the early design phase. Yes, this person needs to be more than an average programmer. In fact, it doesn’t need to be a programmer at all, but it needs to be someone who at least understands the capabilities of the technology. And often a good lead or senior developer who has worked on a lot of projects will have enough design sense and interface experience to provide this sort of thing.

    They should definitely not be the only person responsible, though, which is part of the reason why this approach doesn’t work so well for smaller projects.

    To be perfectly frank, I’ve just as often seen a “designer” or a business analyst charged with the initial design and requirements gathering where the end product felt like a giant cludge. The fact is that it’s often hard to get them out of the box they live in and think about what other possibilities there are.

    As an example, one of the more successful projects I recently worked on involved a continual interaction of both the design and development staff with the end-users. I think that this is ideal if for no other reason than it gives the entire team visibility into the world in which the product will eventually live.

  2. Donna Maurer Says:

    Agree on all points – and there are always bad and good people in all professions.

    Actually, come to think of it, I have never seen a good result from a business analyst ;) (oops – see me insult an entire profession all at once)

  3. Austin Says:

    Just skimming quickly, but I think that if the interaction design is done well, then those specs can be handed to the programmer to do thier magic on the back-end.

    The interface design becomes the liaison between programmers and users, and good interaction design alleviates any problems the programming may cause.

  4. Amr Al-Hindi Says:

    “What [programmers] aren’t so great at is seeing lots of conflicting problems, determining the underlying cause, thinking about it some more, and then designing a solution. That’s an entirely different way of thinking. Every programmer I have ever personally known collapses at this point – conflicting priorities and individual differences frustrate them to no end.”

    Maybe you need to know more programmers:-) Reducing programmers to a stereotype is not going to help.
    I can see why it is necessary to define the borders between programmers and designers for the purpose of conceptualizing the process. In reality, however, it is not helpful to think that programmers are from Mars and designers are from Venus. The interaction of the skills of both groups contribute to the success of any project in ways we can’t always account for. Like Thomas said, many programmers have accumulated enough experience to provide valuable input in matters of design and interaction. That’s why we need to have faith in each other’s abilities and look beyond rigid definitions that easily substitute for streotypes. Somethings are hard to incorporate formally in any process. Respect, like you said, is one of them. Faith in each other is another.

  5. Donna Maurer Says:

    Apologies – I’m not trying to stereotype, but to point out that people with particular types of skills and natural abilities are attracted to particular professions, and that we all should recognise what we are best at. As you say, it is the interaction of these skills that allows us to create great things…

    I do know lots of programmers. I have done lots of user research/requirements gathering. Most times, the reasons for conflicting requirements is due to the way that humans are – our cognitive abilities, communication abilities and social structures. To successfully design for conflicting requirements, you have to be able to understand these issues. But that’s another post entirely ;)

  6. Ron Zeno Says:

    “However, I do not believe that programmers should be doing the requirements gathering process or the interface design.”

    I know of no other group more qualified or more successful than programmers.

    This “programmers shouldn’t do X” argument has been around for a few decades now (Don Norman was using it in the early 80′s for heavens sake!). That’s plenty of time for groups to demonstrate that they can actually do better. History has shown not only that they can’t, but don’t bother trying. It’s just a strawman argument.

    The bottom line is that no one knows what skills are and are not useful in understanding product requirements. There are individuals that can do it well, but they’ve failed to demonstrate they can teach what they do to others. There’s also the problem of people hopelessly overestimating the value of their own work.

    I’ll stick with hiring programmers, thank you. I know what they are capable of as a group, and can easily screen for the specific skills that are unquestionably the most valuable.

  7. Mike Says:

    I would have to disagree Ron. When you are building a home, do we leave the design of that home to the fellow who is hammering nails to put the walls up? Not typically. Would he be capable of telling you where the door should go, how big to make a living room or whether it should be a bungalow or 2-storey home? Sure, possibly. He’s built a hundreds of homes to draw experience on. But the reality is that people have architects design them their home first (or they buy a plan). Why? Because if you left it to the dozen carpenters hammering away, they’d all have their own ideas. Would they all go and talk to the owner of the home and see what he//she wanted out of the home building processes? Rather, an architect sits down with the home buyer, gathers their requirements, proposes design to them while keeping “building realities” top of mind (i.e. building codes, properties of materials, etc.)

    For applications its very much the same. I typically staff a development project at the onset with business analyst(s), information architect(s) and a technical architect (who doubles as the technical lead for the project). With this trio of roles, the requirements are gathered (biz analyst) and from those a usable design is extracted (info arch) and functionality within that design is spec’d out (info arch. & technical arch).