Fog Creek Software
Discussion Board

UI Driven Design

Our company engages in this 'UI Driven Design' construct so often that I feel it's seriously damaging any firm process definition or use case analysis that are completed after the initial 'UI Driven Design'. Basically, producing software that's poorly defined and documented.

Besides complaining during these design sessions, what can one do to prevent this? Or, is this something positive (I don't think so)?

Wednesday, January 30, 2002

I'd never heard of UI-Driven Design as a formal technique before, just a de facto description. Can you tell us more about how it's hindering you?

I just finished working on a project that was de facto UI driven, because that was the only spec that was written. The UI was designed by the useability group, who does not think about software in the same terms. When they request fixes, it's usually an incomplete solution, because they stop with the UI.

What I've found helpful is to ask for the specific information I need, and along the way slip in  use cases and functional specs. Most people outside engineering don't think about the system in terms of use cases or error conditions, so I help them. 

For instance, a user is making a purchase with a credit card, and already has a card on record. They want to use a different card, or modify their existing info.  The  incomplete change request was "just put a link here".

The approach I took was to say "ok, let's put the link in. Now you know, and I know, that users will make mistakes. How shall we handle them? Let's say they modify a card and authorization fails. What happens to the credit card on file? blah blah blah..."

Once we arrive at a solution, I write down the description for each case, the UI description, and the functional requirements (e.g. "We will remove the old card if and only if a valid new card replaces it, in case there are billing charges pending", or "if we discover the old card is expired we will mark it in the database so we know to stop providing services as soon as possible".)
For the non-engineers a good user experience and  billing and legal considerations are compelling motivators.

The solution is then added to the bug report so QA knows what the changed behavior is, and we can refer back to it the next time someone proposes a change.

It's too early to tell if it will catch on, but it beats being silently frustrated.

Wednesday, January 30, 2002

Sound's like the planning game from XP will help...if you can get the business owner to play.

Of course, you won't.  THey'll just think that if you define a new UI feature, everything else will be easy.  Even if, oh, they decide to change the4 HTML the day before a demo and wonder why everything is broken.  Or wonder why when they want to use Tabs in HTML, it takes so much longer than tabs in a window application.  They won't realize that you have to understand 
The technology you are using well enough to tailor the UI.  And when you ty to tell them, they will see you as a trouble maker and not a team player.  And will work around you, going directly to your subordinates to get features implemented that you were not willing to implement because they distract from other stuff you already agreed to and arte 1/2 implemented and they won't say to not put those in as well, and you will work until Midnight getting it implemented.  Then Your integrated Code base will break aprt into little pools of individual styles, and people will start breaking each others code.

Thanks for giving me a chance to get that off my back.

Anyway, as I was saying, the planning game from Extreme Programming is waht you need.  THe requirements people sit in a room with the developers.  They say, I want X.  where X is some feature.  Now you say, who is going to implement it.  Everyone scratches their head and looks around nervously.  Then one brave soul says, "We don't under stand, X,  can we talk through it?"  So you Break X down in to its component parts.  X1 and X2 and Even the revolutionary X3.  X1 is really similar to Q1, so the person who wrote Q1 says, I can do that.  Someone else says, If We stoip doing Q4, we can do X2.  They business people look mad, and shift there eyes and say, no, Q4 is  more important.  FInally you say, well, something has to slip[, what is it going to be.

You can't put 20 punds of manure in a 2 pound bag.  Well yoiu can, once....

Adam Younga
Wednesday, January 30, 2002

I've been on a project where the planning game worked Really Well. We ended up in the alarming situation where we delivered the product late, and missing several features (from the original estimate), but the customer was smiling because he'd been in control all the way, and to him, we were on time and we'd finished everything.

I've also been on a project where the planning game consisted of the following scenario:

[Programmer puts cards on table...]

[Programmer] Well, in the next two weeks, we can do fifteen points of work. All the cards have point values on them, just pick the ones that you want done in the next two weeks.

[Customer] I want them all done.

[Programmer] No, we can't do that. We can only do fifteen points worth. We want you to choose them, because that way we're doing what you think is most important.

[Customer] And what's important is that everything gets done.

[Programmer] What you're asking is impossible.

[Customer] I couldn't care less. If it's too hard, you're just going to have to work weekends.

[Programmer] It's two weeks. If we worked weekends, we still wouldn't get more than one more card done. If we kept working weekends after that, we'd burn out and slow down anyway.

[Customer] What part of "I want them all done" don't you understand?

Charles Miller
Thursday, January 31, 2002

There's also the response I've gotten from middle management: "Well, do what you can in the next two weeks, but I've got to tell my boss that you're going to do everything."

In which case, the best response I've found is to bill as much as possible and try to quit before the disaster becomes apparent.

Mike Gunderloy
Thursday, January 31, 2002

Your only option in that case is to do it all - badly.

I have often been surprised by what customers will accept as long as they can tick off every feature they were after.

Sure they come back moaning about it not being very good, but your deadline is gone by then, and you delivered - and that's often more important than a partial delivery or none at all.

Yes, I do think this is insane BTW.

Friday, February 1, 2002

As a wise friend of mine once observed, "if you want something real bad, that's exactly how you're going to get it: real bad".

Friday, February 1, 2002

' There's also the response I've gotten from middle management: "Well, do what you can in the next two weeks, but I've got to tell my boss that you're going to do everything." '


Wow.  I have certainly been there!

Just one scant year ago, I sat in a meeting with the principals of my company and was assigned to lead the team responsible for building and delivering an enterprise-scale web application in the time frame of - get this - two weeks.

It seems the salesman for that account had sold vaporware.  It was a $500,000 deal, so the company figured, let's give it a shot!  When the company is facing an impossible deadline or a project that is off track, that's when I get assigned to it (shades of "I am Viktor, the Cleaner" from La Femme Nikita.  Fantastic movie, if you haven't already seen it).

As if that weren't already bad enough, it gets better.

To make the deliverable, we writing code on the plane.  Once on the ground we integrated the build on our laptops in the back of the rental car on the way to the client.

Nothing wored the way it had been sold.  Put bluntly, it was a Big Fucking Mess (TM).  But it was good enough (barely!) to satisfy the letter of the contract requirements and get us paid for the first phase.

I asked for (and received) a transfer to another project (which, unfortunately, turned out to be EXACTLY like the one I had left, but that's a different story).

I kept in touch with the lead programmer who replaced me - the ensuing phases wentg about as well as the first one.  And the sad/funny part is, once everything was up it turned out that the company lost money on the deal.

Classic quote from one of the clients (which proves out Joel's Iceberg Theory AND supports the title of this topic):  "It's only 8 screens - why can't you make it WORK?!?"


Wednesday, February 20, 2002

*  Recent Topics

*  Fog Creek Home