Understanding how your end user thinks and interacts is crucial to delivering the best piece of work possible to a client. So, earlier this year when we were handed a brief with the primary user being experts of technology, we knew we had a challenge on our hands.

We were tasked with the development of a web and mobile companion app for a children’s television show, with the primary users being 7 – 10 year olds: these children, born in the digital age, acquire a familiarity with technology from the get-go. Though the brief was broad for this project, there were three key objectives we needed to accomplish for the client, all being centred around the young users:

• It needed to be fun and simple enough for a child to use,
• Children who were using it, should feel engaged and want to come back,
• The online platform needed to provide a consistent stream of user-generated content for the production team, to provide back to the daily TV show.

Ultimately, we needed to make something that was fun and simple, while also appealing to a child’s inquisitive nature, all the while delivering useful content to the production team.

By guiding the young users through the app in a way that felt as though they were discovering something new, the brief was met, and the users still feel engaged with the app almost a year on. During this project, we discovered new things too – here are our top three.

1. Knowing how the target user will use your app is essential for its success.

We know that kids are inquisitive and distracted. They aimlessly (though, often with force and purpose) swipe an active screen while hammering their fingers at colourful buttons and icons. They are constantly searching for interaction which rewards their limbic systems and swiftly become frustrated when something doesn’t behave as they expect.

As adults, we typically decide on a problem and then seek out a solution, while a child wants to discover what is possible, without really thinking about what the outcome might be. During this project, it meant as Software Engineers, we had to think like kids in order create software which would actively guide the young user to the solution. (Okay, thinking like children wasn’t a particularly hard task for our team).

Understanding how your user will use your application is the number one key requirement for its success.

2. Expect the user to do the unexpected

A common problem faced when developing software is that how you expect the user to behave in a given scenario is often vastly different from reality. This is especially evident with children, as their choices are often random and sporadic.

In the early stages of development for this project, focus groups were carried out with children of various ages and technology strengths so we could observe how they would interact with what we had made. What we found was surprising and unexpected (which should have been expected, given the unexpectedness of kids).

Demographic factors including the age gap between 7 – 10 year olds, technology in the home, amount of technology used at school, and even the decile of the schools tested affected user behaviour. For some children, the user interface was fine, but for others it was unusable as they were unable to read the phrases – or, they simply didn’t read them, but instead tried to problem solve by tapping and swiping. This was a major learning for us – we found that it is vitally important to not only have an understanding of your main demographic, but also subgroups within that demographic.

3. User behaviour translates to technical implementation

There were three main aspects which were used to guide our young users to interact. Movement, colour and consistency. If something is colourful, moves and they’ve seen it act like that before, they will tap, click, swipe and hammer it, and expect it to do what it did the last time. By using these three aspects, we could subconsciously teach the young users how to interact the way the app suggested they should.

These principles were therefore considered and implemented when handling any navigation to new sections of the app. By using consistent colours and animations across all navigation elements, we were able to quickly teach kids how to navigate without any conscious explanation.

Thinking like a digital native

When we kicked off this project, we had our clear objectives in mind, and a clear plan to achieve them. What we hadn’t anticipated were the invaluable lessons children were able to teach us about software engineering, and how their way of using technology would further shape the objectives and brief.

This reinforced the idea that everything from design & user interface, to technical infrastructure and implementation comes down to your end user. You need to have a good understanding of who your end users are, so you can have a great understanding of the platform you plan to provide them with – even if it means swiping, tapping and shaking your technology until it works*.

(*not recommended).

When explaining our software development process to clients, the Lab3 team often finds itself comparing developing software to the building of a house. On the face of it, there are a lot of similarities between the two. Making last minute ‘minor’ changes to functionality is a lot harder than if it was planned, for example (like changing a room to be a bathroom will involve much more expensive plumbing than if it was always the plan). Does the model always apply, though? I analysed our recent projects to find out.

The Metaphor in Practice

Most people understand that changing things that have already been made is difficult. It’s easy for most people to understand the physical world; when your builder tells you that it’s not going to to be easy to put a different shaped window in the hole he’s already cut, it’s not hard to see why. Software is, however, far more intangible. Swapping a piece of functionality for something similar can be as complicated as switching window sizes. On the other hand, in some cases it can be super easy – and this is the problem. To everybody who doesn’t understand how a particular program was implemented, the rules for when something will be expensive and when something will be cheap are very unclear – even to other developers.

The cost benefits of planning ahead are also similar. Adding a new room to your build at a late stage might bring a whole range of problems. Your foundations might not support it, and the hours spent on the section of wall you’re removing will go to waste. In the same way, software projects are designed – ‘architected’ – with a final product in mind. The technologies chosen and the structure used all might make sense for a given solution, but could be inefficient and wasteful as the project changes.

Maintenance is another area where house and software are similar. We all want things to be ‘solid as houses’, but if you think about it – houses do take a lot of maintenance. Just like wear and tear causes houses to be bit-by-bit replaced over time, software will never keep working as it may once have. Everything moves on without it – underlying platforms change or security vulnerabilities are found in other software you depend on.

Why It Doesn’t Always Apply

Our ‘house building‘ metaphor isn’t perfect though; in some ways, software is very different. For one thing – it’s not constrained by the same physical laws. Building a four bedroom house on the footprint of a motorhome is physically impossible. We can still make the software equivalent, it just probably isn’t a very good idea.

Another thing that adds to the flexibility of software development is in the way ‘construction’ takes place. Our team, as is quite common in the industry, uses ‘Agile’ development methods. This means that we build things room by room, and that at every stage there is a usable ‘house’ – even if it’s just a standalone kitchen. Compare this to your average house build; the frame goes up first, followed by roof, cladding, and windows – the house is built as one item. When building a house, changing anything means working within the confines of what you have already established, and you only get the value at the very end.

The needs of the client are very different, too. During the course of a building project, it’s unlikely the needs of the client will change. If they do, it’ll be minor – maybe they need four bedrooms now, not three. Software projects are often so exploratory, that the original requirements might be completely useless within the first few weeks of development. We try our best to fix these requirements in place before a project starts, but sometimes we do need to make changes to align with the business case.

It’s clear that while it is a useful model for explaining how some parts of software development work, the ‘house building’ analogy is far from perfect. When it comes down to it, though, you can improve a software build with good planning and management in all the same ways that you can improve the process of building a house.

As someone who finished high school six years ago, I went through the entire primary and secondary schooling systems without being taught how to write a single line of code. Instead, my introduction to software development concepts came from some random places, like writing simple puzzles in Excel or programming a game into a graphics calculator.

The team at Lab3 were all reflecting recently on what made us want to leap into the world of software and app development. Our experiences were all different, and a couple of us had never written a line of code before starting University degrees. However, there was one common theme: that everything we’d learned about software development came from outside of the New Zealand education system.

The Technology curriculum, until last year, was largely based on a document laid out in the mid-90’s, when the percentage of households with a PC sat around 17%. But within six short years, it feels like the attitudes around Digital Technology in the New Zealand curriculum have changed drastically. In 2017, thanks to the efforts of advocates of the benefits of Digital Technology education, the government officially added Digital Technologies to the Technology learning area of the NZ Curriculum.

As the world becomes more connected, there is an ever-increasing need for digital literacy amongst a wide range of fields. Through organisations such as Code.org, well-known figures and world leaders such as Barack Obama and Richard Branson have been outspoken about the need to better teach computer science as an essential life skill. They agree that the best way to both promote economic growth and to increase employment rates is to remove the barriers put up by a lack of diverse digital technology knowledge.

It will take a while for the benefits of these changes to be obvious, but broadening options to account for the ever-changing workforce is extremely important for both innovation and for preparing young Kiwis for the economic landscape they will be moving into from secondary school. We’re really glad to see the changes that are taking place and welcome the shifting attitudes to incorporating tech knowledge in education.

While it may mean we have more competition in the workforce in 5–10 year’s time, we believe the economy, employment rates, and the world, in general, will be all the better for it.

Chat with us about the software services we offer here.

Wait, what do you mean by ‘app’?

Most people associate ‘apps’ with the ones found on mobile phones. The pieces of software we use every day; designed to connect people, read the news and take selfies. You’d be wrong however to think that apps start and end there. Mobile apps aren’t the only kind of apps there are.

‘App’ actually has a wider meaning in the tech space. For example, a website can be an app, a ‘web app’ – they do more than just deliver information, they offer interaction; ‘web apps’ with integrated app-like features are called ‘progressive web apps’; and good old-fashioned ‘programs’ or ‘applications’ for your desktop have been rebranded as ‘desktop apps’.

For a lot of companies, the same product can cover all of these categories. Take Facebook for example. Facebook is a web app, the mobile site is a Progressive Web App, and it has mobile apps too.

Here, we’re mostly addressing mobile, app-store-based apps.

Have you considered that you might not need an app?

The natural tendency these days when faced with a problem is to solve it with an app. Modern culture revolves around apps. In fact, according to the Flurry State of Mobile 2017, 92% of your daily phone use is spent in an app. The only problem – roughly 90% of the time you spend on your phone is on the same 5 apps. People don’t use Facebook, Instagram and Twitter because they’re apps, they use the apps because they are Facebook, Instagram and Twitter.

The concept of ‘App Fatigue’ is something that’s emerged with the abundance of mobile apps. It’s become harder to differentiate your product or demonstrate a unique characteristic. In fact, most people don’t install any apps in a given month. That’s not to say that producing an app is a terrible idea, far from it. For the services we use daily, having apps available on our phones is an invaluable convenience. Product developers just need to consider the value that having an app will bring to their users. At the very least – consider whether releasing your product first as a Web App, or Progressive Web App might allow you to test your market, without significant extra investment.

Okay, so you want a mobile app – what are the options?

You’ve weighed it up, considered your user’s needs, and you want that app. Now what happens? Well, unfortunately, mobile apps are just as confusing, and have just as many options as the term ‘app’ itself.

Broadly speaking, apps are either ‘native’ or ‘cross-platform’. A native app is written specifically for a particular platform. That means a native app made for iPhones, can only run on an iPhone. Native apps typically deliver the best experience to the user. When done well, they’re fast, elegant, and generally just feel good. But, they come with the downside of often being slower and more costly to develop, and you still end up with an app that doesn’t reach 100% of the mobile market share.

An alternative to native apps are cross-platform apps, which aren’t written for any particular platform. Cross-platform apps that are written once can run on multiple platforms – iOS, Android and more. The huge benefit here is that developers only need to worry about developing the one product.

So then what are the downsides of cross-platform? It used to be that native apps were always viewed as ‘better’ – they were faster, and felt more natural for the user. Cross-platform apps were not quite as good as native apps, but they were a lot cheaper – allowing developers to reach multiple platforms with only one app. Despite this, cross-platform apps have come a long way, and in recent years the performance advantage of native has narrowed significantly. It’s still probably fair to say that all else being equal, a natively developed app will never be worse than its cross platform equivalent – the best cross platform apps can hope to be is as good as native.

How much will it set me back?

Apps of course come in many different shapes and sizes, and it’s very hard to give a one-size-fits-all price indication. The price of an app depends not only on what features you want, but who is developing it, and what technologies are used.

Our recommendation is to find a suitable developer and discuss your product with them. The worst that’ll happen is that you’ll learn more about the problem you’re trying to solve. Hear from several developers before committing to one and ensure that their outcomes match your expectations. For us, this means understanding the problem you’re trying to solve and making sure that the proposed solution meets that in the best way possible. If not, then there’s no shortage of options to choose from!

Get in touch to talk to us about your app.

 

Two members of our 4-person team have just come away from an exhilarating 52 hour weekend of pitching, validating and developing a couple of awesome ideas as part of this year’s Startup Weekend Christchurch.

My team, Journey, was formed around the concept of an app that allows tourists to become more immersed in travel by having access to more information about local history, significant landscape features and personal stories. By the end of the weekend we had a working prototype that spoke to the user and informed them of nearby points of interest using information sourced from Google Places and Wikipedia. The future intention is to source additional information from local councils and individuals.

The problems around community participation and consultation in local council decision-making were the focus of Chris’s team’s pitch. GapFinder proposed a digital platform that would allow locals to contribute their thoughts on council policies and actions, giving more transparency and citizen input to these processes. Throughout the weekend they developed a thorough business plan and validated their idea, receiving offers of support and funding from the Christchurch City Council and former town mayor Vicki Buck in the process.

Both of us were well and truly worn out by the end of the weekend but wouldn’t change a thing, with a huge amount of behind-the-scenes work by a large volunteer base the weekend was one we won’t easily forget.

See more here.

Lab3 is a cross-platform development company, but what does that mean? In a nutshell, cross-platform development is using one codebase to maintain apps on many platforms.

In practice, there are two ways to do this. The first option is to compile the code into the native language used on different platforms. The second is to develop using a framework that is runnable on different platforms. These different approaches offer different benefits. At Lab3 we tend to use the second method – using a cross-platform framework called Ionic. Ionic apps are web technology based. This means we write the apps in HTML5, CSS3 and JavaScript or TypeScript. This makes UI design very flexible compared to native app development. All the native functionality of different devices are still available, via plugins. This includes cameras, GPS, and all the other functionality of a modern mobile device. 

We’ve found that by using Cross-Platform development, we can provide phenomenal value to our clients. For a development cost not much higher than a single platform when developing natively, we can reach Web, Desktop, iPhone, Android and Windows Phone. Not every app can work well in a cross-platform format, but in our experience, a lot can!