December has been a busy month for us – so we’re going to re-run an article that you may have missed. You might want to forward this one to an engineer you know!
The majority of our customers are not software engineers. Instead, they are UX professionals, designers, business analysts, executives and project managers. We do have some effusive engineer customers, who are almost always part of a larger team using ProtoShare to reduce rework.
This post is an appeal to software engineers: Add prototyping to your toolkit. It will save you time, you’ll massively reduce rework, and you’ll end up a rockstar on your team.
We’re an agile shop. Our features start out as simple user stories. Our UX’ers will prototype, research, review and test implementations of user stories before they get packaged into a sprint. We don’t try to specify every last detail of a solution, we just try to get agreement on concepts, directions and limitations.
Often, fleshed-out user stories can go right to code. Fairly frequently though, issues arise early in a sprint: technology favors one implementation over another, unforeseen edge cases arise or other information is missing.
This is where prototyping as one of the arrows in a developers quiver can come to the rescue. Either by modifying someone else’s prototype, asking a question or building a prototype yourself, you can save time, reduce ambiguity and better satisfy your stakeholders.
For example, we wanted to expand our appearance bar to encompass all of the appearance settings supported by ProtoShare. We knew that some real estate would have to come from somewhere, but decided to leave some decisions up to the implementation team. After reviewing all of the information in the user story and associated prototypes, engineering realized there were at least three possible paths to completion, some involving significantly more work than others.
Knowing that any initial implementation would require revisions, and that even choosing the ‘quickest’ implementation still probably meant 2-3 days of wasted effort if it turned out to be wrong, the decision to invest 2-4 hours of time prototyping was a no brainer.
We ended up with three prototypes, and were able to have important stakeholders review these, look at them in context and choose the best path forward.
So why should engineers prototype? Because often, prototyping is overwhelmingly faster, and it’s the best way to communicate with and engage your stakeholders. Try it for yourself. Let us know how prototyping helps you as an engineer.