If you want your developers to be productive, learn to draw.
Working with two non-technical cofounders has presented some challenges when it comes to design, especially as a developer who has really only been playing the role of designer out of necessity. We started work on University Niche back in January, and one of our very first meetings was spent figuring out how we wanted the site to look and function. These are my notes from that meeting, based on the discussions between my cofounders and myself:
- Sidebar on the left with all the properties, logo
- Sort options above list of properties
- The rest of the page is just the map
- Really simple & intuitive
- Info on left, picture on right?
- Hierarchical- Address on top, more specific going down
- Important info in individual boxes? Consistent for users to quickly get feel for property
- Description and amenities as separate tabs
- Big call to action for contact
- Auto-rotate through images?
- Something cool for the background. Satellite imagery of house?
With these notes, and feeling like there was some sort of shared aesthetic consciousness between the three of us, I got to work.
This is what I came up with:
And it looked like shit. But this was our MVP. It was our baby. So we stuck with it while we spent time figuring out our business plan and onboarding students and landlords.
Then, in the beginning of March, after getting feedback online and from approaching random strangers in coffee shops, as well as some much-needed usability testing by some inebriated friends, the three of us sat down again with plans to make some major design changes to the site. But this time, we took a piece of advice from our advisor, who suggested that instead of talking about design and going at it from notes, we sit down and just draw it out.
Of course, this seems like common sense. Every designer does wireframes. But, as three non-designers trying to tackle a design problem, it was something we had just never really thought applied to us. But it would completely change the way we handled “design by committee.”
So we sat down with a stack of white paper and a pencil and got to work. This was the result after three two-hour sessions spent wireframing in a Starbucks:
It wasn’t pretty, it wasn’t precise. Hell, it didn’t even have a whole lot of information for being the final result of six hours of work. But as a developer used to visualizing projects in terms of the interactions between interfaces–how everything fits together and connects–rather than as a static picture, this resulted in a much, much stronger end product.
Of course, the design isn’t finished. We’re still constantly changing things. But what’s interesting is that we all agree that the new design is pretty close to what we spent that very first meeting trying to describe. It just took a pencil and paper for us to get there.
So if you’re someone working with designers or developers, rather than trying to put a design idea into words, just draw it out. Even if the drawing sucks, it’ll help your developers understand your idea, rather than trying to translate your words into design.