For those who are not certain what we mean by “wireframe” in the context of software, here’s a quick description:
The idea of a wireframe is to quickly and cheaply create something that represents some software to be built. The principle is that software takes time and highly skilled resources to create something, so if that something is wrong, then time and money has been wasted. Thus, the idea of the wireframe is to prevent this waste. In short a wireframe is a communication tool for the development team.
A wireframe can be hand sketches or drawings done on a computer, and can be created by anyone, although the initial wireframes are usually created by the person who gave birth to the project.
The idea of the wireframe makes a lot of sense, but with today’s software development tools and using techniques like Customer Driven Development and Agile Project Management, it’s not so clear cut when to employ this technique.
For example I’ve seen ads stating “Develop better software with wireframes”, leading the reader to believe if they buy this wireframing tool, their developers will love them for it and they will build better solutions.
The thing is, the wireframe strategy assumes the wireframe creator knows exactly what the end result should be like. But the reality of software is that things can look great on paper (in theory) but suck when actually implemented, thus requiring redesigns anyway. In addition, I’ve experienced projects where more time was spent creating the wireframe drawings than it would have taken to write the software.
What we’ve concluded is there’s a time for wireframing and there’s a time to rely on the programmers and their skill and intuition. Essentially, what we’ve noticed is that if the developers are not good communicators, collaboration is weak and there aren’t good communication tools in place, the wireframe is an important tool. They will help the project owner to convey her ideas with the programmers.
If, on the other hand, communication and collaboration is open, vibrant with regular meetings and good tools to share thoughts and ideas, the wireframe actually adds cost and waste to the project.
KENOVA, for example, has built a tool, Syncromatic®, to manage its software development projects. It supports the ability for any team member to post their thoughts / ideas, sketches, screen shots, etc. It’s common for team members to post a screen shot with a comment, something like “I really like the way this website is listing these products and displays its menus…let’s do something like this.” And for programmers to do some coding and request immediate feedback before spending any more time, so they don’t go down the wrong path.
So the takeaway from the blog is; if the development team prefers to hide during development and isn’t great at communication, then getting a tool to help you create wireframes (such as MS Visio) is probably a good investment. On the other hand, if the team is more like the KENOVA development team, then there’s no need to invest in wireframing.
