So you’ve got a great idea, but no-one in your team is a coder. What can you do at a hackathon that is both productive and shows of the potential of your idea well? This post is a very brief introduction to several things you can do – it should be easy to find out more on these topics online or from others at the event.
The first thing is to develop the idea more to work out all the details. Some tools for doing this are wireframes and personas.
With wireframes, the idea is to draw how each screen of your website or app will look like and how users will move between screens. They don’t have to look good; this is about the functionality. In fact, it helps if they look plain and simple as then people looking at them concentrate on the functionality and not on whether they like the particular graphic you have used. Here’s an example:
With Personas, the idea is to build up an idea of who will use your website or app. Invent fictional characters and give them as many details as you need to make them realistic. Make up multiple characters if needed.
The point of wireframes and personas is to think in detail about exactly how people will use your service, and what their motivations for doing so will be. You will hopefully surface many questions about small details that you can answer. This will serve two purposes: make your idea look more realistic when you present it and make it more likely you will attract others to your team. Programmers hear a lot of people who say “I’ve got an idea” so they tend to ignore them – if you can show you have thought through your idea carefully they are more likely to listen to you.
You could also work on the design and marketing message – how will it look and how will you attract people to it? This will help your presentation look good, but will also help you refine your idea. If you can’t come up with a quick simple marketing message and a way to explain to people what your idea is, then your idea may be too complicated and may need simplification.
Other possibilities to work on over the event is to work out what would make a really effective demonstration for your idea – can you fake something? Maybe you have a service where people submit some information to a website then get emailed some other information – so set up a google docs spreadsheet with a form to collect information, then have a team member sit there and manually send an email in reply. The person you are demoing your service to doesn’t need to know it’s not automatic.
Can you conduct some kind of user research – show your mockups and fake demos to some people from your target market? You should learn lots from this.
Lastly, bear in mind that even with teams who are programming furiously* no-one expects a finished product over a single event. So don’t try. Concentrate on exploring the idea in more depth and showing off effectively what you have done in a brilliant presentation. Remember that at many events your all too short presentation is all you will be judged on, so if you’re approaching the end of the event and you have several different things to do, do the thing that will help your demonstration look best (this applies to coders pondering what feature to do next too).
Above all have fun! Hopefully you will leave with a more in-depth idea, some great feedback to encourage you and maybe even a great team too for the future.
* In fact, sometimes the teams who are coding furiously are at disadvantage, as they have started coding before they really know all the details of the problem. They are at risk of coding the wrong thing. So sometimes it’s good to do a lot of work researching things before anyone codes a single line.