As Shortcutters, we believe that, in order to be successful, any app project must be three things:

1. Feasible to build – by choosing the most advisable, swift, and future-proof technology.
2. Viable for the client – by creating better opportunities for advancement towards a client’s goals.
3. Desirable for the users – by making apps that are downloaded, enjoyed and incorporated into the users’ lives.

High degrees of feasibility and viability are achieved through a combination of our specialist knowledge and the client’s expertise. As app specialists, we have flair for creating successful apps – we are experts at advising and taking action all the way through a project.

When it comes to desirability, however, we need to know about the users’ needs in order to succeed. And the reality is that we rarely know them very well.

‍

How can we fix that?

The way we see it, there are two ways of evaluating the desirability of a concept.

One approach is to let users verify the concept once the app is released. This means conceptualising, designing and developing the app based on:

• the client’s initial wishes
• the team’s expertise
• the current app conventions
• the given assumptions of the problems the app will solve.

Many projects follow this approach, as it often feels intuitive and sensible when relying on what we believe we know. It feels productive, because the process from defining a concept to developing tangible evidence is short when user feedback, and thereby the evaluation of desirability, is postponed.

This also means that the process of creating something to show stakeholders is short and quick. However, it also often prolongs the process and comes with a high risk of exceeding the budget. Why? Because if something’s off, both designers and developers need to be involved in order to fix it.

Another way – and our preferred way – is to test the concept or design with a representative group of potential users before anything is developed in code. With this approach, we can attain a high degree of desirability by learning more about potential users early on. What do they want to do? What do they like? What puts them off? We get a better understanding of the users’ needs, thereby obtaining an important tool to inform the process of prioritisation and steering of the development.

‍

It’s all about the needs

A well-recognised pitfall in design is thinking that everyone else is the same as us – that they must undoubtedly like and want the same things and behave the exact same way as us. That what we like, they will like as well.

This is a very common and instinctive way of thinking – but most of the time, it’s false. In fact, most designers are well aware of and share this mantra: You are not your users. Simply put: being app specialists doesn’t make us mind readers. But user testing sort of does.

Specialist knowledge of app development ≠ knowledge of user needs

User testing can be many things and be done in many ways and at different times throughout a project. It can be done using anything from low-fidelity prototypes – sometimes as simple as sketches – to almost-complete designs in a clickable state. Either way, it relies on a prototype, designed on the basis of an agreed-upon concept.

Testing means analysing the concept, identifying the underlying assumptions and unknown factors, and then, simply, talking to people – touching base with actual potential users, and figuring out how the app fits into their daily lives, what might irritate them and which tasks the app can help with.

The testing process in itself should be thought of more as a conversation with a specified purpose than as an actual test. The goal isn’t to simply conclude that the concept works or doesn’t, because firstly, this can’t be done, and secondly, it’s actually not that interesting. Rather, the testing process is a way to get insight into the testee’s experience with the prototype – what they think, feel, miss, dislike, get confused about, and expect.

While engaging with the prototype, we encourage testees to ‘think out loud’ – meaning that we want them to say everything that comes to mind when interacting with the design. We will ask contextual questions, like: What would you prefer? What did you expect to happen? Why did that surprise you? In other words: we attempt to read their minds.

‍

But … Isn’t that expensive?  

Many stakeholders worry that allowing time for user testing will prolong the process without providing all that much necessary information. Basically, they think it’s a waste of time and money.

In our experience, it is the exact opposite.

‍

Hard facts

User testing gives valuable insight into the living, breathing reality of an app – who will use it, to do what, and in which situations. And, equally importantly, it will teach us the opposite – who won’t use it, and which needs the concept doesn’t fulfil.

The feedback will provide hard facts from actual user behaviour to base every forthcoming decision on. Scoping and backlogging will be a smoother process, and the team will be better equipped to keep the end user in mind.

‍

Saving time

Major changes to the design late in the development phase can prolong a project and threaten deadlines – especially if a lot of the code has to be re-written or essential new features are uncovered.

Testing in the early design phase will catch any conceptual misconceptions or needs that are so far unmet by the design. This affords valuable time to update and refine the solution before development.

‍

Scalability

Testing might sound like a big and daunting project, but here’s the good news: tests are scalable and adjustable to each project, and even a little testing goes a long way. At Shortcut, we tailor the tests and the length of the research period to each individual project, evaluating how much is needed and when the test optimally fits into the schedule.

‍

A little extra work makes less work in the end

Designing unique, tailored test schemes is something we love to do. We strongly believe that this is the solution that helps to bridge the gap between our specialist knowledge of app development and the unknowns of the user needs.

Adding a higher degree of desirability through the exploration of user needs will benefit the viability of the project. If you rely on people to want to use your app, you simply won’t profit if your customers never download and use it.

We’re convinced that testing creates a better prospect for us to get it right, that a little bit of extra work early on in the process actually means less work in the end – and that this feedback is invaluable in creating an app that users will love.

In the end, it ensures that we can achieve an ideal combination of a feasible, viable and desirable product – that, at the end of the day, we can create a truly successful app.

Contributor: Marianne Christensen (Design Team DK)

Illustrations: Cecilie Pihl (Design Team DK)

‍