This weekend, I was building houses for developers. As we were framing the first house, I suggested that the location of the door might be improved if it were shifted from where the original plans stated it should be. After a very short debate, both the product owner and the developer agreed, and the updates for the plans began.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As the new designs started to emerge, we began to understand that by moving the door we’d have a 3 to 5 inch strip of wall between the edge of the wall and the door. This created a problem. Since the entire front of the house was originally whiteboard, it no longer made sense financially or functionally to have a three to five inch strip of whiteboard: you’d never write on that strip and you’d end up with a lot of scrap whiteboard if you were to cut for that space.
Let me lay out the scene in a different way and you tell me if this all seems familiar:
- A product owner, who has a clear internal vision of what he wants, and strong opinions.
- A developer, who knows what is and is not possible, and the trade-offs involved in what’s being asked for.
- A tester or potential user, whose opinion is occasionally asked for, but whose feedback is more often than not, given knowing it’s going to cause friction.
- On the front of the house we require a door, a light, and a space for whiteboard.
- We have a standard that says anywhere there’s a seam between building materials we need to put up trim to make it look nice.
What’s open for debate:
- The size and placement of the door, the light, and the whiteboard, all with the goal of balancing functionality and aesthetics.
When you think about the problem in these terms, it’s a classic software development problem. And after thirty minutes of discussing what our options were to solve this problem, I decided to leverage a classic software development solution to this problem — I suggested that the product owner and the developer create a mock-up that they could interact with.
Using various building supplies laying around our workspace, we did the following:
- We laid one of the framed out walls on the flat on the floor.
- On top of that, we laid out two sheets of siding and a sheet of whiteboard.
- On top of that, we laid out our door, trim, and a cordless drill which represented our light fixture.
We had a full-size very rough model of what we were talking about. At this point, instead of going back and forth trying to discuss the trade-offs in design by saying things like “If you move the door over three inches you’ll…<insert bad thing here>” the product owner and developer could just move stuff, and the trade-offs were immediately apparent. No detailed explanations where required — everyone was on the same page.
When most people think of wire framing, paper prototypes, or other forms of interface mock-ups, I think they envision expensive tools and long lead times so trendy designers can get it “just right.” And sometimes that’s true. But there’s value having the ability to pull together something physical — something you can interact with — in a quick and dirty way.
Once we made our final decision, the developer went back and updated the formal plans which provided a wire — frame picture of the final house with precise measurements. You still need those final design specs. But you also need tools that allow for faster collaboration. You need the ability for the product owner and the developer to push and pull on the same objects at the same time.
What do you use to do that type of rapid prototyping on your projects?