The value is in the service, not the app
Tags: app, ux, servicedesign, business
Published: 2019-09-23 09:49:55

---
title: The value is in the service, not the app
published: true
cover_image: https://assets.browserlondon.com/app/uploads/2019/08/mobile-device-purchase-complete-1536x864.jpg
tags: app, ux, servicedesign, business
canonical_url: https://www.browserlondon.com/blog/2019/09/17/value-in-service-not-app/
---

We’re a digital product agency, so [developing apps](https://www.browserlondon.com/services/design-development/) and digital services is our stock in trade. Unsurprisingly, this means clients tend to approach us once they’ve decided that’s exactly what they need; you don’t wander into a tailor if you’re not in the market for a suit, after all.

This means we talk a lot about [apps](https://www.browserlondon.com/case-study/twine/) and [platforms](https://www.browserlondon.com/case-study/lightning-api/) and technology, but often, what we’re really excited to get to grips with is the problem or idea that the digital service or product is to be designed around.

After all, an app is just a machine that performs a job. It isn’t intrinsically valuable on its own. Instead, it’s the underlying service design – the part of the recipe that solves a problem for the customer – that adds value. The technology, the app, is merely a way for the user to consume or access that service.

Sometimes, I think businesses can lose sight of this simple truth. Instead, it seems [increasingly common](https://www.allbusiness.com/10-reasons-small-business-mobile-app-104508-1.html) to operate with the baked-in assumption that whatever the problem, an app is the only answer. Technology will cure all ills.

I want to challenge this belief, as my twelve years experience in digital strategy and development tells me that this simply isn’t the case.

## **Bring me your problems**

Rather, the best solutions start with a focus on a problem, and problems are much better solved when the solution isn’t prescribed.

![how to set up user testing](https://assets.browserlondon.com/app/uploads/2013/12/Screen-Shot-2016-03-14-at-18.28.33.png)

In essence, just tell me the issue; _who_ is encountering a problem, and what do they _need_ to do. Using just these two touchstones we can start a [user-focused](https://www.browserlondon.com/blog/2016/06/01/user-experience-design-getting-basics-right/) service design process, beginning at the bottom and working upwards to build a full understanding of what and why, and the solution to the issue will usually naturally follow.

Spoiler alert; the solution may not be a new-build mobile app.

In fact, I can point to multiple instances where clients have approached us looking for a bespoke app build, but, once we’ve got to grips with their idea or problem, we were able to direct them towards an existing service or platform that solves their issue (often for a fraction of the cost of contracting us). Likewise, I can recall clients that have been looking to solve one issue, but upon examination, we’ve found that issue to be caused by something far deeper, but also far more valuable to solve.

These examples underpin why it can be useful to work closely with clients to write and develop a full project brief _before_ starting any coding work. The benefits of this are two-fold.

The agency, as a design partner, can build a genuine comprehension of the purpose of the service and the business case and model that it is built upon, both of which are [key principles of effective service design](https://www.interaction-design.org/literature/article/the-principles-of-service-design-thinking-building-better-services). Clients, on the other hand, often find an outside agency's involvement in that process sheds new light on their initial thoughts about the digital product or app, allowing the project team to better identify key features and make plans for these to be delivered during the product build process.

## **The value of the discovery phase**

The space in which this collaborative brief writing process happens is usually called a [discovery phase](https://www.browserlondon.com/services/research-analysis/), and this can take place either as the first part of a full idea-to-product project, or as a standalone scoping and feasibility process.

![A team discusses research conducted as part of a discovery phase for an app project](https://assets.browserlondon.com/app/uploads/2017/07/Screen-Shot-2017-07-27-at-15.16.20.png)

When we approach a discovery phase, we keep three important principles in mind.

- **Take a broad view** – It’s vital to look at problem or product idea in as broad and holistic a manner as possible. That means considering everything that underpins the issue, including operational processes and human factors.

- **Question assumptions** – It’s useful to come at a problem without prejudices about what can and can’t be done, and what can and can’t be changed.

- **Apply a framework** – Applying a structured thought process can help break large questions or problems down into smaller, more manageable chunks. We regularly use the Jobs to be Done and [Design Thinking](https://dev.to/browserlondon/design-thinking-4439) frameworks within our team.

It’s once we’ve been through this process – exploring the avenues open to an organisation while maintaining a clear focus on the user and the problem along the way – that it becomes possible to see what shape a solution or end product may take. If that’s a bespoke app, platform or digital service, great, but it’s equally important to be open to the idea that the best solution for the client and users could just as easily be a new internal system or an off the shelf service or product.

----

The post [The value is in the service, not the app](https://www.browserlondon.com/blog/2019/09/17/value-in-service-not-app/) appeared first on [Browser London](https://www.browserlondon.com).