Fake It. Trash It. Build It.
42floors.com
Fake It. Trash It. Build It.
1–9 of 9 posts
Re: Fake It. Trash It. Build It.
#2It's good that this worked for them, but I think it's a bit questionable to assume that because it worked in this case it's a good idea (or even an idea at all instead of just a complete dismissal of planning and structure).
There's a lot of different ideas about how much is too much in terms of up-front design, but to me this goes a little too far to be called anything but chaos with a chance happy ending.
Re: Fake It. Trash It. Build It.
#3Very nice model, I never thought of it that way. I wonder how this technique would scale to a larger design project.
Re: Fake It. Trash It. Build It.
#4It was incredibly refreshing to read about this level of trust being put in the engineer/developer who needs to make it work right for the long haul. Version 2.0 is almost always the one you wished you launched with and this is a great way to get there.
Re: Fake It. Trash It. Build It.
#5It's good that this worked for them, but I think it's a bit questionable to assume that because it worked in this case it's a good idea (or even an idea at all instead of just a complete dismissal of planning and structure). There's a lot of different ideas about how much is too much in terms of up-front design, but to me this goes a little too far to be called anything but chaos with a chance happy ending.
Your skepticism is very warranted. I was skeptical at first too, but we've used this method a few times now. It seems to help everyone to see it, then build it.
Re: Fake It. Trash It. Build It.
#6It's good that this worked for them, but I think it's a bit questionable to assume that because it worked in this case it's a good idea (or even an idea at all instead of just a complete dismissal of planning and structure). There's a lot of different ideas about how much is too much in terms of up-front design, but to me this goes a little too far to be called anything but chaos with a chance happy ending.
Does it though? I think he might be getting to the core of something important: that trashing the entire thing leaves in your brain the essence, that important thing that we drive so hard to make simple and obvious. Maybe this whole process is a hack to getting at that, even if it seems chaotic and stressful.
Re: Fake It. Trash It. Build It.
#7I'd say that your HTML prototype acted as your wire frame. It does seem to have guided the engineers hand. Nothing wrong with that though. I tend to do a similar process a lot on my own projects. Being solo, and not much of a designer, I'm anxious to jump into the HTML/CSS/backend process. Then when I'm done, I'll call in a designer to "make it pretty", and they'll usually follow a similar layout.
Re: Fake It. Trash It. Build It.
#8It's good that this worked for them, but I think it's a bit questionable to assume that because it worked in this case it's a good idea (or even an idea at all instead of just a complete dismissal of planning and structure). There's a lot of different ideas about how much is too much in terms of up-front design, but to me this goes a little too far to be called anything but chaos with a chance happy ending.
It's an old practice - whether you call it a proof of concept, pilot or a prototype, the tough part is recognising it as such and to be willing to throw it out.
In the enterprise world this is really difficult because managers hate seeing those hours produce seemingly nothing, when in fact the product that follows will inevitably be orders of magnitude better in all respects than the throw-away that preceded it. Personally, the single biggest payoff I've gained from this approach is a cleaner architecture that cleanly separates concerns, allowing individual components to be refined even further.
Re: Fake It. Trash It. Build It.
#9I'd say that your HTML prototype acted as your wire frame. It does seem to have guided the engineers hand. Nothing wrong with that though. I tend to do a similar process a lot on my own projects. Being solo, and not much of a designer, I'm anxious to jump into the HTML/CSS/backend process. Then when I'm done, I'll call in a designer to "make it pretty", and they'll usually follow a similar layout.
The important step I think here is that the developer not used the initial HTML prototype as a template when building the application.
He just looked at it and produced code that output code who have a similar visual appearance but probably with different HTML structure who work well with the code.
If the code was written just to fill some holes in the original prototype, basically replacing some hard-coded strings, the developer would have less liberty on how to code lending to something less efficient and less elegant.