The complexity of the system must be proportionate to the size of the team. I’ve found myself offering up this piece of advice a number of times over the last few years, most commonly with smaller design teams who have started to build their first design system, but are struggling to get it to a point that’s usable and delivering value to their organisation.

For smaller teams starting out in the world of design systems, it’s all too easy to look over the garden fence, see the complex, mature design systems that everyone else appears to be building, and think “Righto, that must be what we need to do…”

Where this ‘keeping up with the Jones’ mindset can lead to problems is when smaller teams mistakenly think that building a complex, enterprise-level design system will solve more problems than it creates. Complexity and ability are of course relative; what’s perceived as complex relative to any one team’s ability and experience level can vary greatly, which is where it gets tricky when modelling your own system on what you see others doing. If you build a system that’s too complex for your team to manage, then that system will inevitably fail; instead, success lies in teams working to build a system with complexity that’s proportionate to their specific size, experience, and ability.

The majority of teams I work with are looking for a Design System to help them reduce complexity, duplication, and effort, in order to deliver valuable product enhancements with greater speed and regularity. This is a sound reason to build a design system, however, you can’t hope to reduce complexity and effort by building an overly complex system. In order to be successful, the system’s complexity has to be proportionate to the ability, size and capacity of the team using it, and this is where The Lean Design System mindset comes into play.

The right starting point for smaller teams

So what do I mean by The Lean Design System mindset? To achieve this, for smaller teams of less than 10 designers this means accepting that you can’t have everything right now, and that you need to start lean, and prioritise immediate value. Sounds pretty obvious right? In a way, yes, but this means picking your battles when it comes to the facets of your design system, and being comfortable in the early stages of building your system, to put on hold some aspects that could bring you greater value in the future than in the present. Comprehensive documentation such as guiding principles, DO’s and DON’Ts, detailed component anatomy diagrams for example, are important facets of a mature design system, but does your team need those things right now? And furthermore, is it realistic for your team to create and manage those facets right now? Remember, maturity is something that’s acquired over time, so with this in mind, don’t be afraid to embrace immaturity as your starting point.

The most effective way to start demonstrating the value of your new design system, is to get some reusable styles, components, and patterns built, and into use. That’s why I advocate for smaller or inexperienced teams to start by building the winning combination of a robust pattern library alongside a concise style guide and design tokens, as the starting point for their organisation’s Lean Design System.

While these things alone do not constitute an all-singing, all-dancing design system, they can be easily managed by a smaller cross-functional team whilst being incrementally scaled into that full blown, all-singing all-dancing design system over a longer period of time. A lean, functional Pattern Library and Style guide will give your team a modular library of reusable components and elements to work with, demonstrating value through faster, more consistent, and more abundant prototyping and optimisation of your products.

How much documentation is enough documentation?

Comprehensive documentation is a highly valuable facet of a design system, creating clarity on how to use the system, and reducing misuse of components, assets, and styles. However, comprehensive documentation takes a great deal of effort for a small team to create and manage. So instead of looking over the fence at Google’s Material Design, and trying to recreate its level of documentation, instead ask your team to identify what’s the absolute leanest documentation required for your designers to successfully use a component, and for your engineers to build it. You can create placeholders for any nice-to-have documentation that you’d like to add in the future, ensuring the scalability of your design system’s structure to accommodate more, richer content.

What about governance?

The same mindset can be applied to your Lean Design System’s governance processes. Never undervalue the importance of your system’s governance processes, as they’re the secret sauce that turns a well organised set of components and styles into a usable, scalable system. That being said, this is another area where finding comfort with immaturity is the smart approach to complexity. When you’re starting out, put perfection to one side and aim to create governance processes that are acceptably imperfect whilst being perfectly manageable for your team on a day-to-day basis. If you’re a small team, you can afford to be a bit more scrappy in your approach to governance, so try to define processes that enable you to move quickly, and avoid design and Tech debt, without too much bureaucracy or red tape.

In the Pattern Library Playbook I described governance as a framework that outlines roles, responsibilities and decision-making for maintaining and updating a design system, and this still holds true. My recommendation for the most valuable facets to focus on first for small teams, is points 3 and 4 from the Pattern Library Playbook, which cover modifying the system and tracking changes to the system. As a small team you should look to answer the following set of questions with the leanest workable documentation and processes that you can define, keeping in mind a view to future scalability.

• What’s the process for assessing whether to modify an existing pattern?
• What’s the process for assessing whether to create a new pattern?
• What’s the process for assessing whether a new pattern is reusable or a Snowflake?
• Where do Design and Engineering practitioners come together to review updates?
• What’s the process for merging new/updated patterns to the Library?

Answering the above set of questions will help your team to define their lean process for getting components and updates into the design system and handed over to engineers, so that your team can start using and contributing to the system while your organisation can start reaping the benefits of having a design system in place through increased efficiency.

Building for scalability

The mindset of starting lean, to prioritise immediate value is a sound one, however, it’s essential that while you’re embracing immaturity today, you have a clear idea of what growing into maturity should look like in the future. What this amounts to in simple terms is planning ahead, in order ro reduce the risk of designing your system into a corner, so to speak. Before you reach for your crystal ball, let’s agree that while no one can be certain what the future might be, certainly when it comes to digital products and services, every team is capable of identifying how they would like the future to be.

As you might already do when defining a strategy for the products your system supports, have your team define a North Star for your design system, and a roadmap to get there. This approach will ensure that with every step you take towards that ideal North Star state, you’re avoiding short sightedness while creating the structures and space required for future scalability.

At this point it’s important to reflect on something we covered at the beginning of this article; small teams often think that building a complex, enterprise-level design system will solve more problems than it creates. Don’t fall into the trap of planning a future that’s beyond your team’s capabilities. This means that your North Star must still reflect the size and ability of your team. If your North Star is a system that will ultimately be too complex for your team to manage, then you’re building towards failure.

Today, tomorrow, next year, and beyond, the complexity of the system must be proportionate to the size of the team.

About the author

Thomas Weaver is an experienced Product Design Director with a passion for leading teams to deliver engaging, accessible, and visually stunning digital services that are easy to use. Thomas has particular expertise in user-centred design, DesignOps, Design Systems, and integrating design capabilities within Product Teams.

Sustainability in IT has recently started to gather some long needed attention. Even though it’s a trending topic, no commonly-agreed regulations or standards exist on what it actually means. While cloud service providers are setting their own targets to reduce emissions and achieve carbon neutrality, this is only one part of the equation. As developers and maintainers of software solutions, green coding and green maintenance are areas where we can actively contribute to sustainability ourselves.

What is sustainability in IT?

We find ourselves in a situation where the emissions from the IT industry are comparable to, or even surpass, those from commercial flights, depending on the source. Technologies like GenAI and cryptocurrencies, which consume vast amounts of energy, exacerbate this issue. The pressing question is how can we, as an industry, contribute to combating climate change and be part of the solution?

In order to make a difference, we must understand sustainability in general. It can be divided into five dimensions:

1. Environmental
2. Social
3. Economic
4. Technical and
5. Individual

All these dimensions have to be taken into account in order to create sustainable software. Futurice as a whole is working towards making an impact on all dimensions. In this blog post we focus on environmental and economic dimensions, as these are primarily present in green maintenance.

Why green maintenance is needed

Various terms related to sustainable software development have surfaced in recent years. Here we will focus on two relatively new ones: GreenOps and green maintenance.

GreenOps denotes the practices and technologies dedicated to reducing the environmental footprint of cloud computing. GreenOps is a broad concept that some consider a subset of FinOps. However, we believe GreenOps stands as an independent entity, although one that is closely connected to FinOps. For example, cost-saving measures, such as operating only essential instances of software, also contribute to lessening the environmental impact. But then some other FinOps measures, such as moving computing workloads to cheaper cloud regions, might actually have the very opposite environmental effect.

Through green maintenance, our aim is to ensure that applications are operated in the most sustainable manner possible. While many decisions impacting the software’s sustainability have been made before the maintenance phase, there still remain plenty of opportunities to improve the sustainability. In Futurice Managed Services (aka. FutuCare) we can best see the consequences of choices made during the design and development of the applications we manage. We’re eager to share what we’ve learned with our development teams, to ensure that we keep improving in developing maintainable and sustainable software.

Interested in ROI? Focus on maintainability

Sustainability should be measured throughout the entire lifecycle of software, from requirements engineering to shutdown. The maintenance phase, despite being one of the final stages, is crucial for long-lasting software. From a sustainability point of view it bears the cumulative impact of all previous phases. Poorly implemented software is costly to refactor, both financially and environmentally.

If you truly want good ROI on your software assets, maintenance should be a top priority throughout its lifecycle.

Steps we are already taking to facilitate green maintenance:

• Extensive knowledge transfer when project is moved to maintenance
  Why: Understanding the link between the architecture, different scenarios and solution
  -> Better maintainability and less complexity
• High automatisation throughout the development process
  Why: Manually executed tasks take more time and thus are more expensive
  -> Better efficiency
• Quality assurance
  Why: Way to ensure that the software works after changes and detect bad quality code
  -> Maintainable code done according to best practices
• Monitoring resource usage
  Why: Changes in usage suggest performance issues
  -> Ability to detect and address the issues
• Add tools to CI/CD pipelines that measure sustainability in different ways
  Why: Detect changes between different versions of software
  -> Awareness and possibility to take action
• Use cloud providers’ tools for sustainability
  Why: To be able to calculate the total emissions of cloud resources used
  -> Transparency and ability to make better decisions

This is a start, and other ways will emerge when knowledge of the topic grows and industry standards are made.

A sustainable future is within our reach

One thing that still needs to change on the path to green maintenance is the attitude. Generally, it’s hard to oppose sustainability, but since it requires changes in how we develop and manage software, it can seem intimidating. However, many developers who follow modern software development practices are already on the right track. Thus quality assurance and best practices are key to ensuring software sustainability. Software developed with best practices in mind won’t waste resources, whether it’s processor power or human time and energy. As awareness grows and methods for measuring impact improve, people are likely to be less hesitant to adopt new ways of working.

While sustainability is just beginning to trend in the industry, there are already many actions we can take to promote sustainable software development. As cloud providers become greener and provide more information about the environmental impact of our workloads, we can see a glimmer of hope for sustainable IT. However, this requires action on many fronts and a commitment to utilizing the tools available to us.

At Futurice, Care is one of our core values. Our main 4x2 decision framework encourages us to consider all our actions also from the environmental viewpoint. Thus the topics discussed here, GreenOps and green maintenance, are very much aligned with who we are as a company and how we want to contribute to this world. We are keen to share this journey with you 💚

About the authors

Henna Mäkiluoma is a Software Developer, and Miika Heinonen is a Service Lead at the Futurice Tampere office.

Green Maintenance: How to maintain software sustainably was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Although the gap between digital products and business objectives is not as wide as it once was when products were driven purely by technology, aligning the two still proves challenging in many instances. In this article, we will discuss how viewing your digital products through the lens of their lifecycle and adjusting your product strategy accordingly can propel a product towards business success.

Connecting digital products to business impact

For a business, one of the primary goals is growth, typically measured by revenue. Nowadays, companies are investing in digital products (or services, if you wish) with the hope of generating value for their customers and/or employees. This value, in turn, is expected to directly or indirectly improve overall business performance.

However, there is often a significant disconnect between the products being built and the business’s expectations of their contribution.The disconnect goes both ways: products often fail to demonstrate how they justify their investment, while businesses undermine product success by disregarding the necessary process for achieving the most significant impact.

So how do we connect the contribution of digital products to the overarching goals of the business and evaluate their impact? And how do we teach a business to understand the process through which the product should progress in order to become a success?

Our digital products naturally progress through lifecycle phases: introduction, growth, maturity, and eventually decline. By leveraging the product lifecycle framework along with a fitting product strategy, both the business and product team can better understand the goals and actions needed at each stage to maximize potential and ensure successful transitions. It is crucial to align the objectives of business, product, and technology with our current phase in this long-term project to focus on what truly matters now.

Mastering the introduction: discover your first product-market fit

It all starts with an initiative to introduce a new digital product to the external market or an internal company domain. The introduction phase (A) requires significant effort and is frequently oversimplified. There’s a common misconception that creating a minimal viable version of the product and launching it to the market will propel us into the growth phase, and if we simply keep building it further the growth is guaranteed. However, the reality is often far more complex and requires careful planning, iteration, and adaptation based on user feedback and market dynamics — essentially, discovery. Without properly addressing this phase, the product may never successfully transition to growth. This phase is inherently very risky; no one can guarantee the success of the original idea. Yet, when executed and overseen correctly, there is a significant chance of finding the idea and implementation that sticks.

During the introduction phase you need to find your first product-market fit, the worst thing you can do for your product is lock yourself in a rigid plan, heavy technology approach or unverified concept. Until we achieve product-market fit, extensive technology implementations and heavy investments in marketing may yield little to no return. We need to build, measure, and adapt very quickly — striving to be as lean as possible. It’s crucial to seek knowledge and market acceptance during this phase. Only when the market begins to pull the product without needing significant pushing do we start to see the first signs of growth.

Maximizing growth: strategy for sustainable product expansion

The growth phase (B) is a critical time for leveraging market awareness and expanding market share. Often, in our eagerness to grow, we start to make rather common mistakes. B2B businesses tend to over-customize products to meet specific client needs, which quickly begins to dilute their core offering. This leads to a stack of unscalable and barely maintainable solutions that only meet user needs at the minimum level and serve many, but no one well. In B2C, we can often experience “phantom” growth. This refers to short-term sales spikes driven by marketing efforts that don’t translate into sustained value. Effective marketing is crucial, but it’s wasted if digital solutions fail to retain users or convert them into paying customers.

Absence of a sustainable growth strategy

These issues highlight the absence of a sustainable growth strategy focused on long-term engagement and loyalty rather than short-term gains. It also suggests that your focus is solely on tactics: a long backlog of features created by random customer requests and user feedback that hasn’t been properly evaluated for impact.

While products can grow without a strategy, they often fail to reach their full potential, leading to stagnation(E) and premature decline(F). Despite potential for continued business growth, it cannot be realized due to the current state of the product.Without strategic product thinking, products become stagnant,and soon require costly partial or full renewal, giving our competitors the opportunity to outrun us.

Organic growth and reliable scaling

A product strategy for this phase should focus on organic growth and reliable scaling. Organic growth involves identifying and prioritizing growth areas, understanding driving factors, and setting appropriate goals. Then it is a lot about finding outputs that have the potential to make a difference, acting on it and measuring the outcomes — again, focusing on discovery. Many of these actions would revolve around introducing new value and removing friction in the user experience. The e-commerce sector has long excelled at this, and other digital products can adopt similar optimization tools and frameworks.

Reliable scaling requires continuous product and process optimization to remove bottlenecks.This entails optimizing the product design for scale, refactoring the codebase, ensuring the infrastructure can handle growth, streamlining operational processes, and enhancing team capabilities. These actions are crucial for meeting the increasing volumes of a growing business and they can’t be overlooked.

Navigating product maturity: product stability and future plans

After a sustained period of healthy growth, a product may reach a stable stage — maturity(C) — where significant growth is no longer observed. This is often due to market saturation, where the demand for the product has been largely fulfilled within the existing market. When rapid user acquisition is no longer feasible, our strategy should shift towards consolidation and maintenance, focusing on retention, customer loyalty, cost optimization, and careful investment. Additionally, it’s crucial to make decisions for the future during this phase. Without proactive decisions, the product may naturally decline, which can be a problem if your business is not ready to diversify into other activities. Extending growth(D) may require innovation and diversification to add new value and explore new markets or product lines.

In conclusion, viewing your digital products through the lens of their lifecycle enhances our ability to develop relevant product strategies. This approach helps set goals that align with both current business and product needs and prioritize the right activities. Companies that understand the process through which the product should progress during its lifespan establish a solid foundation for long-term thinking and investment decision-making, positioning themselves well for continued success.

About the author

The author Veronika Vallen, is a Product Manager, at the Futurice Helsinki office.

Aligning product lifecycle with strategy for optimal business impact was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last decade, the DevOps model has been celebrated for its agility and efficiency in developing and operating software systems. Yet, many companies still face prolonged throughput times and persistent quality and security issues in their DevOps workflows. To tackle these challenges, we’ve pioneered the LiveOps+DevOps model, reimagining how organizations can structure their development and production operations.

The original DevOps promise

The separation between development and operations has evolved through various models. In the 1990s and 2000s, a siloed, control-oriented approach was common, leading to issues like ticket-based communication and unclear responsibilities. The rise of DevOps in the 2010s aimed to address these problems by merging developers and operators into a single team, promising numerous benefits such as faster release cycles and improved quality. And at the start, it did look promising.

However, at the same time, the software, as well as the operating environment for it, changed dramatically. We’ve moved from desktop applications to always-online web applications, from single-user to collaboration, from individual web applications and servers to complex architectures and public cloud environments and cloud devops. Not to forget that the cybersecurity landscape has also become much harder to navigate.

All this got more complicated while DevOps team members were supposed to master it all.

Running a successful DevOps team is certainly possible, and many large-scale technology product companies have mastered that skill. It just takes a lot of people and time to get it right. Consider your own DevOps team. Does it include skilled professionals in at least the following areas?

• Frontend development
• Backend development
• Technical and solution architecture
• Quality Assurance
• Observability
• Platform engineering
• Cyber security
• IT Service Management
• On-call practices, schedules and agreed SLAs

Based on what we are seeing in Futurice’s Managed Services business unit, also known as FutuCare, most companies struggle to meet these requirements. For them, DevOps often fails to deliver on its initial promise.

LiveOps

Our venture to a new way of providing value-based maintenance started with the frustration towards traditional service desks. You know the drill: Send a ticket, wait for a reply, “Have you tried to reboot your computer?” Surely we can do better than this in the 2020s, right?

To address this, we established our own service desk, staffed with cloud experts, platform engineers, and software developers, and named it the LiveOps team. This team is equipped to not only respond to but also resolve most issues on first contact (ie. from the 1st level all the way to the traditional 3rd level). By handling these issues directly, we shield our original development teams, who traditionally serve as third-level support, from unnecessary interruptions. This allows them to focus on solving business-critical domain problems.

After a few iterations of adaptation, our LiveOps team is exceeding our expectations:

• 83 % of issues are being resolved on first contact
• 100 % of reaction time SLAs kept
• 93 % of resolving time SLAs kept (with average resolving time of 2 hours)
• Customer satisfaction is extremely high with a 4.9/5 CSAT score

Both our customers and employees love the new system, proving that our approach is making a significant impact.

LiveOps+DevOps

A DevOps team member is quite often expected to be a jack of all trades while truly being a master of none. Due to their predominantly developer backgrounds, DevOps teams tend to skew towards being 90% Dev and only 10% Ops.

In client organizations, development programs are typically driven by business units aiming for a competitive edge through new software solutions. This creates a scenario where the Product Owner prioritizes new feature development over maintenance and operational tasks.

As a result, operations-related issues are frequently neglected, leading to major, hard-to-fix problems when the software is in or nearing production. To mitigate these challenges, we decided to start to integrate our LiveOps team members into development projects from the early stages. This proactive approach prevents real-life problems from arising, and the results have been remarkable.

Our LiveOps+DevOps working model is based on the principle that LiveOps is not merely a support function.

Benefits

• Best practices and sane defaults for quicker time-to-market: There’s a difference in experience whether you’re doing something for the first or second time, or for the 20th time. Whether it’s Platform Engineering, Cyber Security, or Observability, our LiveOps experts bring extensive knowledge to the table. By leveraging this expertise from the outset, we ensure implementations that don’t require last-minute fixes before going into production.
• Experts available when needed. Our whole Modern Managed Services approach is built on the principle that you purchase a service, not specific individuals. If you need a Platform Engineer to create an efficient deployment pipeline for your application, our LiveOps Platform Engineers will be available and can handle it. This approach eliminates the need for you to hire a full-time expert for your development team.
• Great observability leads to better quality. Our LiveOps team employs a robust set of leading monitoring tools and practices. We integrate these into your solution from the beginning and advise your development team on best practices for cloud runtimes, logging, and application performance monitoring. This shift in the development mindset from “Will this work?” to “How do we know this will work?” and “Is the system working well enough?” significantly enhances your application’s quality and simplifies tracking KPIs.
• Hidden Ops work gets revealed and addressed. A common question from prospective clients is why their development activities are slowing over time. This is usually because operating a production system is demanding, and developers often underestimate the work involved. By tackling recurring issues — such as vulnerability scanning and dependency updates — with automation and processes like those used by our LiveOps team, we prevent the accumulation of blocking maintenance tasks.
• AI opportunities become easier to identify and realize. While integrating AI tools and capabilities into development workflows is often discussed, implementation can be challenging. However, since the LiveOps team regularly addresses similar issues, it’s more feasible to develop AI-driven processes and automations that enhance operational efficiency.
• More time to work on business problems. When the majority of maintenance and operations-related tasks have been moved to the LiveOps team, the DevOps team has more time to deliver business value through new feature development.
• Seamless transition to production. LiveOps+DevOps operating model ensures some of the most uneventful and boring production deployments, by design. We prioritize stability over excitement, resulting in smooth, reliable production launches.
• Smooth operation in production. By incorporating LiveOps early in the development program, we build a solid foundation for handling operational issues. Our LiveOps team transitions from enabling a solution to maintaining it. It’s like flipping a switch in our operations room — suddenly, you’re supported by our LiveOps Service Desk, backed by guaranteed SLAs.

What’s the “Plus DevOps” all about?

In this model, LiveOps is not intended to replace DevOps but to enhance it. While DevOps is an excellent methodology for building software, offloading certain tasks to a centralized LiveOps team is both logical and beneficial, simplifying processes and improving efficiency for everyone involved.

A LiveOps team member participates in the DevOps team’s agile meetings and operates as a normal team member. This integration is led by a single Service Lead, who acts as the single point of contact for the client. This ensures smooth development, efficient operations, and a seamless production environment.

More than anything, the LiveOps+DevOps working model offers a practical solution to a problem that, in theory, shouldn’t exist but, in practice, hinders many companies.

How to get started with LiveOps+DevOps?

At FutuCare, we truly believe that the LiveOps+DevOps model can supercharge most development programs. We’re eager to share our insights on how to implement it effectively.

Feel free to follow our four-step process, which we use to determine the best way to incorporate LiveOps+DevOps to meet our clients’ needs:

1. Assess the current state. Evaluate the number of applications in development and those already in production. Identify which production applications are business-critical and determine their SLA requirements.
2. Determine the potential. Identify common tasks across DevOps teams that could be centralized. Assess how much time individual DevOps teams currently spend on these tasks. Determine if this time could be better utilized or if the tasks could be executed with higher quality through centralization.
3. Build and roll out the LiveOps team in a gradual manner. Avoid moving all Ops work to LiveOps at once. For long-established DevOps teams, accumulated hidden knowledge can hinder this process. Start small by selecting specific work areas, such as the maintenance of deployment pipelines, to transition to the LiveOps team.
4. Let the LiveOps team improve things. The greatest benefits arise when LiveOps not only maintains but also enhances the assets it operates. LiveOps team members, motivated to streamline their work, will drive improvements in shared components, automation, and processes. Ensure they have sufficient bandwidth to innovate without being overwhelmed by their workload.

Both LiveOps and LiveOps+DevOps services are available to our existing and new Managed Services clients. Additionally, we offer advisory services to help you build this operational capability in-house.

About the author

Jouni Kaplas is a Tech Principal at Futurice.

Value-based maintenance helps you in two ways. It helps clarify service value and uncover hidden costs, making it easier to increase the former and decrease the latter. It also helps identify and eliminate activities that do not contribute to the core business value, thus freeing up time and enabling the business to focus on activities that matter most.

Every digital service must produce value

Creating and maintaining digital services is not cheap. All services must produce more value for the company than the costs of the service. Value service produces changes over time. If no actions are taken, usually it decreases. Either the world (or company) around changes and updates are needed just to keep it at the same level as before or the value decreases because of system deterioration.

Cost-effective maintenance is a delicate balance: value service creates vs investments required to keep/improve value vs costs. Driving down costs has been a common way of dealing with this equation but it is not always the optimal way.

Actual value vs potential value

The value of service needs to be monitored not only as the potential value service brings if it works perfectly, but also the current value it brings when it works as it works.

For example, a new service is created for employees to purchase mobile phones for work. This saves IT lots of manual work. The value of service is clear. However, the service is maintained poorly. It crashes often and the orders get stuck. IT has to do manual work to restart the service and answer employees’ tickets about why they haven’t received their new phone. Thus the actual value of the service is lower than the potential value.

The actual value can decrease gradually. If new changes or bug fixes are hard to implement because of poor or lacking maintenance, the service’s actual value keeps on dropping.

External costs vs all costs

The term “total cost of ownership” is used when calculating service lifetime costs. It also includes the maintenance and recurring costs, which are the biggest portion of total costs. But what about internal costs? “Internal costs” are work needed or wasted because of the service and its maintenance.

For example, the company has outsourced maintenance of its critical master data service to a vendor. Uptime requirements are tight and the vendor performs well. But almost every new business solution built will have to integrate with the master data service and getting required access, integration documentation, or any support for development is non-existent. Expensive development teams waste weeks or months because the maintenance partner doesn’t help them.

Or a new employee starts but getting all the required accesses takes weeks, multiple tickets, and email ping-pong. Every time. Lots of work hours are wasted.

Some companies try to use SLAs to avoid this, but SLAs are not the best tool for this. SLAs define the minimum required quality of service that has to be fulfilled but the vendor is not rewarded to do more. Or automate things. Or decrease the need for tickets in the first place by implementing self-service functionality.

How to implement Value-based maintenance?

Identify Value

The first step is to clearly define what “value” means for your business. It could be improved customer experience, time used at the site, increased uptime, cost reductions, or any other metric that directly impacts your business objectives. There can be more than one.

Measure Value

Measure the value of your service, both the potential value and the actual value. KPIs are good for measuring potential value and Service Level Objectives (SLOs) for the actual value. SLOs help you to understand the effectiveness of your maintenance activities and identify areas for improvement.

Prioritize Tasks

Once you’ve identified your value parameters, prioritize the maintenance tasks based on their potential impact on these values. This approach will help you focus on the tasks that offer the highest return on investment. Sometimes it is a new feature, sometimes reducing technical debt, building automation, or increasing self-service functionality.

Continuous Improvement

Value-based maintenance is not a one-time activity but a continuous process. Incorporate feedback, learn from your successes and failures, and constantly look for improvement.

Select the right partner

Instead of just selecting a maintenance partner with the lowest external cost, find a partner who can lower your internal costs, increase service value (both potential and actual), and help you measure value. This will lead to better ROI and also increase employee and customer satisfaction. A good maintenance partner can take the value to the contractual level, ensuring that there is an incentive to bring great value instead of just maximizing the amount of tickets.

Switching to a value-based approach can be a game-changer for your business maintenance strategy. It allows for strategic decision-making, efficient use of resources, and ultimately, a better bottom line. The best part of this transition is a clear understanding of your business objectives and customer needs. It makes your organization more customer-centric.

About the Author

Joonas Korpela, Vice President, leads Futurice’s modern managed services — FutuCare. He is passionate about combining the value of care with business success and continuous improvement. As a sports and wellbeing enthusiast, he loves to measure performance and aim for maximum sustainable levels; the same as the values he advocates at work.

Value-based maintenance takes full benefits from your valuable services was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 4/4

It’s no secret that listening to your customers makes good business. To succeed, we collect an increasing amount of customer data, map their journeys and include designers in our teams. But how does this impact your operations on an organizational scale? Is the data collected useful, seen and actionable by those who can make the changes? How do you manage the multiple moments of your many services? This article introduces ‘Journey Operations’ and why it works.

Journey Operations enables organizations to measure, manage and continuously improve services using journeys

Journey operations consist of three key components that work together within an agile system:

1. Value stream — The team responsible for the service, often organized around delivering value
2. Journey — The shared big picture of a service delivering value from a customer point of view
3. Metrics — Qualitative and quantitative data needed to evaluate the health of a service

A. Value stream

Let’s start with the product team. Traditionally we see teams organizing around channels. For example, one team will govern retail, one for the website and another for the application (channels). Though this is useful to keep those with the technical knowledge in one place — it’s not great for the customer. Let’s say I want to send a parcel or maybe sell an apartment. I will interact with many channels and people over a period of time, to achieve that goal. A team governing only a website would receive information from many people trying to achieve many goals, covering the whole range of what a company offers. This is very hard to design for, resulting in a fractured end-to-end customer and product team experience.

Alternatively, Journey Operations forms teams around delivering that value to your customers: called ‘Value Streams’. In my experience, great value streams are often named with ‘verbs’ — that signal the customer’s goal they enable e.g. sending, renting, tendering, ordering, installing, etc. As a result, an organization will typically have several Value Streams depending on the complexity of their value chain and size of the team needed to manage them. In addition, value streams give leadership a snapshot of how well value are being delivered throughout their value chain to allocate investment.

Successful streams include team members with three lenses:

• Business: Those who consider the business impact and needs of a service
• User: Those who champion all user’s experiences, especially the customer
• Tech: Those who enable the delivery of the service in the most effective way

Together the team creates services that are: technically feasible, customer desirable, and business viable.

B. Journey

Teams flourish with a shared end-to-end picture of their service: the journey. The journey connects all the activities that go into delivering viable value to your customer. A great way to kick off a value stream is to create the journey together, as a team. This way, everyone knows where to find it, how to use it and their role in delivering value.

Headlining your journey are the ‘Customer’s Jobs’. ‘Jobs’ are the; social, physical, and emotional tasks your customer is trying to do (e.g. know when their taxi arrives for pickup) to achieve their goal (e.g. arrive at their destination). Jobs should be validated to reflect your customer’s real-life actions, and not just describe your service. The layers below document how your service delivers the value, such as; employee jobs, touchpoints, stakeholders, systems,etc., creating a complete ‘service blueprint’. Finally, your customers’ experience, is the result of how well your service enables them to perform their jobs in order to ultimately achieve the value of your service (more on metrics below).

With Journey Operations, the journey becomes the backbone of your continuous innovation process — where insight, and initiatives can be connected to a moment in your service.

C. Metrics

Now you have a team, and a shared big picture of your service — but how do you know what to prioritize and improve? Continuous qualitative and quantitative data is useful on two levels of detail. On a high level, ‘journey metrics’ gives your team the pulse of how healthy your service is doing overall. On a more detailed level, ‘experience metrics’ indicate where the issues are occurring.

Journey metrics

Key journey metrics enable you to measure the (1) Business viability, (2) Operational performance, and (3) Customer experience, of your service. Some might recognise these as key performance indicators (KPIs) from three critical points of view.

To define these metrics, first ask the question: what is my customer, business, and operational goal? Then, what do I need to measure to evaluate how well we are doing in these areas? For example: business metrics may measure the revenue from several charging sessions (€income), operational metrics may measure: Vol. customer service contacts & servicing costs (€cost) and customer metrics may measure overall customer satisfaction upon using the service (%CSAT). Key journey metrics allow all stakeholders to evaluate the overall success of each new initiative, and where to focus the next improvement efforts.

Experience metrics

Experience metrics are connected to each phase of the journey offering more detailed insight. They measure how successfully your customer is able to perform specific jobs resulting in a positive or negative experience, good or bad business. Experience data can be qualitative or quantitative. For example: qualitative feedback from customer service, or quantitative volume of contacts. They might also show user volume information to identify drop-offs or how many users chose one option over another. The goal is to have a continuous stream of actionable live data for continuous improvement. More mature teams will have a dashboard on a team and organizational level.

Once your journey metrics are in place, the success of your initiatives can be automatically measured because they are how you define service success. The difference with value streams also owning these metrics, is that they have the information to make decisions and drive informed change.

How it all works together

With these key artifacts: journey, metrics and valuesteams — you have the ingredients for continuously; measuring, managing and improving your service. Here’s how it all works together;

Using metrics, your team can identify opportunities to improve the: customer experience, operational efficiency, or business performance. A good metric set-up should give you evidence to prioritize the most impactful opportunities. If your origination utilizes a goal-setting framework e.g. OKR model, you can choose which opportunities might best help you to reach your objective.

Your journey metrics should give more clues about root causes. Service and product design skills play a key role in validating how the problem is understood and best way to solve it. This not only maximizes the opportunities to elevate the customer experience but limits the risk of investing in something that doesn’t add the value you are expecting. Once your solution is defined as an initiative (a solution with a clear problem to solve within 1–3 months of development), you’re ready to build. Each initiative should include success metrics that you can evaluate before and after results.

Through this approach, organizations can make informed decisions to continuously deliver customer and business value. Service teams have a shared view of the services they are responsible for, and full agency to deliver value. Where to start and details of what works best depends entirely on the organization. In my experience, any transformation requires a topdown enablers and bottom up action. I’d always recommend, starting small e.g with one value stream, then scale what works.

About the author

Rosie Trudgen is working as a Lead Service Designer at Futurice. Rosie works with multidisciplinary teams to continuously improve their services and create new ones leveraging emerging tech

The breathesimple approach

At its core, breathesimple is an innovative app that integrates with a wearable ring to enhance your sleep quality. The ring monitors your blood oxygen levels (Sp02) and heart rate accurately and continuously. The app operates in two main modes:

1. Sleep Mode: In this mode, the ring tracks your blood oxygen levels throughout the night. It calculates the Oxygen Desaturation Index (ODI), which indicates how frequently your blood oxygen level drops. This measurement is crucial for identifying sleep apnea and other related breathing issues like snoring.
2. Breath Training Mode: This mode focuses on improving your breathing quality through guided exercises. The ring’s precise heart rate monitoring, combined with advanced algorithms, assesses your breathing. The exercises use the phenomenon of neuroplasticity to rewire the brain’s automatic breathing control patterns. Better breathing means more energy, less stress, and better sleep.

So the app can not only monitor and track how well you sleep but also coaches you to breathe and sleep better.

Overcoming technical challenges

Our journey wasn’t without its hurdles. Here are some key challenges we faced:

• Integrating with the wearable: Since we lacked full access to the ring manufacturer’s binary files, we needed a way to bridge our React Native application with the device. The solution lay in creating a custom Native Module written in Swift. By implementing the RCTBridgeModule protocol, we defined methods that could be exposed to our JavaScript code. After registering this module with the React Native bridge, we could seamlessly communicate with the ring using the NativeModules API from within our JavaScript components. This highlights the ease with which React Native allows for the creation of tailored native components using Swift.
• Pairing Process: Limited access to the ring’s resources initially made Bluetooth pairing tricky. Once our custom code could interface with the ring, we gained fine-grained control over its state.
• Leveraging Legacy Algorithms: Repurposing pre-existing algorithms for the specific needs of breathesimple required careful adaptation and integration.

The development experience

Our primary goal was a functional, testable proof-of-concept (POC). That said, we didn’t want to sacrifice aesthetics entirely. React Native Elements proved invaluable, providing a library of pre-styled UI components to streamline our development process.

Why this matters

breathesimple showcases how software and hardware can converge in the medical field to produce solutions with tangible benefits. The sleep disorder market is vast, and our project offers a potential avenue for disruption through accessible, technology-driven interventions.

Lessons learnt

• React Native’s versatility: Building a health-focused app that interfaces with external hardware demonstrates the flexibility of the React Native framework.
• The power of custom modules: When off-the-shelf solutions aren’t available, extending React Native with native modules (like our Swift code) allows projects to overcome limitations.
• Data-Driven healthcare: The importance of robust algorithms for translating raw physiological data into meaningful health insights is highlighted in breathesimple’s sleep analysis capabilities.

What’s next?

Our sleep monitoring app vision is to enhance the user experience through algorithm refinements, improved sleep monitoring using AI-supported detection of breathing instabilities, advanced data analysis to determine apnea phenotypes, and partnerships with other device manufacturers. Our goal is to create a comprehensive solution that empowers individuals to manage their sleep and improve their well-being.

About the author

Sachin Jethwa is an Engineering Manager with a passion for building robust, scalable software solutions. With expertise in React, React Native, and agile development methodologies, he excels at driving technical excellence and fostering collaboration within engineering teams.

breathesimple: Building a React Native app to combat sleep disorders was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 3/4

In today’s business landscape, organizations are increasingly recognizing the importance of design in driving business success. However, the challenge often lies in effectively harnessing the power of design, especially as companies scale and grow. This is where Design Operations, or DesignOps, comes into play.

What is DesignOps

DesignOps refers to the orchestration and optimization of people, processes, and craft to amplify design’s value and impact at scale. The primary mission of DesignOps is to set up design teams for success by establishing a clear design culture, efficient people operations, streamlined workflows, and effective tools. It ensures that designers can concentrate on their work instead of grappling with operational challenges.

DesignOps focuses on four key layers: Design Culture, People, Ways of working, and Tools & Infrastructure.

Design culture: A strong design culture is pivotal to the success and health of design teams. DesignOps emphasizes the importance of defining the purpose of the design team, promoting a culture of sharing insights and expertise and establishing strong collaboration across departments.

People: Effective people operations contribute to the long-term health of design teams. DesignOps addresses this by role mapping, defining career growth paths for designers, and streamlining recruitment and onboarding processes.

Ways of Working: DesignOps focuses on streamlining workflows and improving design processes, considering process & operating rhythm, enhancing teamwork and communication within and across teams, and facilitating knowledge sharing and continuous improvement.

Tools & Infrastructure: In the complex landscape of design tools, DesignOps ensures standardization, addressing storage, licenses, and device management, and providing training to ensure designers are proficient in using the tools at their disposal.

Why DesignOps is important

Traditionally, design was seen as a linear step in the product development chain, disconnected from other business functions. However, the paradigm has shifted, and design now permeates throughout the entire product development and delivery process. Design maturity, a measure of how well design practices are integrated into business processes, has become crucial for positive outcomes in product, position, and profit.

Companies with mature design functions can directly link their design teams’ work to increased revenue. As design maturity grows within an organization, the need for a systematic approach to design management becomes paramount.

How to proceed with DesignOps

Embarking on the journey of implementing DesignOps requires a thoughtful and strategic approach. The process for DesignOps is unique to every organization, but it usually has three phases:

1. Current state analysis

The initial step in the DesignOps implementation journey involves a comprehensive examination of the current design landscape. This analysis delves into existing design processes, tools, and team dynamics. By identifying pain points and areas for improvement, organizations gain valuable insights that serve as the foundation for designing a more efficient and collaborative future.

2. Defining the DesignOps vision

With a clear understanding of the current state, the next stride in DesignOps implementation is the articulation of a vision. This vision outlines the desired state of design operations within the organization including all four layers of DesignOps: design culture, people, ways of working, and tools & Infrastructure.

3. Pilot and scale the model

Once the vision is defined, organizations can embark on pilot projects to test the effectiveness of DesignOps initiatives in a controlled environment. This phase allows for adjustments and refinements based on real-world feedback. Successful pilot projects serve as the springboard for scaling the DesignOps model across the organization. This phased approach ensures that DesignOps becomes an integral part of the organization’s design culture, driving continuous improvement and innovation.

Conclusion

DesignOps plays a pivotal role in amplifying the value of design within organizations. By focusing on culture, people, workflows, and tools, DesignOps ensures that design teams can scale efficiently and deliver impactful outcomes. As organizations continue to recognize the strategic importance of design, investing in DesignOps becomes not just a choice but a necessity for sustainable growth and success.

About the author

Sami Haikonen is a Design Director specializing in Brand experience and User Experience design, and the development of operational models for design teams.

Amplifying the value of design: An introduction to Design Operations was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

In particular, Next.js, a JavaScript framework from the creators of Vercel has been a favourite. After shipping a few projects using Next.js, including for Jagex and WRAP, we decided to partner with Vercel to show how much we value their view of building modern web apps. Let me walk you through what we love about building with Next.js and Vercel.

Choosing the right tools

When considering to (re-)build web applications for our clients, we take certain considerations into mind. We only suggest tools and stacks that we fully believe in and have tested thoroughly ourselves.

Developer experience is key, for our own people and also to ensure that future developers can have an enjoyable experience maintaining applications for our clients. In the last 8+ years, we mostly opted for React, the popular JavaScript framework, due to its popularity amongst talented developers and great community support. React has been great to build solid single-page client-side applications with a seamless experience for users.

Working with pure React in its early days presented several challenges, however. Client-side rendering (CSR) often resulted in slower initial page loads (often caused by slow server-client network waterfalls) and limited SEO options due to the lack of pre-rendered content. Data fetching required manual implementation, leading to boilerplate code and potential performance bottlenecks. Additionally, the absence of a built-in router necessitated the use of third-party libraries, adding complexity to the development process.

However, the emergence of modern frameworks like Next.js has revolutionised React development by introducing Server Components. These components pre-render on the server, significantly improving initial load times and SEO. Next.js also offers built-in data fetching capabilities and a robust routing system, streamlining the development process and enhancing the overall user experience. This shift towards server-rendered components addresses many of the historical pain points associated with pure React and paved the way for a more performant and developer-friendly web development experience.

Next.js

Next.js is a powerful and versatile framework that offers compelling reasons to choose it for developing modern web applications. One of its key advantages is its built-in support for server-side rendering (SSR) and static site generation (SSG), enabling faster page loads and improved performance. This not only enhances the user experience but also contributes to better SEO results. Next.js integrates nicely with React, which means a familiar and efficient development experience for React developers. Its automatic code-splitting feature optimises the application’s bundle size, ensuring that only necessary code is loaded, resulting in faster load times. The framework also comes with an intuitive file-based routing system, simplifying the organisation of code and making navigation more straightforward. Additionally, Next.js supports a wide range of data-fetching strategies, including server-side data fetching and incremental static regeneration, offering flexibility in handling dynamic content.

Vercel

As a platform for deploying your web application, Vercel streamlines web development by automating deployments and continuously integrating code changes. In its core functionality, it is similar to other platforms like Netlify and Heroku, however, it comes with seamless integration and optimization specifically for Next.js apps and a global edge network to deliver content with low latency worldwide.

Vercel offers zero-configuration deployment for Next.js apps and provides support for serverless functions and HTTPS certificate handling. You can also bundle and ship Next.js applications to the provider of your choice but with additional integration and configuration effort. For us the simplicity and convenience outweigh the potential greater flexibility you can have with self-hosting. Depending on your personal setup or company restrictions this might differ of course.

With its automatic deployment and continuous integration features, Vercel ensures that updates are deployed whenever changes are pushed to the repository, streamlining the development workflow. When integrated with GitHub, every Pull Request gets its dedicated preview environment which makes viewing changes, especially for non-technical roles in our teams much easier.

Vercel’s collaboration features make it easier for development teams to work together, and I personally like the comment feature for preview deployments which easily allowed one of my designer colleagues to leave feedback directly on the page for me to investigate. In addition, the integration with popular version control systems like Git and support for environment variables enhance the platform’s flexibility and security.

One of Vercel’s unique selling points lies in its global edge network, an integrated Content Delivery Network (CDN) that caches content in strategic locations. This ensures content gets delivered with reduced load times, regardless of the user’s location. Especially when working with clients that have a global user base this offers a cost-effective solution instead of configuring a separate CDN.

An exciting future ahead

The team around Guillermo Rauch (CEO of Vercel) is constantly working on expanding Vercel, and there are some recently released or announced features that we are particularly excited about:

1. AI SDK: An open-source library to build conversational streaming user interfaces using existing components from your applications
2. Partial Pre-rendering: This feature combines the benefits of fast static rendering and personalised dynamic rendering. It allows users to pre-render only the parts of the page that need to be personalised, while the rest of the page is statically rendered.
3. DX Platform: The new DX platform with monorepo support, code owners, and conformance provides security at a glance and health reporting in one view. It allows users to manage their projects more efficiently and securely.
4. v0.dev: Vercel’s GenAI website builder that allows you to generate entire web interfaces including React component trees via single prompts.
5. Draft Mode: This feature enables cross-discipline collaboration by allowing users to comment and edit content in preview builds. It is a great way to get feedback from team members and stakeholders before publishing the content.

Outlook

Web development has been changing rapidly over the past decade and it most likely will transform even more within the upcoming years. No-code and low-code solutions will become more reliable and should have their place in the wide web dev ecosystem as they provide a low entry barrier platform for everyone to create impressive web experiences. Generative AI has proven its potential and tools like v0.dev are simply the beginning of allowing users to build their own custom web experiences with just a few prompts.

And on the other hand web applications need to become smarter as well, it’s not enough anymore to just optimise for SEO and consider simple personalization based on IP location. With the rise of GenAI and more sophisticated Customer Data platforms (CDPs) customers expect new products to tailor to their needs and provide a minimum of smart content as well as user-generated content. For those kinds of applications, the market for fully custom builds will still exist and tools like NextJS and Vercel ensure that they will be reliable, fast, and enjoyable to build and iterate on.

If you want to get started — I recommend the Next.js interactive courses at Next.JS Learn where you’ll be guided to build your own full-stack e-commerce system. And if you’d like to discuss building something with Next.js and Vercel feel free to reach out to me directly.

About the Author

Tino Junge is an experienced technical consultant and engineer at heart who led multiple engagements building high-quality software products while balancing business and user needs. He gets motivated about learning new technologies and improving developer experience while building products that solve actual user problems.

Building modern web apps with Next.js and Vercel was originally published in Futurice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 2/4

This is the second article in our series exploring the multifaceted value of design in today’s digital landscape. Through this series, we aim to uncover and articulate how strategic design decisions can significantly impact business outcomes and customer experiences. Stay tuned as we continue to delve into the various dimensions of design value, providing insights and actionable strategies to leverage design as a key driver of digital success.

Creating standout services demands more than sleek design or innovative technology. At Futurice, we craft service concepts that seamlessly combine digital and physical channels to not only address current challenges but also drive substantial business value. These concepts enhance customer loyalty, open new revenue streams, and distinguish brands in competitive markets, making a tangible difference in both the market and user experience.

What is a service concept and why are they important?

A service concept is much more than a blueprint for a future offering; it’s a comprehensive framework that defines how a service will be delivered, experienced, and perceived by its users. It encapsulates the service’s essence, including its purpose, the problems it solves, how it benefits users, and the underlying technology that enables it. This concept goes beyond mere functionality, integrating strategic thinking, design innovation, and technology to precisely address user needs and surpass business objectives.

From a business perspective, new service concepts are invaluable. They can tap into new revenue streams by reaching untapped customer segments or markets, gathering extensive insights or data about these groups, and enhancing understanding of market dynamics. Innovatively designed services not only elevate visibility but also significantly boost brand value. By offering unique solutions that stand out in the marketplace, companies can differentiate themselves from competitors, fostering loyalty and driving sustainable growth.

How are great concepts built at Futurice?

The development of transformative service concepts follows a comprehensive process:

Understanding user needs: Through empathetic research methods like interviews, surveys, and observational studies, we gather insights into the challenges, desires, and behaviors of our target users which ensures our concepts are rooted in genuine user needs. This is especially important when targeting new markets or customer segments.

Market analysis for opportunity identification: We analyze market trends, competitor strategies, and technological advancements to identify gaps and opportunities where our services can offer significant value.

Creative ideation and rapid prototyping: Our teams engage in brainstorming and ideation sessions to explore various solutions. Early prototyping allows for quick visualization and assessment of these ideas, fostering an innovative and experimental culture.

Iterative design and user feedback: Prototyping and user testing are iterative, involving real users to refine the concept based on feedback. This ensures the service is both desirable and viable, tailored to meet actual user needs.

Branding and visual identity: A crucial step in the concept phase is establishing a compelling brand identity and visual design strategy. This includes crafting a unique brand voice, visual aesthetics, and a cohesive user experience that effectively communicates a value proposition and resonates with the target audience.

Technical and feasibility assessment: Our technology experts evaluate the concept’s technical feasibility, ensuring the envisioned solution can be realistically developed with current or near-future technologies.

What makes a great concept

A great service concept is distinguished by several key characteristics:

Genuine user value: It must stem from a deep understanding of user needs, offering a solution that significantly improves their life or work.

Innovative edge: The concept should introduce a novel approach or technology, differentiating it from existing solutions and pushing the boundaries of what’s currently available.

Technical feasibility: Beyond being imaginative, the concept must be technically achievable, leveraging current or near-future technologies in a practical, efficient manner.

Business strategy alignment: It should resonate with the company’s strategic goals, demonstrating clear potential for market success and growth.

Sustainability consideration: In today’s world, concepts must also account for their environmental and social impact, aiming for sustainability and ethical integrity.

Our portfolio showcases a variety of innovative service concepts we’ve developed, from advanced digital platforms to evolved services in the physical realm. Each project highlights our commitment to excellence, innovation, and creating meaningful impact through design.

About the author

Joakim Schonert, a seasoned design leader at Futurice, based in Helsinki, Finland, brings over twenty-five years of experience in product design, service design, and design leadership. He has also founded and managed various design-focused ventures, showcasing his entrepreneurial spirit and dedication to design innovation. Driven by a passion for emerging technologies and continual learning, he remains committed to shaping the future of design through leadership and creativity.