The principles of modern, business-driven concept design

What do you think when you think concepts (in the world of digital service development)? Many people consider concepts merely something that precedes the actual production of the service, a detailed depiction of an idea that can be moved to the next phase (production, that is). However, I think it’s so much more — so much, in fact, that I see it as the most crucial part of any service development project. Here’s why.

First, I’d like to introduce a three-layer approach to digital service development. This approach will help us to understand the principles of modern, business-driven concept design laid out further on.

User experience (UX) refers to how the service looks, feels and serves its purpose to the user. A “concept” is what we usually see as a part of this layer.

Front and back-end are exactly what they say. It’s what makes the service work like the planners and designers want to.

Technical novelties could be regarded as a part of front and back-end, but it’s more — it’s the novel part of the technology that not all rivals have or could have. Today, this often means algorithms, specialized data processing technologies, and so forth. Not all services have this layer.

Concepts — typically put in the layer on the top — show how the service should work, and might often have even something visual to concretize it. However, this is a limited way of seeing concepts and concept design — here’s how it actually can and should reach all layers:

Keep the business close.

The development of new digital services often follows a business interest — be it a new business or operational efficiency improvement. The concept is where the original business interest meets the first version of the actual service — they should describe how the problem is solved and what is the real business benefit. While concepts of today often do that, they fail in parts: lack of validation & continuation.

Lack of validation leads to concepts primarily based on assumptions & secondary research. While secondary research is important, concept design should always include validation with real users in the real environment.

This validation is often left for “the phase after concept”, which might be prototyping or straight-up piloting. It is essential to test the hypotheses as early as possible and do it from the business viewpoint.

Continuation means keeping the business benefit and the concept tightly connected throughout the development, not just in the early stages. Business benefit tends to be forgotten when service development continues further on.

It is essential to keep the business benefit in the front-and-center even after the concept leaves the drawing board. Companies often make this mistake — business viability is measured in the beginning when making decisions about moving the concept to production, and next when the service is in the market. A lot happens in between, so keep the business close at all stages.

Don’t stop the design.

Coming back to my initial statement: concept design is something seen just as a phase preceding all production phases. But if a concept is what defines the service, this is nonsense — why should the concept design and development end when you take the service to production? During phases after the initial concept design phase, it’s crucial to be able to continue developing the concept.

While you have an initial concept and have agreed on which features to develop and how, but you should always keep challenging these. It may often seem tempting to stick with the plan and evade possible challenges to the original concept when the development work is underway.

However, if you want the project to be successful and the service to fulfill the need, its concept should remain in continuous development and, especially, validation. It allows for the concept design to reach down to our second layer, the front- and backend.

It’s not just pretty pictures and slides.

It’s commonplace for designers and developers to clash, when taking a concept into production — there’s a lot of fancy features spearheading the current UI and UX trends by the designer, but the realism of the developer often means that there’s no a) budget b) time or c) feasible means to execute this. If your concept is about a digital service, it should not be just visions and pretty pictures — it should include technical concept design.

Not all things we want our services to do are possible (reasons mentioned before). Thus we should aim to close the gap between high-flying designers and down-to-earth developers by incorporating the technical design element from the early stages. Often these services also include something from the previously mentioned layer of technological novelties.

Especially in today’s data-driven world, algorithms, tailored automation, and robotics mean that many services contain something technological that contribute to its uniqueness. However, designing these novelties with no touch point to reality is useless in the long run, as the end goal, after all, is to create a functional service.

To prevent this paradox, the technical design should include developing and validating the technological novelties before moving on to the actual production — this doesn’t have to include production-grade algorithms, but it just has to show that it’s technically possible (and wise) to do this.

Now, that’s just scratching the surface. If you’d like to discuss more on the depths of concept design, drop me a line at kalle@smartbi.fi.