“Keeping you up to date with everything software engineering!”

Fred Baku: How To Make Prototype Review Meetings a Waste of Time

Work Life | October 27, 2004 | 5 comments

Meetings… got to love them. Especially prototype review meetings or as I like to call them point and say awwww meetings. I spent two days on a prototype for a project that is estimated to last 16 weeks and the project manager is optimistic that it would be approved on the first run through. No shit it will be if you just point to a pretty user interface (UI) in the front of a room full of people with long titles but no end users.

What really makes these meetings really productive is that no users participate in them… why have users attend a meeting where the only thing they will do is point out flaws with the system that they are going to be ultimately responsible of approving in the end during user acceptance.

I suggested to my manager (the project manager) that she should get users of the system in front of the prototype and ask them to complete some of their daily tasks. She said she would after the prototype review meeting. Wouldn’t the meeting be so much more productive if not only we showed management what we produced but explained to them our findings about the application through our user testing?

This leads me to my first rule.

Rule: Fred’s Pre-Condition for Prototype Meetings

Have at least five users sit in front of the prototype and ask the user to run through at least 3 out of the 5 main tasks the system is being created to automate.

If a system already exists and you are trying to improve on it or you just want to better understand the system I have created another rule.

Rule: Requirements Gathering

Sit with the person you are building the system with and watch how they presently do their work. Tell them you have been hired to make their life easier and more efficient. If they start to trust you they will let you into their world and even make suggestions on how their present system can be improved. This would work with any type of method they are presently using to complete their tasks… from computer systems to manually.

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 27, 2004 11:19 AM | ElvisIsGod commented:

Your comments are valid but you forget some of the other rules.. The client wants to see “pretty images”, they don’t care about useability. You can’t sell user testing in most cases.

If you sit the end user, they will most likely want you to build a system for “them” - meaning very personalized. For example in web design, I feel that I have to customize for the boss’s screen. To make the system look good on his system only. This is not good design, but something that you have to watch out for.

Listening to an employee is fine but the results should be analysed to find out what they are really saying. Finding out what the real problem is and how to improve it is the key.

October 27, 2004 04:23 PM | Louis-Philippe Huberdeau commented:

Having users to give comments on the application is required, of course. In the end, they are the ones who will you using it. The best is to have experienced users: those that know the job that has to be done and how it should be done. They are the ones that will be able to guide the development in the right direction. If they are not present, you will either have an application that does not do what’s required or a super-geek interface no one knows how to use except those who made it.

Of course users like the interface to be pretty: they see it all day long. From my experience, they prefer to have something stable and ergonomic than pretty, but perfection is what you should be aiming for right?

October 28, 2004 09:21 AM | Gili commented:

Gili’s #1 rule for meetings:

if some of the people attending the meeting don’t actually need to digest all the information or participate at all, have them attend a subset (or none) of the meeting.

I wish managers would finally realize something I have: if you have 5 people sitting around a table, only one speaking and the other 4 are idle and frankly the discussion does not interest them or concern them one bit, you are wasting the equivilent of 4 people’s revenues. Congratulations Mr. Manager :)

November 3, 2004 08:24 AM | John Kopanas commented:

Perfection is not a bad thing to aim for. It is something that will never to attained (sorry)… but we should always strive for it.

But there is always a point in time where you have to ask yourself is the cost of improving the product worth more then shipping it today? I wouldn’t ask the managers that question but most developers know when a product is good enough for them to be proud of it and use it themselves.

November 5, 2004 11:53 AM | Niraj commented:

I think I agree to a certain extent with Elvis & John’s original comments. But expanding on that point where it could be productive to sit with end users to go over a given prototype is where you understand what the user wants, before he even knows what he wants. As Elvis points out, end users often lack the capability of abstracting beyond their current needs. It is the job of the software engineer to understand what the user needs today and what he will most likely need tommorrow. Anyone can develop an application when someone is giving him blow-by-blow instructions…but there aren’t many people who can add value to this process…that’s where the engineering aspect of it comes it.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)