The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Is About Face 2.0 Waterfall?

There seems to be some discussion in the rails community about doing some design up front as advocated in About Face 2.0 by Alan Cooper prior to any development. Jeremy Voorhis feels that <a href="http://www.jvoorhis.org/articles/2006/08/31/agile-book-club-interaction-design">this is too Waterfallish</a> while Robby Russell <a href="http://www.robbyonrails.com/articles/2006/08/30/agile-interaction-design">finds it adaptable</a> to Agile methodologies.

Where should the creative process of Interaction Design be placed in the process? Before, during, or after development? Should programmers be trusted to manage this process?
Rodney Send private email
Thursday, August 31, 2006
 
 
Rodney Send private email
Thursday, August 31, 2006
 
 
Rodney asks:

"Where should the creative process of Interaction Design be placed in the process? Before, during, or after development? Should programmers be trusted to manage this process?"


How can this be placed anywhere but at the front?  I have yet to see an example of someone building a decent system that requires human interaction where you design the back *before* the front (i.e., database/datastructures drive the UI rather than vice versa). 

I'd always been told that this was possible, but during my younger years I'd always felt quesy about accepting this as doable since I couldn't quite grok it.  It just made no sense.  However I was willing to accept the "wisdom" of my elders and play along. Now as a hoary old veteran of nearly 7 years in this industry, I'm almost certain it's NOT true. 

I believe this kind of thinking is a relic of systems programming days.  Also, programmers CAN handle this kind of thing.  "ID" is simply the process of *taking the necessary effort* to design a UI that won't cause customers to kill themselves.  Programmers can absolutely do this, but it takes effort; effort in an area that many programmers think is "beneath" them (ala documentation, maintaining systems, code documentation, etc).
Crimson Send private email
Thursday, August 31, 2006
 
 
If you wait till the back end it before you start "designing" the user interface, then you almost certainly WON'T be doing interaction design: merely graphical design (what fonts/colors/bitmaps should we use, where should this button be located, should it have round or sharp corners).

True interaction design deals with issues that affect the entire structure of the application (do we even need to this piece of imformation, or can we figure it out for ourselves). THAT is interaction design. You need a rough design of the interaction to generate the requirements that drive the back end design.

If you don't go through this process, you've still designed an interaction, but it's design by accident. And the design presented to the user (the "manifest model" in Cooper's terms) will likely be a thinly veiled version of the implementation model. Oh, the backend can't do what we need without this extra information, so we'll just add a dialog to get it from the user.
Stephen C. Steel Send private email
Thursday, August 31, 2006
 
 
RoR hype, meet reality.
D in PHX Send private email
Thursday, August 31, 2006
 
 
"RoR hype, meet reality."

How so? In their book "Getting Real", 37 Signals (the creators of Rails) advocate that you design the interface before you start programming (p92):

"Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first."

"Another reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show."
John Topley Send private email
Thursday, August 31, 2006
 
 
A big problem with designing the interface first is that when it is displayed to stakeholders everyone thinks that the product is complete.  This leads to a big reality gap in what appears to be done and what is really done, because many people cannot grok the pile of unimplemented use cases (or even undiscovered use cases).
Cade Roux Send private email
Thursday, August 31, 2006
 
 
Yes, you have to be very careful of that. Joel touched upon it in "The Iceberg Secret, Revealed": http://www.joelonsoftware.com/articles/fog0000000356.html
John Topley Send private email
Thursday, August 31, 2006
 
 
John,

The possible issue I see is that there are so many folks excited that they can develop an app fast that development moves too fast.

Should development start with the backend and go forward? Of course not.

I really believe that a ton of existing problems are related to no clear division between the role of frontend UI/ object designer/developer and backend developer.

Objects <> Data
D in PHX Send private email
Thursday, August 31, 2006
 
 
""A big problem with designing the interface first is that when it is displayed to stakeholders everyone thinks that the product is complete. ""

This is definitely a reality when dealing with non-technical users.  If you are a developer making a proposal, I'd almost recommend paper print outs over a pseudo-functional UI.  I've had to learn my lesson on this the hard way.
baus Send private email
Thursday, August 31, 2006
 
 
I strongly feel that it's the data/object model that drives everything else. Know what you're dealing with before you decide how you're going to deal with it.

Otherwise, it's like putting up the bricks before the framework (not a house builder, but you know what I mean).
Steve Hirsch Send private email
Thursday, August 31, 2006
 
 
I can totally see not wanting to worry about a bunch of CRUD wiring when you are trying to figure out a rough idea, but what I haven't seen is some way to generate a static layer from the current 'state' of a fullstack framework.

A framework that had that and that recommended folks transition to a static layer would make me sleep better at night (let me know if I missed one somewhere that does this!)
D in PHX Send private email
Thursday, August 31, 2006
 
 
The early stages of interaction design are probably best handled with low-tech prototypes: pencil sketchs on index cards and typical use-case scenarios.

Nobody is going to confuse a pencil sketch on an index card with an almost completed application. The other advantage is that people don't get too hung up on the graphic design issues (colours, fonts, layout). These are aspects which probably can be deferred, as they don't affect application structure too much.
Stephen C. Steel Send private email
Thursday, August 31, 2006
 
 
Waterfall for the UI design is a recipe for a lousy UI that doesn't work right.

You can NOT design a good UI a priori. You have to approach it through stepwise refinement, and a few stages of throwing it all out and starting over.
Meghraj Reddy
Thursday, August 31, 2006
 
 
Here's an interesting exchange between Alan Cooper and Kent Beck.

I'm a firm believer in doing design and in anything else that let's me improve the quality of the code before I actually write the code.  I'm not one for doing all of the design in one batch, though.  There has to be a closed loop feedback in place so that when learning occurs, the learning can be fed back to improve subsequent work and minimize rework.  I like iteration, but I definitely think design, experimentation, paper prototypes, and hallway usability studies all have a place in an iterative environment.
Lincoln Send private email
Thursday, August 31, 2006
 
 
Lincoln Send private email
Thursday, August 31, 2006
 
 
Interesting article Lincoln...even if I couldn't quite see all the hairs they were splitting. 

I guess I was thinking of "Interaction Design" as "Interface Design" too...though apparently Cooper meant something different.  Regardless, I didn't really understand the meaningfulness behind many of their analogies or why they disagreed on several issues. 

They tried to fix the argument in the "Change the organization vs assume the organization is broken" cage, though I'm not sure they succeeded.
Crimson Send private email
Thursday, August 31, 2006
 
 
Quoth Cooper:

"When an architect begins to define a building, he or she works very closely with the people who are buying the building to understand what the requirements are, and translate those requirements into a sketch of a solution. Then there's a lot of give-and-take between the occupants of the building and the architect in coming up with a viable solution. Usually, the architect at the sketch level will know enough not to design something that's an engineering problem. And if the architect does detect that there might be problems, he or she will consult with an engineer to make sure that he or she is not painting himself into a corner, technically speaking. At a certain point, the architect and the customer are going to achieve common ground. At that point, the architect turns those sketches into detailed drawings. Now, during the detailed-drawing phase, there's a lot more intense interaction between the architect and the engineer. The architect, you know, draws a span and calls in the engineer and says, how big a girder do I need to support this span? And there's a lot of detailed interaction between the two. This is precisely what happens in the world of good interaction design. "

Beautiful words.  :)
Christopher Hawkins Send private email
Friday, September 01, 2006
 
 
>You can NOT design a good UI a priori. You have to approach it through stepwise refinement, and a few stages of throwing it all out and starting over.

Well, I most certainly agree in the stepwise refinement process!

However, you have to distinguish between refining existing functions and features, and adding new ones.

When you say refinement, do you mean refine current features, or adding new features?

Most people mention changes to UI, but often they are actually talking about design changes to the application. You can change the UI, but not much change the features/functions.

UI changes in my projects are usually the result of ADDING MORE features.
 
So, lets admit right now that you can’t get perfect requirements. However this issue DOES NOT get one off of the hook in that you still must build good requirements.

Of course, I would rank good designs just as high as good requirements.

If you have a poor design, then the FANTASTIC stepwise refinement process is not possible. I find that without good design, then the whole stepwise process fast becomes a train wreak, or what we often call a death march. In a rotten project, changes can occur, but they seem to take forever and one NEVER reaches the goal of “acceptable closure”.

    What do I mean by “ acceptable closure” ?

By acceptable closure, that is a point at which the application becomes useable by the client. (and they like it!!!). This is that magical tipping point when you see a project start to function. This is one of the BEST feelings that any developer can experience. That instant, or tipping point when you know the project is actually going to work!! (I assume you folks still fear failure in projects??).

Of that magical day is also the instant when you begin to see requirements are missing!

This just happened to yesterday!
    
I am in the process of deploying a new version of my software (into Las Vegas of all places). The problem that came up was some invoice items are not supposed to be taxable.  This requirement NEVER came up during testing, or training.
 
Anyway, I was able to add a new invoice type with great ease, and also make the changes to the UI to accommodate this.
 
Adding this feature to meet customers requirements was EASY since I had a good design in the first place.

Simple story here is that I love stepwise refinement. The above change was enjoyable to add to the software due to a good design.

Without a good design, then refinement is painful.

You can’t come up with a good design without some decent requirements.

Thus, good designs, and good requirements are prerequisite for the stepwise refinement process.


Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Friday, September 01, 2006
 
 
"Without a good design, then refinement is painful.

You can’t come up with a good design without some decent requirements.

Thus, good designs, and good requirements are prerequisite for the stepwise refinement process."

More beautiful words.

This has been a pretty good evening at JoS, I've seen a lot of excellent posts.  I should get back to hanging out here more often.  Who needs to bill?  ;)
Christopher Hawkins Send private email
Friday, September 01, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz