Continuous design in development: methodology and principle

    In practice, it happens that you have developed a product, and after launching, customers use it differently than expected. Then it turns out that the user's tasks are already different, and they go against the planned product development and your vision of the project. Why?

    In fact, you are working with a user task that is not fully understood and that changes under the influence of the product. This suggests the idea that the product needs to be improved, and in tandem with the client. So you immediately protect yourself from creating unnecessary solutions based only on hypotheses.

    I think that it is best to build communication with the user on the principle of continuous design, which will be discussed in the article.

    Dear and doubtful IT chaos

    Most of the products and functions supplied by IT are not used in practice. Resources, applications, software remain unclaimed. Not all companies think about whether their products are really needed.

    A clear proof is the mobile development market, which has measurable indicators. Although best practices are concentrated here, the statistics leaves much to be desired: in 2017, analytics company Localytics published a Sql study , from which it appears that 24% of applications are opened only once by users.

    This is taking into account the fact that the percentage of users who opened the application less than 10 times does not exceed 63% . If we take into account the "stability" of statistics, it becomes clear that they do not draw conclusions from it. People are able to develop, but they miss the aspect of how the product enters a person’s life, that is, they don’t use the person-centered model. The latter involves long-term customer interaction; usually within a few years.

    This leads us to the conclusion: in a customer-centric approach, you need to refer to existing development practices like DevOps, agile or scrum, which are usually applied separately. But if you combine them, we get something more called continuous design. It consists of the classic principles of DevOps and design thinking. We propose to consider and adopt it, but in order to introduce the principle into development, it is necessary to reconsider the relationship between the two components: design and operations.

    Introduction from operations and design

    Operations - what is happening now. These can be system administration, user support, business processes. Operations are based on different models, for example, using the mentioned DevOps. It provides for an ongoing process of feedback, refinement, and delivery of solutions. A “loop” is created from feedback, planning, finding solutions and their presentation. And for each of the stages there are tools that help in the work, automate processes and ensure the constant exchange of information and solutions.

    Design is all that is involved in defining actions, methods of construction and ways to pack a product for a consumer. We usually approach design as a solution to a problem. If we understand the essence of the problem, then we can offer the right solution.

    This is a traditional approach.

    4 circumstances that do not take into account the traditional approach

    But when combining design and operations, 4 factors are revealed that have not been previously paid attention to by teams working separately. And for these aspects, continuous design becomes the solution:

    #one. The problem cannot be fully understood.

    With the help of analytics and research, we build hypotheses about how people will use the product, but they give an incomplete picture of the problem, since we cannot cover all its aspects. Only when the product falls into the hands of the consumer, we see how useful it is for the consumer, what tasks he helped solve or what he changed.

    A simple example: on jeans there is a small pocket for watches. He was invented by the company Levi Strauss in 1873. Since then, no one used the pocket for its intended purpose. The company even released a whole video dedicated to this.

    # 2. Product changes consumer

    An active experience of interacting with the product changes the user. And this transforms the problem that the product solves, which creates new difficulties for you and the client.

    Remember how we ordered a taxi 5-6 years ago: the operator at the other end of the line took the order and said that the car would be served in 20-30 minutes. And we were ready to wait. With the launch of services like Uber, Gett and Yandex.Taxi, our perception has changed: in 2018, the optimal time for submitting a car for us is 2-3 minutes. If we wait longer, it becomes annoying. And it's not about digitization or uberization, but about changing our consumption pattern.

    # 3. Value is something created together

    The value of the product cannot be imagined at the time of its creation. After launch, the service begins to live its life and acquire new value, which is formed during use. Some functions will be in demand, while others will not. So the value created by you and the consumer matures. Therefore, often the utility is not obvious until such time as the product or service is not used.

    Recall the AppStore, which appeared contrary to the ideas about the value of Apple. In 2007, Steve Jobs presented an iPhone with the words: “You do not need to write programs. It's no good: you have html5. ” This did not stop users: they hacked into devices and wrote their software distributed through the Cydia software application. It was launched in March 2008, and already on June 10 of the same year, the guys from Cupertino adopted a successful experience and launched the AppStore, changing the situation in their favor and becoming the number 1 player in the mobile market.

    This thesis leads us to the conclusion that the developer and the consumer are part of the problem and the solution.

    #four. Difficulty precludes control

    We are constantly creating complex systems that cannot be fully controlled. And this leads to inevitable failures and errors in them. One of the main problems in working with such systems is trying to control at too many levels when you are carefully considering what will happen or can happen.

    I am sure that all of us once called customer support, where we were redirected a lot of times to different operators. And we again and again described the problem and waited for an answer to the background music of the company. These are the cases when the service operators are thought out too carefully. Employees have algorithms for communicating with customers, which are constantly rewritten and detailed. Instead of serving the benefit of user interests, they only complicate and confuse the system. One operator due to company policy cannot solve your problem, even if it is simple. He just has to redirect you to someone else.

    Digitalization software

    Look at the evolution of the iPod.

    These unaccounted factors affect not only the digital, but also the physical world. It becomes more difficult to gain experience that does not include an intermediate program component. The environment in which we live is softwareized, and this changes the perception of things and the way we use them.

    For example, Tesla released a software update that increases the battery life of the car. At the same time, its physical characteristics are improved: now you can go not only to the supermarket or work, but also to the neighboring city. What changed was not the number of trips and the length of the path, but the quality of the car, and with them the understanding of the tasks and purposes for its use. Now you do not need to spend money on a taxi or put other restrictions, because the battery runs 2 times longer. One machine closes all tasks of its owner.

    Brand goes from promise to dialogue

    If everything became clearer with operations and design, then a larger and more abstract brand concept remains. He also works in a bunch of continuous design.

    Previously, we perceived the brand as a promise. For example, stability or immutability. But now its foundation is shifting to dialogue, because we live in a paradigm of changing values. And the dialogue with the user should not be one-sided, it is tied to constant communication. IT is the environment where this is done the fastest. After all, we have the tools to provide constant feedback at different levels: from external analytical services to DevOps methods.

    IT becomes an environment of continuous dialogue.

    We begin to continuously change the product due to the feedback from the client, for whom we observe and whose actions we analyze. So the DevOps loop closes into infinity when operations, development, design and marketing are involved in this process: we choose one solution from many, implement it and see how it behaves in practice. It is in this form that continuous design works.

    Continuous Design Paradigm

    And in order to design a fascinating dialogue, there are 4 recommendations:

    #one. Design customer and employee interaction at the point of contact.

    Design a user experience before releasing a product. And it is necessary to study it not only in ideal conditions, when a product or service is used correctly, but also where the client comes into contact with business processes: back office or IT architecture. Designing experience based on the external environment and on the user's lifestyle helps to identify how the product and the employees with whom it interacts fit into the life of a person. It will also clarify what the points of contact will be with the company's divisions and under what conditions. For this, you can use CJM and jobs-to-be-done clients and colleagues.

    # 2. Minimize delay, maximize feedback

    Flexible development methodologies like agile and DevOps practices provide not only speed and delivery of updates or beta versions. Using them we can quickly get feedback, test hypotheses and adjust actions to improve the product and further. We learn at each sprint of work or product updates and squeeze knowledge from it throughout the service life cycle.

    # 3. Design for bugs. Do to study

    Turn dips into information that serves your and user interests. Mistakes are inevitable at all stages, be it the design of functions or the development of a marketing campaign. But you need to be ready for them and build a continuous design to be able to notice a mistake in time and draw conclusions. Here it is important to use the practices of Lean UX, such as UX tests, AV tests, hypotheses, and so on.

    Ultimately, the culture of working with errors and the tools that it creates are shaped: like Chaos Monkey or Blameless post mortems.

    #four. The concept of "done" does not exist

    We are in conditions where the problem cannot be fully understood, but the solution changes it. Therefore, the team can not simply follow the hypotheses about the value of the product and continue to design the IT-architecture and service. Instead, you need to look at how products and services work when they are out of control. The feedback in the DevOps loop is meaningless until the operations and the world around you influence the process of product improvement. And in this case, the concept of "done" is excluded. You are constantly changing the product. This means that the process continues further in the system DevOps and design thinking.

    Working in the paradigm of continuous design teaches to respond quickly to errors, it is easier to treat them and not to do useless work. Its advantage is that step by step, more and more client tasks are closed, which brings additional profit and has a beneficial effect on the business.

    ps Jeff Sassn 's speech inspired me to write this material .

    Also popular now: