Where design meets business

So, staying in the realm of words – a better phrase to use in this context is the "interface". We deal with it every day, often without being particularly aware of it. And there is a reason for that: after all, they say good design is invisible.

There’s an interface in your washing machine, where someone has thought through how the process of changing the temperature will work. Self-service cash registers have interfaces as well, and their quality and usability can determine our mood when we leave the store. The interface in your car was created after hundreds of hours of deliberation on ergonomics and safety principles.

Finally, we carry a mobile interface in our pockets every day. It's not just Android or iOS, but more importantly, the dozens of mobile apps that compete for our attention. We communicate with each of them with our hand (or sometimes with our voice) within a designed interface architecture.

In the world of digital products, design is much closer to a craft than an art. Without a doubt, copious amounts of creativity and flair are required to produce it, but they are balanced by an important layer of technical circumstances and constraints that determine the direction of our efforts. And the larger the product, the more important it becomes to consider design decisions at the level of scale and data. This text is exactly about such large products.

But how should we even understand "large products"? What determines describing a product as large? Well, the simplest measure is the number of daily users. To make this definition even more specific, let's add the scale of the business behind the product as a criterion.

Now, it turns out that the Polish market has a countable number of "large" mobile applications, most of which will belong to the field of m-commerce. As it happens, I have been involved in designing precisely this type of product for a decade, and I will use this text to share my thoughts and the experience I have gained.

For it turns out that the matter is not as simple as it might seem. It is quite a challenge to build a product that is not only useful, but also accurately fulfills business needs and is scalable. Besides, if product design were so simple, we wouldn't have to deal with hundreds of applications that make us irritated, impatient or even angry, with technological debt hidden within their inner workings effectively stifling their growth.

Ottolenghi would make a great Product Designer

Yotam Ottolenghi is a world-renowned chef. He is famous for his unique approach to food preparation, which he sees as a combination of two worlds: simplicity and sophistication. Simplicity forms the vast majority and is the base that makes the entire cooking process simple and not overwhelming.

However, everything is topped with something special, often a seasoning that gives the prepared base a unique character. For a simple roasted eggplant, Ottolenghi recommends adding sumac, which completes the work with its citrus flavor. His two cookbooks are always present in my kitchen and provide inspiration every week. However, they remind me of something else…

The very title of Ottolenhi's main cookbook, "Simple", both illustrates his philosophy and serves as the connection we will use as we move into the world of design. Simplicity and minimalism are the first associations we hear when asking users what they expect from an interface. It is meant to be clear, devoid of complications. This principle is crucial when designing large products, and it is by no means just about the simplicity of the interface – it is about the product-building strategy.

From a designer's perspective, the creation of a digital product can be divided into two levels: business and technical. The former collects the strategy, processes and ideas that determine the direction of development. The second, on the other hand, is the strategy and form decided at the interface creation level.

A successful product is one in which both of these strategies not only work together, but are implemented in a way that is reasonably adapted to the circumstances. The good news is that there are universal, verified principles, adherence to which will allow you to avoid the troubles that have led many large projects to business failure.

Rule 1: Be ready to make sacrifices

If you want to build a large mobile application, start by accepting reality. This is the key to finding the optimal plan and scope of work. After all, the reality is that the first version of the product should be simple and hit the market as soon as possible, not only to start earning money for itself but also to start verifying hypotheses (more about that in a moment).

The reason why such sacrifices have to be made is usually due to the cost and time constraints that accompany large projects. Trying to fit everything in already at the start is almost always counterproductive.

Of course, we must not forget that you only get one chance to make the first impression. We want users who come into first contact with our application to be enchanted by its capabilities and stay for longer.

How can you go about this challenge? The answer lies in the recipe I mentioned a while ago, which Ottolenghi simplified to enrich it with sumac at the very end. In the world of design, the role of this spice could be played by one additional feature that will charm users and give them a reason to visit the app regularly. It could also be a set of original interactions or personalized onboarding experiences. The combination of absolute simplicity and one extra feature is a recipe for success for our version of MVP.

Rule 2: Plan to make room for quality

The run-up to the first product release is always a tense period. It’s when the application begins to undergo final testing, during which we discover interface flaws and come up with a number of ideas for additional improvements that will improve product quality.

But... it's too late for them at this stage. Few products will devote critical resources to fixing details at this crucial moment. The lesson here is simple: the moment to plan for micro-interactions, haptics, gestures and anything else relevant from a UX perspective is when the processes are first being built, not at the end of the work.

After all, quality is not the culmination of the work, it is its strategic foundation. Proper planning and deliberate selection of native and custom solutions will make the best use of time and not add work that won’t fit within the project scope.

Ottolenghi picks out a few products for his dishes, but all of them meet the criteria of quality and freshness.

Rule 3: Test, measure and tweak

Building an MVP should resemble a simple, easy-to-understand path, where we know what sections it consists of from start to finish. However, this changes when we begin to expand this foundation with more features. This stage of the work should resemble a path that every now and then encounters forks in the road. These usually let us proceed in two directions, and then we call this process A/B testing.

Sometimes, variant testing is required for some detail, like the text content of key actions. At other times, we should test a prototype or hypothesis, and here, qualitative and quantitative tests with users will come to our aid.

Sometimes, we may even be tempted to use the (risky but effective) "fake door" method, in which we test interest in a new service already on the production version, without fully implementing it, just observing users' reactions and involvement. All these procedures minimize the risks of investing in features that may not bring the expected benefits and involve burning through significant resources.

Undoubtedly, it is crucial to rid ourselves of the belief that it’s us who know best what exactly users need and that we are able to predict what interface will drive our business goals best. Discussing design is similar to discussing how a certain dish tastes. It is so close to our subjective impressions and experiences that we are often convinced of the validity of solutions that we already know, like, and find appropriate.

However, what we like is frequently not the preferred solution when we begin to look from a broader perspective, expressed in terms of the number of general users who will have to deal with the product.

In reality, usability is something that can be objectively measured. And here is when analytics comes in to save the day: an oracle to guide our design efforts and answer key questions. In order to get the process right, we should first of all assign analytic events to the key elements and actions of the process we are working on modifying.

Then, before making adjustments, we should collect data analyzing the current state and, extremely importantly, define the goals that we want to achieve in advance. The third step consists of measuring the same parameters after making changes. This is a simple, effective and, most importantly, reliable way to verify the validity of the designers' solutions, and a compass that will point us in the right direction.

Rule 4: Build interfaces from your own Lego blocks

Despite all this thinking about strategy and philosophy, we can't forget that the product has to be built, and what it consists of are lines of code and their corresponding pixels. The efficiency of this production process determines the final success, and this applies both in the initial phase (MVP) and in the development phase (post-MVP).

We should thus from the very beginning adopt a strategy that will allow us to build our product in a light and flexible way, using technological advantages and organizational cleverness. This strategy, by the way, has a name: it's a “design system”, a term that has been the talk of the town in recent years, and for good reason, as it represents a real and tangible output.

Playing with the name of this concept, one can say that any design is a system. A system, understood as a set of communicating vessels, in which the butterfly effect applies, where one change entails many consequences.

Design systems imply nothing more than building your own library of UI elements at the level of both design and development. It is the glue that connects and organizes the two worlds, and at the same time serves as the single source of truth about the user interface.

And, most importantly, thanks to the idea of reusability, it reduces the time needed to build an interface so significantly that it is the absolute technical foundation on which any mature digital product is based.

Design-Systems-CTA-Banner

Today is the best day to make a change

Large products are like huge tankers: their scale makes it difficult to change course. But it is not impossible, and here, too, it’s important to heed the life wisdom from the headline. Every small contribution towards process optimization is valuable.

Process improvements won't happen overnight, but their impact will quickly make itself known, which will undoubtedly translate into key resources – time and money – and ultimately make our product more effective and precise in meeting business goals and needs.

And if we are faced with the challenge of building a new product and the opportunity to start with a clean slate, then the principles described above will certainly help make the process more mature and ensure that the product we create will not only not succumb under the weight of the roadmap, but will also be bulletproof, flexible and effective in the key stage – the development stage.