Creating something new is exciting, but don’t get carried away.
Wednesday, January 25th, 2012This post originally appeared on the Community Knowledge Transfer website.
Creating something new is exciting.
Hopefully, you’ll be so excited by your idea that dopamine will be rushing through your body, and you’ll be falling over yourself with energy and eagerness to get stuck in, hire a developer, and get making the thing.
Before we do anything, however, let’s take a deep breath, count to 10 (don’t worry, that’s only two in binary), and look at some of the techniques which help make sure that your new project runs smoothly.
First of all, do you actually know what you want making?
You might be able to pitch the idea in a lift to raise funding, or sell the concept to someone with wavy hands and waggling eyebrows, but do you know what the thing you’re making will actually do, screen by screen, click by click?
If not, you probably need to spend some time developing the ‘User Experience’ – as in “what will the user experience when they use my application”. What do they see when they first arrive? How many articles appear on the homepage? How do they register a new account? What happens if they’ve already got an account and try to register again?
Depending on the size of your idea, this project could be relatively quick, or take a few days exploring all of the features and functionality. I often use post-it notes to quickly list out all of the features, and group them together per screen, perhaps using a large wall as a working space. It allows you to very quickly move features and functionality around, and encourages you to think quickly and sketchily, rather than focusing on detail. Drawing up each screen can come at a later date.
It is always best to involve your developer in this user experience design process (or UXD, if you want to impress others with abbreviations), so they understand the reasons behind each decision, and when they come to create each screen, they understand how things connect and why.
It is even better to involve the end users in this UXD process, as they’ll often provide many wonderful insights, suggestions and comments you might never have considered.
In fact, the more collaboration at this stage the better, as its easier to discuss around post-it notes than change designs and code.
Once you have this user experience piece, and everyone is roughly in agreement with what the application will do, your designer can go away and make it beautiful, and your developer can go away and write up a specification.
This specification doesn’t need to be hundreds of pages long, perhaps just annotated drawings if you created screen by screen drawings in the UXD phase, or short ‘user stories’ describing what the system will do, hopefully in plain and simple English.
If you don’t understand what the specification is saying, it’s a useless document. Don’t encourage someone to write something just to tick a box, as its waste of time for both parties; create something that acts as a living guide for making sure you’re creating what you need and want.
And now, the exciting part, the coding begins.
The most important thing to make sure that DOESN’T happen is that your developer just locks himself or herself away in a room for several months, ‘getting it done’, and presents you with your application in a ‘tada!’ moment.
If you were building a house, you’d want to be on site every week, talking with the foreman, checking the plans, making sure any necessary changes are included, or any unforeseen circumstances are dealt with suitably. Creating software is no different.
At the start of the project sit down together and work out the order in which things are done, and rough time-scales for how long each piece of functionality should take to build. Think back to the post-it notes, and work out which parts are the most important to see first (either because they’re more complex or because you need to start demonstrating it).
Again, the UXD will have defined most of the elements of your application, so you use that as a guideline. Your developer will be able to guide you on a sensible order (you can’t build a roof before the walls in a house, and software is similar to a certain extent).
Plan with your developer to have a weekly review, where you look at the functionality that was built that week, and discuss what will be built the following week, in case things have changed, or the developer has any questions. Ideally, in these reviews, everything should have been tested and working, so you see actual functionality, rather than half-completed code.
Sometimes, things won’t be exactly what you expected, or once you’ve seen it working, you might realise some elements need to change, but hopefully, they’ll be small things (as there was only one week of work that passed since you reviewed it last).
These weekly reviews will pass, and your software will continue to grow, in the order of priority that you agreed up front, and hopefully to schedule (or at the very worst, each week, you’ll know whether your deadlines are slipping or not!)
At some point, you’ll have a version of your application that you’re happy to share with others, and you can start testing.
Again, get the UXD documents out (see how useful they are??), and review what you originally agreed upon against what you what you’ve ended up with. Apart from where you’ve made decisions to change things along the way, you have a wonderful tool to check you haven’t forgotten anything, and your application works as it should.
And finally, once everything has been built and tested, your developer will be able to help you launch the application, and make it publicly accessible. Before this happens, it is really important to agree with your developer how support will work. If something breaks, how quickly will they react to fix it (and for how long will they do this for free?) If you need something changing, what is the process for asking that to happen? How long notice might they need for future updates?
You’ll see that the key to running a successful project is good and regular communication, and getting the original user experience agreed between you and your developer, and making sure that people are involved from early on in the project, not just when they need to be doing ‘their bit’.
And when you make a billion pounds from your application, don’t forget to buy your developer a beer or two.
