How we made a prototype Bluetooth mobile app concept in a week with no Swift programming experience

We’re massive fans of the book Sprint: How to Solve Big Problems and Test New Ideas In Just Five Days by three design partners at Google Ventures, Jake Knapp, John Zeratsky and Braden Kowitz.

The book delivers a process for answering critical questions through design, prototyping and testing ideas with your use.

My favourite chapter from the book is all about producing a prototype to get your product into the hands of your users quickly. The reason I’m such a fan of this approach is I love making prototypes. They provide such valuable insights into your products without spending time worrying about the detail. You can catch problems early on in the design process and work to resolve them with your users.

So when a client approached us with a concept mobile app for a piece of hardware they were developing — we thought it would be lots of fun to put this method into action. We knew we could develop them a prototype to demo their idea.

Our typical approach would be to work through the 5-day sprint process and deliver a user tested prototype created using Invision or Marvel. We’d usually focus on providing the project from a user experience perspective. But in this project, our client wanted something different from us. They wanted us to answer a different kind of question. Could we provide a proof of concept app which demoed their hardware communicating with a mobile phone?

The Sprint process focuses on choosing the right tools for your prototype — and in this case, we didn’t know any mobile development platforms. We should have probably walked away at this point, but we were intrigued. Could we pull this off? Could we build a mobile app communicating with a piece of Bluetooth hardware in just 5-days? So we decided to find out.

I know what you’re thinking — we’re crazy (and you’re probably right!). But let me give you some background. We are experienced developers and problem solvers. We’ve been developing custom solutions on the web for 10-years or more now. Every day we face questions to which we don’t know the answer, but the key is being able to find solutions to the problem — and that’s where we excel.

Before commencing a project like this, you should make sure you’ve got all your requirements nailed. We requested a specification from the hardware company regarding the messages they wanted to receive from our app and also set expectations around what we would and wouldn’t be able to deliver in the time we had available. For this project, we also requested a prototype of the hardware to be available to us.

Day 1

Monday is all about providing a clear path to delivering the project within the sprint week.

We started at the end of the project by agreeing to a long-term goal, and then we mapped out the challenge. We broke down the problem into several smaller components such as being able to identify the piece of hardware, connect to it using Bluetooth, send a message to the device and construct a simple UI to demo the app.

From experience, it’s important to gather resources to make our life easier later in the week. We started finding tutorials online and resources which would provide an insight into how we could solve the problem.

As part of our discussions, we decided to focus our coding attentions on Swift. We love the Apple ecosystem, and by knowing we’d be delivering the concept on a platform we admire, we felt it would inspire us to work through the difficult parts of the project.

We didn’t know any Swift — but we didn’t feel this would be detrimental to the project. We’re confident enough in our problem-solving abilities and our understanding of the concepts of programming that we can figure out any language.

Day 2

We began Day 2 by trying to solve one of the fundamental problems. We needed to be able to connect to the device before we could send a message to it.

From Day 1, we’d already bookmarked some resources which we would help us. The one which proved to be invaluable was this Zero to BLE on iOS tutorial (https://www.cloudcity.io/blog/2016/09/09/zero-to-ble-on-ios--part-two---swift-edition/)

It gave us clear instructions on how we could connect to the device, and by using the tutorial alongside the Apple developer documentation, by the end of Day 2, we’d successfully been able to connect to our device.

Day 3

Day 3 started in good spirit. We’d already managed to connect to our device successfully, and we were pleased with the progress we’d made.

However, Day 3 quickly turned into an uphill battle.

Our connected hardware was waiting for a correctly formatted set of strings to perform specific operations. We just couldn’t send the correct message string to get the thing to work. We toiled all day, referring to our specification sheet and trying every combination of formatted message we could think of before the day ended.

The day had gone, and we hadn’t moved forward.

When working with new technologies and new concepts, you’ll always hit stumbling blocks. Dead ends happen all the time, and the way you deal with these problems defines if we’re likely to achieve our goal by the end of the sprint.

Day 4

We began Day 4 outlining the problem again and seeing if anyone on the team had come up with some magic overnight. No one had.

We re-read the spec sheet and noticed we’d made a small mistake in our messaging format. We quickly coded in our new message string and hit send, and it worked! Everyone was ecstatic. Within 20 minutes of Day 4 starting, we were back in the game.

We quickly cobbled together a UI for the prototype, and we’d finished with half a day to spare!

In the afternoon we decided, we’d try to create a companion Apple watch app to extend the functionality of the prototype. The theories we’d learnt from the previous days allowed us to put together the app within the afternoon.

Day 4 finished with everyone in a great mood knowing we had completed the objectives of the Sprint.

Day 5

The start of Day 5 was used for final testing/bug fixing to iron out any small niggles. While the app is just a prototype, we didn’t want our clients to find any shocks!

We ran our demo session in the afternoon to show the customer our progress, and they were amazed we’d managed to prove their concept in just 5-days. We’d delivered them a working prototype and a watch app in a time-frame most companies wouldn’t have dared to do.

What we learnt from this experience

So the first thing to mention is this approach won’t work for all projects. In fact, I’d say it won’t work for most of them! But if the project fits then you can try to deliver a coded prototype.

You need to remember you’re making a prototype. You’re not going to release this app, and it can’t be used to shortcut the development process. App development is challenging and time is required to deliver a high-quality product that meets the user’s objectives.

Think differently — focus on solving the problem, not how elegant the solution is. You’re going to throw it away. Leave your ego at the door.

If you don’t understand the science behind programming, this technique won’t work for you. We didn’t know how to declare a variable in Swift before the start of this project, but we knew what a variable was.

Who does this approach benefit

Design agencies have lots of tools for delivering stunning prototypes to their clients. But in some cases, the facade of a prototype just isn’t enough.

With companies combining hardware and software products, they can often produce a hardware prototype quickly but don’t have the skills in-house to marry this with a software prototype, and they might need to demo an end-to-end solution.

Using a process such as the one described here, hardware creators can drastically improve the combination of a hardware/software product and reduce their go to market time while gaining valuable product feedback in the process.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.