Smartphone apps push alerts or notifications letting us know there is an update. Most digital services provide updates at the frequency of a few weeks or a few months at the latest. These updates sometimes are just simple bug fixes, while others are experimenting new technologies or functions. That is how digital services 'quietly and slowly, but repeated and continuously' evolve and survive.

 The frequency of updates is linked to the survival of the service. For example, Facebook updates its app two or three times a month. Most updates make small changes that are barely noticed until one inadvertently realizes 'oh, this is different.' But if you were to look at the Facebook app 200 updates ago, it would seem like an ancient relic. On the other hand, nine out of ten apps that go on without updates for a long time are almost no longer in service.

 Of course, apps don't only focus on small updates. There is sometimes a renewal in a massive scale that involves a lot of work which takes maybe a year, in case there is a need to change or improve the strategy of the service itself. Remember when Instagram completely changed its design 2 years ago? It has since then made small updates, trying out function tests, like Facebook. Posting a video to your profile, the tiling of video content when searched, and timeline logic that shows new content every time, which are now everyday functions of Instagram, are a few examples of those updates. As such, digital services need to live and breathe in the now, not just looking forward into the future. Social networking services such as Cyworld, Freechal, and Myspace that once dominated an era were complacent in their heyday and made the wrong choices when it was already too late, which eventually led to their fall.

 A traditional method of digital service development is known as the [Waterfall Model]. The model executes a process in the order of 'Conception-Design-Construction-Testing-Operations' and a clear division of labor is required. Many companies apply this method, but it also has critical problems in the speed of the process and in responding to arising issues. Most of all, the model requires considerable time to complete, which is exactly why there exists new methodologies for smaller companies, such as [Agile] and [Lean]. They quickly produce a basic version of an idea with minimum requirements and improve it through iteration of tests and modifications. One hurdle is that these models mean that services are released at a state of "incompletion," and because it must be applied in the entire process it may be challenging for big organizations or companies to adopt.

 In light of such situations, Google proposed a new method called [Design Sprint]. Design Sprint method was first created by Google Ventures to collaborate with more than 150 startups but has now become a key methodology across Google. The method calls for a process of clearly identifying the issue to be resolved and then to test the solution with design. In other words, the method puts more weight on the 'design' process preceding the 'service construction and release' process in the Lean method. In some perspective, there are similarities to design prototyping process. One crucial difference, however, is that Google's Design Sprint requires iteration of one-week cycle and cross-functional collaboration.

 Google's sprint process ideally requires the following conditions :

a. 4~5 stakeholders with diverse range of skills and perspectives (such as developer, marketer, designer, administrator, etc.) / one decision-maker
b. A total of 5 phases: Understand > Sketch > Decide > Prototype > Validate

 More than anything else, the composition of members is the most important. A prototype developed only by designers would require a lot of energy to take it to market. The true significance of the sprint comes from collaboration of stakeholders with different skills and perspectives and a decision-maker in validating ideas and making decisions.

 The total cycle of the sprint should last one week by limiting the time each phase takes up to a day. This means you need to validate and 'move forward' rather than looking at what is right or wrong. You must decide on an idea and make quick decisions on the best option within the given timeframe. There will be opportunities to come back and validate mistakes or things that were left out.

 After a Validation session, sometimes what was thought to be an awesome idea might turn out to be not quite good. In such case, the process must be repeated. The key is not whether you succeed, but that iterative validation takes place. Some might think that iteration is inefficient but identifying the problem quickly and fixing it can be an opportunity if you consider the time and effort it takes to actually take an idea to market.

 In January, Digital Design Team had the opportunity to meet with Google's UX Lead Designer Jonathan Chung to hear about the work in Google design. I personally had questions on how to narrow the gap between the methodology defined in writing and its actual application but found out that there were many sprints held and are being, fortunately, utilized according to each circumstance. Whatever the circumstance, it is important that we 'move forward' to solve a problem. And ultimately, shouldn't it be our goal to maintain digital vitality in a sustainable manner?