How we build products and work with clients

At Reboot we have a strong opinion on how digital products should be developed, which is understanding design and development as an indivisible whole throughout the entire process . Our vision as previous founders of a product startup may be somewhat biased, but it is the way we understand that it is possible to create great products.

When you work with clients this is not always possible, since many times the different areas of the product are divided into different vendors -design, development, brand- or part is managed in-house and part outsourced. In these cases, it is essential to establish good communication from the beginning for the success of the project and, unlike many people think, does not consist of having more meetings. Sometimes less.

In this post we want to explain what our process is when we create products and how we involve and communicate with our customers.

1. Discovery

At Reboot we combine our experience in the design and development of digital products with the experience and knowledge of our clients in their sector. In the first phase, we understand the problem to be solved, the audience and the competitive environment of the sector.

This helps us to establish the direction at the product level, understanding what other market players are offering and how we can improve it considering the purpose and the audience we are targeting.

We assume that our clients are already experts in their market. We may challenge some of your assumptions, but we do not do market research or validation work. When a project arrives in a stage prior to the PMF (Product Market Fit), we work on creating a MVP that allows the client to validate or discard the business hypothesis efficiently in time and resources.

Kickoff

All our projects start with a Kickoff meeting where the main stakeholders are present. In this meeting we establish the goals, a realistic roadmap and how we will communicate throughout the project. Depending on the type of project, we will be able to anticipate the approach proposed at the product level -technologies, architecture, services that will be used. Of course, we will address any doubt or question about the project.

Research

In the following days we will begin to research in parallel in:

  • Technology. Based on the objectives and requirements, we will research which technology, architecture and approach are best suited. If it is necessary to use external APIs or integrate with existing services, we will see what the limits are and how we can work to make them work.
  • Product. We benchmark the competitive environment to understand what competitive products look like and what they offer. This will help us to understand what the user's expectation is and how we can exceed it.

    • This phase does not have a specific duration, it will always depend on the magnitude and complexity of the project.

    Proposal

    We present the results of our research with a firm proposal on the product development stack. Our specialty is JavaScript and its frameworks so it will always be a proposal aligned with our knowledge, but we never rule out using new technologies if they are appropriate for the project or non-code approaches for MVP or rapid prototypes.

    2. Production

    We get to work. The production phase can vary greatly depending on the type of project. In the projects in which we are responsible for design and development, we begin to work in parallel on both.

    This is only possible when design and development are treated as one. So that we can begin to build the fundamentals of the product that are not susceptible to change while the experience and the interface are defined from design. The advantage for the customer is very clear: shorter production times and an earlier product launch.

    Wireframes

    We define the most basic architecture of the product and focus the conversation solely on the content and its hierarchy. Here there are still no colors, fonts or other graphic elements, the important thing is to lay the foundations.

    Our wireframing process has two phases:

  • Low Fidelity Wireframe. It is the minimal expression of the interface. We only work with boxes that represent the different types of content in grayscale. The objective is to determine the content and its hierarchy.
  • High Fidelity Wireframe. In this phase we incorporate the copies and some recognizable graphic elements such as buttons or icons.

    • Visual Design

    Once we have validated the wireframes and copies of the application, we begin to work on the visual design of the product. Again, this phase can vary greatly depending on the starting point.

    If the client has clear brand guidelines, we will use this as the main input for the development of the visual design. If it is a completely new project, we use different techniques such as Moodboard, references provided by the client, the values to be transmitted or the target audience in order to generate a consistent visual design.

    The final result is a Style Guide that includes the color palette, typographic fonts and their uses, iconography, buttons or spacing rules. This guide serves as documentation and future reference in order to evolve the project while maintaining its coherence.

    Prototype

    Before moving on to development, we create a prototype of the application that we share with the client so that it can validate the different user flows in a format very close to the final result. For this kind of prototype Figma is perfect. When it comes to more advanced prototypes that validate not only user flows but complex interactions, we use another tools such as Framer or Principle.

    Development

    Although the development phase occurs in parallel to the previous ones, only when the visual design is specified can we begin the last stage of development. Luckily, when working in parallel throughout the process, many times you just have to finish the frontend because all the backend and infrastructure have already been closed.

    In all our projects we create a test environment to which we give access to our clients so that they can test the product safely as we develop it.

    3. Launch

    We take care of the product launch like any other part of the process and this begins with a good delivery of the project.

    Delivery & Training

    For us it is essential to deliver a product that the customer can understand and control without depending on us. We do not want to create cages of knowledge where the client is forced to continue with us because they have no other alternative.

    We are just as transparent in delivery as in any other part of the process. We give access to the entire project: credentials, services, design and, of course, the complete source code. We design a training so that you can make use of the product with total independence, even being able to evolve it yourself if that is your intention.

    Launch

    We stay with you during the project launch to make sure everything goes smoothly. We only close a project when it has been properly launched into production, it is public and no problem has been detected.

    New opportunities

    We always understand product development as an iterative process that never ends. Of course, continuing to work with us depends entirely on you, you will have control at all times to be able to decide if you want to continue with us or find a new partner.

    Conclusions

    Of course, this process is not written in stone and can vary depending on the type of project. Sometimes it will be shorter and go-to-market time will be prioritized. Other times we will invest more in research and production of visual design. In the end, each project and product has its own timing and we have a flexible enough process to understand this idiosyncrasy.