Tags

, , , , ,

This is in many ways a companion piece to my previous post it started out as a version for LinkedIn, but rapidly evolved into something with a different emphasis.

The internet revolution has changed the landscape of our lives, and yet the disruption has only just started. Existing ways of doing business are largely unchanged from the way they were 20 years ago. Hilarious disconnects exist all over, when ultra-slick digital-only processes crash into messy physical transactions.

There is a reason for this. Coders like to code – they like the safe, ordered, complicated-but-not-truly-complex world of programming. And coders are the ones who feel empowered to invent digital businesses. So, of course, the early digital businesses are the ones that can be achieved with purely digital workflows, and don’t require the startup team ever to leave their own world.

The rest of us might have ideas about improved approaches to some aspect of life, that could be turned into a business, but get stuck at the point where the idea needs to put into digital form. At this point we either need to recruit a co-founder who has coding skills, or take the risk of employing an outside team. Both of these options are scary because for a digital business, the idea, however brilliant, is utterly dependent on even quite small details of the implementation.

We’ve all experienced it – downloading an app that promises to resolve some particular pain point and then discovering that, because this button does X when you expect it to do Y, the thing is effectively useless. The idea sold you the app but the implementation undermines the promise so much that the next time your device runs out of space, you realise that it’s one of those apps you never use, and delete it.

So us non-coders know intuitively that just because we’ve got a great idea, without having the coding skills ‘in-house’ the risks of setting out to make it real are enormous. And thus many of us give up before we get started – our idea gets relegated to a topic of conversation, or worse, we end up saying ‘.. but I thought of that!’ when someone else eventually makes it work.

Well I think this needs to end – and I have good news. There are tools and techniques out there that anyone can use, that can allow you to take a good idea a long way along the road towards a first working implementation – without needing to cosy up to a coder.

Don’t get me wrong – proper coders will be needed! Their advice, skills, expertise and capacities will be crucial to any viable digital business. But if you need to, and are prepared to work at it (and frankly, if you’re not prepared to, don’t bother starting…), you can get yourself to the point where you have a working prototype that can act as its own functional specification – something you can give to a coder, or an offshore out-sourcing team, and say;

Make me something that does this, exactly like this – that looks like this, that does what this does – that works fast and scales well.

– without it being a joke.

How do I know? Because I’ve just done exactly that. Over the last 15 months, my co-founder – a physiotherapist – and myself – an architect – have gone from some doodles to a fully working tool for physiotherapists and their clients – therapy-smarter.

And we’ve done it with only a few days freelance support, and for less than £5000 (not including the exercise video content, which is another shoestring story).

We used two key tools:

ONE: Prototyping on paper: there are lots of blog posts out there that tell you to start out by drawing simple mock-ups of all the screens used in your app on paper, and simply moving from one to the next as you chart a user’s progress.

They’re right – this is a great approach – you can use it for immediate user testing on friends and family. But to get the best value from it, you can use those same paper sketches to make something that looks and feels like a real app. Popapp and balsamiq are the two best known tools for this. You scan in your sketches, upload them to the site, and then simply draw hotspots over your buttons which can link to the next relevant sketch.

Using this simple tool, you can make something that feels like a real application, which works on your phone or in a web browser, so that it really engages test users, so that they can give you the feedback you desperately need. After using our version of this, some users expected that it was a real working app – even though it was obviously hand drawn – it’s that convincing.

Here’s a simple example which I made as a suggestion for ways of getting people attending a Climate Change march to become more actively involved. You can do as many versions of this as you like – testing and refining the look, feel, and user journey of all aspects of your proposal – without any need for technical knowledge – and it’s free for lightweight use! Alternative services are listed here.

If you prefer digital tools, you can use invision, which gives you perfect-looking digital screens and a wider range of interaction options. In my opinion, use paper first, and beware of things that look neat giving testers the wrong idea…

TWO: FilemakerPro: Filemaker is a database authoring platform. Yes, I know – sounds like coding to me, too. And indeed it isn’t utterly simple – you will need to read some of the manual and do a tutorial or two to get anything out of it. But if you can get useful things done with a spreadsheet, you can get useful things done in Filemaker. Honestly.

‘Why a database?’, you might ask. Well, the simple answer is that almost every website or app that you use is essentially a series of graphic interfaces between you and a database. Databases power everything – all the information you put into any app is stored in some sort of a database, and what the app does is fetch it, show it to you, and alter it based on the actions you take, in accordance with some rules (usually rather simple rules, too).

In Filemaker, you largely work by designing screens – screens that will be the real screens of your app. What this means is that you can approach it using your paper prototypes as the template. Start with the simplest screen. Recreate the paper layout on the screen, and then begin to specify the fields that will contain the data. You’ll find that you already know much of what you need to know (a name – well, that’s going to be a text field; date of birth? yes, that’ll be a date field), or that working it out actually improves your understanding of what you are designing.

So what you’ll be doing is designing the way your idea works – breaking it down into the various categories of information it uses, and the way they relate together. And the beauty of Filemaker is that it can deal with rather sophisticated relationships and present sophisticated interfaces without you needing to understand how they are achieved. The interface is largely graphical, and even when you get to writing scripts – sets of instructions – they are mostly short, and mostly written in real, simple words.

Filemaker will serve web pages and has an associated iOS app (even better, they’ve just announced a tool which will make it possible to make native iOS apps).

Another great feature is that Filemaker allows you to change your setup as you go. Start simple – as simple as possible – and add sophistication in small stages as you go. And when it gets too complex for you, you can get help on a freelance basis through sites like peopleperhour. Because Filemaker has been around for 25 years (it’s now at version 14), and has evolved steadily over that time, there is a large pool of freelancers who will readily take on piecemeal work and move you forward. What you get back from them will still be accessible to you at all levels. A good freelancer shouldn’t mind explaining what they’ve done for you and how it works.

In this way you can get from nothing to a fully functional ‘beta’ version of your app without losing control or spending serious money. At this point, you can put it in front of prospective users and let them start working – again, in return for that indispensable feedback.

Downsides? Of course there are downsides! The main one being that Filemaker just isn’t built for thousands of simultaneous users – it will slow down long before that point. If your idea really works, you’re going to need to get coders involved at some point. Another issue is that there is currently no way to produce a native android app. If your idea involves some sort of extra-fancy multimedia implementation, then it is going to need specialist coding early on – Filemaker can play videos and soundtracks – that sort of thing is no problem, but it doesn’t go beyond that. And of course, Filemaker isn’t free – you’ll be paying nearly 300 quid for the basic version (no trials as far as I know) – so do your homework before deciding to go down this route.

Whatever your route, I wish you well with your ideas, and don’t give up – the internet is too important to be run by coders!

EDIT: Here’s a post along parallel lines by Pete Warden, who IS a coder, but has some interesting suggestions.