Comments on: Designing in the dark, part 2 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2 Information architecture, interaction design and much more Sun, 07 Sep 2008 21:01:10 +0000 http://wordpress.org/?v=2.3.1 By: Mike http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-343 Mike Thu, 23 Sep 2004 08:50:12 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-343 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). 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).

]]> By: Ron Zeno http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-342 Ron Zeno Tue, 17 Aug 2004 01:42:41 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-342 "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. “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.

]]> By: Donna Maurer http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-341 Donna Maurer Thu, 12 Aug 2004 23:28:40 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-341 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 ;) 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 ;)

]]> By: Amr Al-Hindi http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-340 Amr Al-Hindi Thu, 12 Aug 2004 20:13:09 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-340 "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. “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.

]]> By: Austin http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-339 Austin Thu, 12 Aug 2004 17:32:46 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-339 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. 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.

]]> By: Donna Maurer http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-338 Donna Maurer Thu, 12 Aug 2004 13:52:34 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-338 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) 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)

]]> By: Thomas Lockney http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-337 Thomas Lockney Thu, 12 Aug 2004 13:43:56 +0000 http://maadmob.net/donna/blog/2004/designing-in-the-dark-part-2#comment-337 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. 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.

]]>