Speaking Nerd: Communicating With Developers

by Josh Sandberg

There’s been quite a bit of debate on this blog (e.g., here and here) about whether or not it’s important for business folk to learn programming. Personally, I think that gaining a least a basic understanding of how things are architected “under the hood” will pay dividends throughout your startup career. But either way – and especially if you don’t have any programming experience yourself – you’ll need to be communicating your vision with your development team, and knowing how to do this effectively will (a) rapidly increase your iteration speed, (b) help you realize your actual vision, as opposed to some sub-par version of it, and (c) make your developers much happier.

Step one is good mockups. There are several tools out there to help with this process, the best known of which is Balsamiq. They’ll make your sketches prettier and save you some time drawing rectangles, as well as give you handy examples of some common ways to display and interact with data (user interface elements). At the end of the day it doesn’t really matter how pretty your specs are, but do invest time into thinking about what information you want to display on each page (and in each element) and how best to convey it: this should be one of the key parts of your product vision. Entire startups can be built out of thinking of better ways to interact of data – for a recent example, just take a look at Hipmunk. Don’t just throw everything you think you might need in and plan to pull out bits later: simplicity takes a lot more work, but is crucial to a good user experience.

Step two is good specs. This means thinking through every one of the actions that a user can take on each page of the site, and how the logic should flow. The hard (but crucial!) part is making sure you consider and address every possibility: what happens if a user clicks on this button when she is logged in? What about if she isn’t logged in? What if he hasn’t set up a particular option yet? If the user’s entering data, what filters are necessary to determine if the data is valid, and what do you do if it’s not? In my experience, one of the big differentiators between mediocre specs and great ones is the coverage they have of these edge cases. Force yourself to think of every possible scenario, and put down everything in excruciating detail. You may think many of these are trivial, but whoever’s implementing your spec is either (a) going to have to figure out how to deal with these situations himself, which slows down development and can lead to very inconsistent design choices, or (b) is going to miss or ignore a possible use case, which leads to bugs and poor user experiences down the road.  It’s also important to make sure you’re specific about what to do in every case, down to the level of what data to display/collect/store/modify, what dialog to show the user, and where to take the user next. Otherwise what seems so obvious to you can often get lost in translation, and you’ll wonder how the final output could be so different from your initial vision.

Finally, before the coding ever begins, make sure you have a high-level discussion with your lead developer(s) about the consequences of your design decisions. Make sure you understand what parts are difficult (and why), and what’s easy. For the stuff that’s hard, brainstorm if there’s an alternative solution that eliminates much of the complexity, or if there’s some way to test the utility of the feature before implementation (maybe a smoke test). Agree on a mutual prioritization and timeline. And once development does begin, make sure you’re available for rapid feedback & get your hands on iterations as early as possible.

For others with experience in product design / management / interfacing with developers: what are the techniques & tips you have found particularly useful?