Site icon Nick Bradbury

Wireframing and the Reformed Cowboy Coder

Wireframing – sketching out the interface of your software with a focus on what it does rather than how it looks – was something I used to avoid.

I figured I’d end up laying out the interface in my programming IDE anyway, so why make extra work for myself? Just skip the wireframes and go straight to the IDE.

Besides, weren’t wireframes only used by teams in order to collaborate on design? I was a one-person company when I created HomeSite, TopStyle and FeedDemon, so wireframes seemed pointless.

But I was recently tasked with designing the next version of Glassboard, and I’m not the only one working on that so wireframes suddenly made sense.

And you know what? I should’ve relied on wireframes all along.

Sure, it’s extra work. And it can be pretty tiresome, too. It took me a lot longer to wireframe the app than I thought it would.

But once I was done, seeing an overview of every screen turned out to be enormously helpful. I better understand the relationships between those screens than I would have if I stuck with my "cowboy coder" ways and designed in the IDE.

Plus, writing out the purpose of every major area helped me clarify the UI and UX. I ended up re-thinking a lot of initial design decisions after I had trouble explaining them.

So consider me a reformed cowboy coder. I was wrong to think that only teams need to wireframe their software. The primary benefits I got from wireframing would’ve helped me even when I developed alone.

PS: I’ll probably be asked which wireframing tool I use, so I’ll say here that after trying a number of tools I chose Balsamiq Mockups. I like how its "lo-fi" approach reinforces the idea that you’re sketching out your design rather than deciding every last detail.

Exit mobile version