FLiP-ping Out on Process

I've been in my current job for nearly a year now, and I've been strongly advocating a move to the FLiP methodology for most of that time. Responses to the idea have varied from strong support amongst the developers and project managers, to more cautious support from the business owners who aren't sure about buy-in from clients, to "cautious-agreement-in-principle-but-not-yet-convinced" from consultants who have yet to see it properly implemented across an entire project, and may feel like it restricts what they can and can't ask for.

Since we agreed a few months ago to give it a try, we've had a couple of attempts at using FLiP on projects that I haven't been involved in, but somehow it hasn't quite worked out as planned - and in both cases I'm convinced that the problem wasn't the process, it was that we hadn't applied the process thoroughly enough.

In the first case, it was a major upgrade to an existing application. This application was coded years ago, in CF5, in a page-based style - no Fusebox or any other methodology - and no-one could claim to have a full grasp of the existing functionality. It turned out that what had been signed off as a Prototype was only about a a small percentage of the final application - more like a design mock-up of about three or four pages. As a result, it went seriously over budget and a couple of months after go-live, we're still discovering features that were in the original version but not in the new release, and we're still fixing issues on a regular basis.

The second case was much better - a proof-of-concept (i.e. didn't have to be production quality) app that was a fresh build, but on a tight time scale. Again, I wasn't really involved in the development, just on a technical advisory level, but I tried to ensure that we followed a better process.

Anyway, on the day of the all-important demo to the client, I was feverishly coding away on another project when I heard the main consultant behind me saying to a designer:

"Can we change that font? Can we bring this out more and change that colour there...?"

When I interjected with:

"these are things that should have been sorted out in the prototype phase!"

the consultant replied

"Yeah, but the thing is, we couldn't really get a feel of the flow from the prototype, and it's been such a tight timescale...."

.....so the process was circumvented "just this once".....

The thing is, it's a fair point that he made, but "just this once" is a slippery slope. Before you know it, there'll be another "just this once", then another, and then it becomes the norm rather than the exception.

In the end, the client demo came and went very smoothly - the client was actually blown away by what we'd developed. He was expecting an extremely rough proof-of-concept, and we gave him a damn-near finished app.

There are lessons we can learn in relation to the consultants issues for the next project:

Timescale Issues
The tightness of the deadline shouldn't really be an issue. I've successfully used a full FLiP wireframe/prototype/build process on a site with a timescale of ONE AFTERNOON before, and found it an invaluable tool for focussing the minds of developers and project managers/business owners/clients alike onto

• what are we building?
• (just as important) what AREN'T we building?
• how should it look?
• how should it behave?

As it turned out, we used the actual prototype itself for 90% of that particular app, with just a bit more back-end added. But we probably wouldn't have known that if we hadn't gone through the process.

Flow and Feel
If you couldn't really get a feel of the flow of the app from the prototype, then the prototype wasn't as complete as it could/should have been. If you need to highlight a newly-added element, for instance, then you should have a page on the prototype that shows this - either a separate page, or a simple parameter passed to the existing page.

Any time the finished app will need to present something differently to the user, this should be reflected in the prototype. This may be tedious, and may feel like nit-picking, but it's important - the process of implementing this in the prototype means that you've

• identified a feature that needs to be in the final app
• thought about - and got feedback on - how it's going to look and behave
• at least thought about how it's actually going to be implemented

In other words, the prototype has served its purpose.

If there are "implied" features that aren't in the prototype, then you're potentially leaving yourself a banana skin for later, when you may discover that what you thought was a simple tweak turns out to be a large development with, for instance, lots of dynamically-generated javascript / XMLHttpRequest() / DHTML niftiness.

If the reason for not doing it in the prototype was time constraints, then you may have a problem - if it's going to impact your deadline to just mock it up in HTML, then what does that tell you about the final dynamic version?

I've actually come round to thinking of prototypes not as mock-ups per-se, but as front-end development. It's a bit of a subtle mental shift, but it helps me to justify the time they take to myself and others - and I've yet to come across a project where a decent prototype has been done, but I can't re-use the front-end code in the finished app. Sure, you'll probably need to change it slightly and add more CF, etc, but I've never felt like it was wasted time.