Production
For us, a digital product is any piece of software designed with a specific purpose in mind. Each product reflects the context in which it is used and the objectives of its creators.
Creating a successful digital product requires a combination of professional skills, including service design, digital design, software development, testing, analytics, and marketing.
The final product can be a mobile app, web service or any piece of software – with endless possibilities across platforms and use cases.
Digital product development projects can take many forms. For example, improving the performance of an established product is very different from creating a software product that introduces a new, disruptive business model.
Each project requires a tailor-made combination of efforts and skills. The work effort distribution varies across disciplines as the project progresses.
Our philosophy for building digital products is design-driven. This guides all ideas presented in this document.
Being design-driven means that the end user is at the center of our consideration from the get-go. This approach drives all phases of the project. A digital product must both serve its users and the business goals of its creators.
In digital product design, simple is beautiful and efficient. Ultimately, we believe that a design-driven approach is by far the most economical way of creating high quality digital products.
There is no shortage of digital products in the world – some are more useful than others. Our principle is to not produce digital waste. A high quality digital product has a clear reason to exist: it serves the needs of its users and the goals of the organisation behind it.
Quality also means delivering an intuitive user experience enabled by a robust technical implementation. Elegance is achieved when complex problems are transformed into simple, beautiful solutions.
Quality assurance is not a separate activity. Rather, it permeates the whole project. Quality is achieved through the right people, using appropriate processes and tools, supported by a sufficient budget.
This document outlines the fundamentals required to create high-quality digital products. Ultimately, the foundation of high quality rest on the commitment of everyone involved. Every decision from small to major must reflect this.
There is some variance in how agile is understood and applied in practice. For us, the most important principle of agile is collecting feedback at every phase of development – and having the willingness and ability to adjust course based on it.
In design, this means validating the ideas with interviews and prototypes and other service design tools and methods. In technical implementation, it involves peer reviews and thorough testing loops. Analytics further supports this process by providing data on user behaviour and key performance indicators, helping us measure progress and inform decisions.
A successful digital project must begin by establishing context, defining the goals and understanding available resources and constraints. All of these factors must be transparent to the entire team.
Only once this foundation is in place can the appropriate set of actions be chosen. This applies to projects of all shapes and sizes, and is perhaps the most important step when starting a project.
The size and composition of the team depend on both the project itself and its phase. We follow the principle of work pairs: every team member should have a partner to support their work.
A project should include a Product Owner. Representing the client, they can make decisions to support the higher level goals. The Project Manager is responsible for the deliverables. Other team members are selected based on the skills required.
Successful teamwork in projects has the same building blocks as any human relationships: mutual respect, trust, openness and the will to stay motivated and negotiate.
In every case, communication between all specialists should be established from the start – it’s a skill that takes practice.
Digital product development is a multi-disciplinary effort. A good team composition is a balanced combination of various areas of expertise. Individual team members can have multiple roles.
A Product Owner represents the client’s perspective in the project. They bring in-depth knowledge of the client’s business and how the digital product fits within it.
A Project Manager oversees the project as a whole, ensuring deadlines and KPIs are met, reporting progress, and coordinating follow-ups with all team members.
Service Designers are responsible for conducting user research and ensuring the product’s design is centred on the end users.
UX/UI designers work to turn research and business goals into intuitive, uncluttered user experiences. They work closely with developers to ensure that the UX aligns with the technical implementation.
Front-end developers work on the interactive layer of the technical implementation. Anything the user can see, touch, or click must work smoothly and be built in a way that allows for flexible changes.
Back-end developers are the architects of what happens under the hood of the digital product. How the product interacts with servers and APIs is crucial and can become complex depending on the product's requirements.
Gathering the right data tells us how well we’ve succeeded and informs us of the changes that need to be made in the following iterations.
Content guides the user and sets the tone of the product.
Marketing helps the product reach its intended audience and grow over time. The work can be both textual and visual and requires deep knowledge of marketing platforms.
Testing ensures that the solution is free of major bugs, secure, and fulfils all of its functional requirements.
Throughout a project, there will be hundreds or even thousands of decisions, both big and small, and all must support the overall vision. Most of these decisions should – and typically are – made collaboratively by the team.
The person ultimately responsible must have the final say, much like a captain on a ship. A wise captain, however, always involves the team to maximise commitment and contribution.
The work is typically split into a hierarchy of goals to be achieved. The naming conventions vary, but they can be e.g. milestones > epics > tasks.
The work is split into sprints. A sprint is a defined, fixed amount of calendar time or work effort – typically 2 to 10 weeks.
A sprint has a predefined set of outputs that should be achieved and related tasks. There can also be several concurrently ongoing sprints in a project. The sprint plans with associated timetables form the high level project plan.
The kick-off is the first official project meeting. It is often preceded by a round of quotation requests, offers, or internal business plans. The goal is to get to know each other, establish a shared understanding of the project context and objectives, and get the train moving.
A typical kick-off can last anywhere from a few hours to a full working day, during which next steps and a preliminary schedule are agreed upon.
Company introduction
Provide a concise overview of the client’s business, including key products, services, markets, and strategic goals.
Introducing the project team
Present the main team members from both the agency and client sides, including roles, responsibilities, and contact points. Include brief CVs and relevant references for the vendor’s team.
Introducing the project
Outline the initial concept and scope of the work, giving everyone a clear understanding of what will be created.Our initial plan for what we are about to create.
Goals
Define the objectives of the project and how success will be measured.
Planning the routines
Describe the recurring activities, such as meetings, communication channels, documentation practices, and version control methods.Weekly, meetings, communication, documentation, version control.
Schedule
Provide a detailed project plan and timeline, highlighting key milestones and deliverables.
Ground rules
Clarify agreements around the contract, budget, responsibilities, and available resources.
Next steps
List upcoming meetings, action items, and tasks to ensure everyone is aligned and knows what to do next.
Risks
Identify potential risks, assess their likelihood and impact, and suggest mitigation strategies to minimise project disruptions.
Design is about finding the essence of the required solution and giving it a functional and aesthetic form. An investment into good design enables cost-efficiency as only the essential is developed into the final product. There is no clear boundary between design and implementation in the context of digital products.
The philosophy behind finding the essential has been summarised by Winston Churchill: “If you want me to speak for two minutes, it will take me three weeks of preparation... If you want me to speak for an hour, I am ready now.”
Our design process is heavily inspired by Design Thinking and Lean methodologies.
For us, Design Thinking is all about being solution-oriented – the main role of design should always be mapping real issues and finding ways to solve them.
From Lean, we’re most influenced by the principle of involving both clients and end users in the iteration and testing process.
Co-design workshops that involve both us and the customer are a key component of our process. This way, we ensure we share the same vision and take advantage of the fact that the customer knows their own business field the best.
In the first workshops, we define the target group(s), goals of the product and hypotheses – and go through the potential obstacles known at that point. Typically, we then move on to creating user profiles and user paths.
Co-design tools are a powerful way of arriving at a shared vision for the product and making informed decisions regarding its design.
The Lean business model canvas is one of the most widely used brainstorming tools that helps gather the basics of the project in one easy-to-read template.
Featuring basic information like Opportunity, Solution, Competition, Value Proposition and Key Metrics, it helps solidify the purpose, goals, and challenges of the product we’re about to build.
User personas provide greater understanding of the people who will be using the product. These personas may include demographic information, financial information, marital status, lifestyle, descriptions of use situations, as well as goals, hopes, and fears related to using the service.
User journeys visualise the users’ interaction with the service over time. They can include descriptions of the various phases of the user journey, what actions are taken, and how different emotions and situations might affect the experience.
A prioritisation matrix is a tool for evaluating the different features of the project, making it clearer what to focus on.
Trigger cards are a creative ideation tool that can help the team move forward with brainstorming by posing various “what if” questions.
Designing UX is the process of collecting data, prioritizing, and presenting it in a format that offers a smooth experience for the user. Often, the best user experiences are almost unnoticeable in their intuitiveness.
Typically, UX design starts with creating information architecture (what information is necessary and how should it be organised?) and moves on to wireframes and prototypes that visualise the flow of the service. With these tools, the product can be tested with the users and other stakeholders before writing any code.
From information architecture to interactive prototypes, UX tools bring the planning and ideas to life.
Information architecture is about what information to present and how. Finding out what information is essential to the product and organising it in a way that’s intuitive for the user to navigate is a key component of a smooth user experience.
A more comprehensive description of what the product does, a service blueprint explains what should happen in the service at various levels during the user journey.
User testing should not be an afterthought. Rather, it is often a good idea to incorporate it into the design process from as early on as possible. In the end, only the data from actual users can reliably determine whether we’re making the right design choices.
Wireframes present the flow between the different views of the service. They're an effective tool for finding out whether moving within the service follows a clear logic: the user should never get stuck or lost.
With various prototyping tools, it is possible to create clickable versions of the service before moving into production. This is ideal for testing, as making even drastic changes to the UI is much faster and cheaper at this stage than during coding.
For us, Service Design is a seamless part of design. Depending on the project, we collect more in-depth data with observation and field studies. Typically, we conduct interviews and surveys to gain a clearer understanding of user needs and challenges.
User testing is also a normal part of our process, helping us validate both bigger ideas and highlight individual issues within the user paths.
The projects can also include service audits, where we research and test the usability or accessibility of the product.
UI design is much more than just visualising wireframes. Rather, modern user interfaces are built using components and dynamic styles.
Design systems can go beyond being component libraries – they can be a design philosophy that enables a more consistent customer and brand experience across whatever digital channels a client may use now or in the future.
Our tool of choice for UI design is Figma, due to its collaboration capabilities and flexibility. Over the years, we have built custom plugins for advanced prototyping and translating styles and components directly into reusable code.
A digital product is always a reflection of its technical implementation and vice versa. Implementation and design cannot be separated from each other. Both must be present from the start.
Technical implementation can follow many approaches – some are better fits than others.
The chosen methods are always a compromise between various factors. The choices should be made to ensure they stand the test of time and are easy to upgrade based on feedback from real-world use.
Small is beautiful
From information architecture to interactive prototypes, UX tools bring the planning and ideas to life.
Simple is elegant
Over-engineering is a common trap. Don’t introduce needless complexity. Don’t try to solve problems you don’t have.
Re-use is smart
Reinventing the wheel is not efficient or economical. Do it right once, and it keeps paying dividends.
Stable technologies over fashionable technologies
You don’t want to rely on “the new hotness” in production. The boring, battle-tested option is nearly always the right one.
YAGNI (You Ain’t Gonna Need It)
Build what is needed now, not what might be needed in the future. Build it smart so it’s easy to extend later.
Light and informal (mostly) over heavy and formal
Unless lives are on the line, you don’t need exhaustive change management or cumbersome quality control processes. Common sense and code reviews are the way to go.
There are multiple facets that need to be taken into consideration when designing the technical architecture. Here are some of the principles we incorporate in our work.
Based on the different user requirements, there are multiple possible ways to solve the problem, each providing its own set of benefits and drawbacks.
We strive to use the most suitable tools for the task and only a necessary amount of fundamental building blocks. Dependencies are liabilities, so we tend to be conservative about them.
The customer might have their own technology stack in use – we always try to fit in whilst incorporating our own tools of choice if possible. If the impedance mismatch is too big, it is our responsibility to be honest about it and possibly skip the project altogether.
The project team’s skills and expertise should always guide the choice of technology stack for the project, ensuring it aligns with both the team’s capabilities and the project’s goals.
All technology choices should be realistic in relation to the budget. Where budgets are tight, we go with the principle of “test manually and create a good product” overextending resources on automated unit or integration testing that cannot be properly supported.
On the back end, we take a conservative approach: using VPS, automating deployments with Ansible, and keeping systems as simple and dependency-free as possible. For most solutions, maintaining cloud-provider independence is also recommended.
Most services perform well with vertical scaling when needed — in practice, this means upgrading to more powerful machines rather than building a cluster right away. Vertical scaling is sufficient for most long-term use cases, whereas clustering adds complexity that may not be justified for the project’s scope.
We use automated service setup through Ansible, with core security principles built in by default. Leveraging these tools ensures a secure and consistent foundation from the start.
Using the proper algorithms and ensuring the database tables are indexed goes a long way. We don’t try to optimise until we know where the bottlenecks in the system under development will be.
We tend to build clusters with VPSs and ensure reliability through basic distributed systems principles.
We try to stick to components that are already widely used and known to work as expected. Naturally, there are also some projects where experimenting with new components carries a lower risk.
The best way to be flexible is to stick to best practices within the given framework as closely as possible.
When we create new abstractions, it’s not because we’re, for example, “unsatisfied with the way things are in Django.” Rather, such decisions must be justified by the use case and solve a real problem that would be more difficult to address otherwise. Sticking close to our tools is worth biting the bullet for at times.
Some projects allow for more exploratory and bold technological decisions. In such cases, it’s crucial to ensure that everyone involved understands the potential benefits and pitfalls of the chosen approach before moving forward.
All projects tend to share certain aspects in their fundamental design. We aim to design systems by separating them into autonomous units that can work independently on subtasks wherever possible.
Early in the process, it is important to understand both the data and the data flow patterns within the system. This understanding helps shape the rest of the solution around a solid foundation.
We recommend using a relational database as the primary data persistence layer. However, when there are strong offline requirements involving multiple users interacting with the same dataset, we opt for PouchDB/CouchDB-based solutions.
When multiple services are required, inter-process communication is typically built around message queue abstractions, such as RabbitMQ or Redis. In some cases, we use HTTP REST APIs as the communication layer as well – but only when the API is also used by other clients and there is no practical way to make it queue-based.
Depending on requirements higher up the stack, we evaluate the interactions between the client and backend services to determine whether a REST- or GraphQL-based solution is more appropriate.
Typically, we create the environment based on an existing project. We have experimented with creating templates but found it difficult to implement cost-efficient, one-size-fits-all solutions this way.
Having completed hundreds of projects, we now have reference projects available for most needs. We recognise that this is not the case for everyone. This remains a topic of ongoing investigation for us – we’re always interested in hearing about better alternatives.
In larger projects involving many people, we always organise the work using a Kanban-style agile process. Each sprint is planned, and stories are created in Shortcut, which has an in-house integration with GitLab to keep everything in sync.
We recommend providing an estimate for every issue in Shortcut. If an issue is estimated to take more than four days, it should be split into smaller issues to gain a clearer understanding of the required work.
The backlog is organised by priority, so developers can simply pick the top task once their previous one has been merged.
Once a developer picks the highest-priority issue to implement, the work begins in a new branch, which can be created automatically in GitLab.
The developer then proceeds with the implementation, seeking input or advice from project members, the client, or colleagues as needed. When the implementation is complete, a reviewer is assigned to the issue, and a code review is conducted. After all findings have been addressed, the code is merged into the relevant branch, and the CI/CD pipelines handle the deployment.
If the budget allows, we always recommend covering at least the most critical parts of the solution with unit and integration tests. Combined with a good plan for manual testing, this is sufficient for most small-scale projects.
When introducing UI tests, it is best to implement them when the user interface is to close to completion.
Each project should have at least the basic CI setup in, for example, GitLab, to ensure the work is packaged, tested and deployed to the environments properly. We maintain a solid set of CI configurations that can be incorporated into new projects – and are easily worth the initial investment.
We also include a standard set of metrics and monitoring for backend services, along with Sentry and other tools that enable proactive detection of issues and system errors, often before users even have a chance to notice them.
Having monitoring and error reporting for both the back end and front end makes it possible to quickly react to issues in production.
The specific data to be collected and monitored depends on the service. From a technical standpoint, it should be selected on the basis of what best enables us to stay on top of things when preventing and dealing with possible issues. Certain metrics are always relevant, such as CPU and memory usage, instance load and the number of successful requests.
Once the CD pipelines are in place, it becomes easy to update the system after the problem has been identified.
Testing is an integral part of every phase of digital development. No software is bug-free but reliability requirements vary greatly: issues in aviation software are not the same as those in a mobile game.
Defining these requirements and the testing process is essential for results that meet everyone's expectations. A key aspect of testing is ensuring that problems can be detected even after the digital product has been deployed.
A testing plan defines the rules and goals for testing in a way that best serves the project.
We define what is in or out of scope for our testing efforts, who is responsible for organising and implementing each area of testing, which environments must be taken into account, and what the testing schedule looks like.
Time and budget will always impose constraints on testing. The test plan should reflect a shared understanding of what quality means in the context of the project.
There’s a large number of operating system and device combinations to consider when testing mobile applications. For web apps, the same applies to browsers and their versions.
To determine which use cases should be prioritised, the device & operating system test matrix (for mobile apps) and device & browser test matrix (for web apps) are useful tools.
Based on the current market data and the specific requirements of the product, we create a map of probable OS, device and version combinations. These can then be prioritised based on time and budget.
Processes, responsibilities and goals
Define testing goals, responsibilities, and quality criteria. Create a spreadsheet mapping user interactions within the software. Form an internal test group.
Testing instructions
Create a testing instructions document and distribute it to all relevant parties. List known issues prior to the testing phase.
Distribution to the client
Form a client test group. Distribute the product using a selected prototyping or testing tool. Provide training or guidance for the client on how to use the tool effectively.
Functional testing
Conduct end-to-end testing to verify core functionality.
Documenting the test results
Create and maintain a test transcript to record outcomes and observations.
Moving the issues to GL
Highlight identified issues and add them to GitLab for tracking and resolution.
Compatibility testing
Test across different devices, browsers, operating systems, and configurations.
A deeper dive into analytics is outside this document’s scope. Here, we’ll focus on a general checklist that can be expanded upon depending on your project’s needs.
The first rule of data is: you can never get back what you didn’t collect. Therefore, the product should be integrated with the right analytics tools from the very beginning.
Having data over a longer time period makes it possible to use it in more sophisticated ways later on. When data from other sources – such as digital marketing – becomes available, it should also be integrated into your analytics setup.
From a technical perspective, collecting error logs is essential for identifying and fixing bugs and usability issues throughout the product's lifecycle.
Creating an analytics setup should begin with a discussion: what are our KPIs? How do we measure usage patterns? Which actions count as conversions? Can we link our marketing channels with analytics to measure campaign success?
The most used analytics platforms offer abundant features, but it is up to the team to ensure the setup and integrations work as intended.
Once the basic analytics setup is ready, it is a good idea to bring the essential metrics to a dashboard for easy access.
Every digital project comes with risks – internal and external – some of which are more likely than others. Most software integrates with third-party services, making it vulnerable to any issues those services might experience.
Risk control includes preparation and procedures for action when problems are encountered. One effective framework for risk handling is the OODA loop, originally developed by the U.S. Air Force. It provides a structured, four-step approach that should be implemented by the responsible organisation:
Observation
Identify and observe the problem – preferably before it occurs.
Orientation
Determine the severity and scope of the problem.
Decision
Make informed decisions based on the available information and analysis.
Action
Execute the chosen course of action and monitor its effectiveness.
A thorough threat and security analysis helps both to mitigate potential dangers and to ensure that a plan is in place in case something goes wrong. Preparation and backup plans are essential to minimising risks and maintaining the resilience of a system.
Risks related to third-party services can range from temporary downtime to data corruption. These are best avoided by decentralising the service across multiple providers and maintaining private backups of critical data whenever possible.
Third-party services are also prone to change over time, so it is often a smart idea to design the technical architecture in a way that minimises dependency on the implementation details of any single external product.
DDoS attacks, data theft, and other criminal activities are always a possibility. To minimise risks, it’s important to avoid the “everything behind one locked door” approach by maintaining unique and secure configurations.
Security-focused DevOps expertise is a valuable asset within any development team. Encrypting sensitive data and storing databases on separate, high-security servers are often necessary practices.
Unit and integration tests are essential. They make it possible to implement changes and continue development with a reduced risk of components or products breaking. Budget-wise, this should always be taken properly into account.
In addition, there should never be a situation where only one person truly understands a piece of code. This risk can be mitigated through collaborative peer review practices within the development team.
Social risks include issues in personal relationships, key personnel leaving the companies and problems within the work culture. It is better to have cohesive teams that work well together and document their work thoroughly, rather than relying on individual “rockstars.” Good documentation also makes it easier for new team members to join and contribute effectively.
Culture-wise, supporting and monitoring team wellbeing while encouraging open discussion is essential. Social issues should always be treated as a high priority, with emphasis placed on proactive measures that help prevent such problems from arising in the first place.
Software development is not immune to force majeure situations (accidents, vandalism, war, environmental catastrophes).
The world is unpredictable, so is crucial to have a process for creating offsite backups that remain up to date, as well as ensuring that the physical premises are protected by appropriate safety measures.
Data can be lost due to file corruption or physical damage. Storing data securely in multiple locations– both digital and physical – helps ensure that the team can sleep well at night.
The most important aspects of a successful digital product are clear goals, the right skills, proper tools – and last but definitely not least, teamwork.
When these pieces are in place, a digital project can become an inspiring journey from an idea to a finished product.
Let’s get to work!
No matter where you are on your digitalisation journey, we encourage you to get in touch.
Office Coordinator
vilma.merikanto@taiste.com+358445568459Have a question related to events, co-operation etc.? Our Office coordinator Vilma is happy to help.
Considering applying to work at Taiste? Our HR Manager Laura can aid you with any questions you might have.
