Fog Creek Software
Discussion Board




Design By Cattle Call?

I have worked at a few dev shops where the practice of "design by cattle call" was the rule. 

Let me explain.  Once a feature is proposed and a functional spec worked up by a business analyst, a design meeting is called and anybody in the company who wants to show up can show up - salesmen, testers, corporate controllers, janitors and receptionists alike - and offer input on the technical design of the feature.

I'm curious if you have any experience with such a practice, or any thoughts on the matter.

Norrick
Saturday, February 21, 2004

Janitors?!

Sounds perfectly terrible. Large meetings with lots of people are not a good place to do design -- they are only useful for brainstorming to get ideas. And most of the time when I've been in such a meeting it was just a cynical ploy to make the tech writers feel important.

Joel Spolsky
Fog Creek Software
Saturday, February 21, 2004

I disagree somewhat. It depends on the context. A friend of mine does consulting work and before they start coding a new app they hold seminars at the client company and invite everyone who will use the app or is affected by it in some way.
Their thinking is that the people 'on the floor' will probably have a better understanding of the workflow even if they dont know jack about data modelling. The seminars is a way of channeling the knowlege of the workers into the design, and apparently it works very well.
I should mention though that the seminar participants dont have any direct influence on the design, even though they will often think that they had. They do however contribute alot to the overall sturdyness of the app.

Eric Debois
Saturday, February 21, 2004

... that's what I meant by "brainstorming" -- no decisions are being taken, but lots of input is being gathered by smart people who will synthesize the input and take decisions later.

Joel Spolsky
Fog Creek Software
Saturday, February 21, 2004

just injecting a slightly cynical note here, is that another way of saying "yeah, we've pretended to listen to you.. now wait for the design document that is signed off by the entire team, but curiously has nothing even remotely resembling the material discussed? "

Been there, seen it happen. In fact, a team lead I knew used to get away with it on a regular basis. No one wanted to make waves.

deja vu
Saturday, February 21, 2004

From what my friend tells me, the seminars are very valuble because they get to hear things like "Once, the widgets had two thingummies!". Such info can be pretty vital, especially after the client rep assured them in writing that "All widgets have one thingummy each".

Eric Debois
Sunday, February 22, 2004

There's a lot of value in having lots of people provide input on the functional requirements - whether you use brainstorming, interviews, JAD sessions - it's all designed to extract the best ideas and the most appropriate points of view.
Once the requirements are understood, however, the best way to achieve that design should not be an open meeting. I realize there's no clear line between "what" and "how" - if the requirement is "the user selects the widget to be twingled", there are many ways for the user to select the widget - a query, a drop down list, voice recognition etc. And - in my experience at least - designing the user experience is perceived by many users as being part of the "what", and many techies as belonging to the "how".
Nonetheless, I believe that the "how" benefits from discussion among only a small group of people - any more than 5 and it seems to get out of hand. Typically, I let the developers propose a high-level candidate design, we discuss the design, and then I let them fill out the detail later, usually working in pairs.

Neville Kuyt
Monday, February 23, 2004

>>>designing the user experience is perceived by many users as being part of the "what", and many techies as belonging to the "how".

..which is also an importat thing to remeber with regards to usability. Most people have no clue as to the actual 'what' and so their understanding of the causality of an app is limited to "Push button X --> Program does Y". That, I think, is the sort of the first principle of usabillity.

Eric Debois
Monday, February 23, 2004

*  Recent Topics

*  Fog Creek Home