Skip to content

Phase 5Design & development

Now it’s time to focus on defining basic mechanics, PCBs, and form factors that allow us to use the product in a limited environment. Does our rocket have a chance to fly? Do all components work as we wanted? Does everything fit inside the housing?

If this is the first blog post of the series you've come across, be sure to take a look at the previous ones:


Photo by Donald Giannatti on Unsplash


After this phase, we should have developed the two most important materials that will allow us to decide whether to continue development and move on: 

  • The risk assessment will show us if there are any big threats and whether we can deal with them.
  • The balance sheet and roadmap determine whether the production is financially viable and how we can estimate production, certification, and sales over time.

In the previous article, I summarized what we have after the first phases


In the case of design and development, the processes happen simultaneously and are very similar to each other. Even if they start separately, they have to connect at the end.


If we are dealing with a physical product, we need the cheapest version of the prototype, preferably 1:1, which will show us how this product will look in space and how we can use it. Such solutions can be made of cardboard, foam, everything that will allow you to see the idea in reality cheaply and quickly. In the case of applications, it is much more comfortable; we need a preferably clickable prototype.

After selecting the best version of the prototype and corrections, we have dimensioned and CMF (colors, materials, and finishes), which can we refine using the appropriate software. This will be the basis for the production of physical models. Finally, we get a high-quality mockup of the product. It should contain all the elements that will be included on the device.

If we are also working on/or on the application, it is also the moment to reflect high-fidelity mockups and check the user experience.


At this point, we want to collect as much feedback as possible on both design (wireframes, looks-like prototype) and user experience with the product.

What I would like to emphasize is that testing should be well planned:

  • it is worth doing a few tests to catch errors in the planned testing process itself, before we do them on a larger scale,
  • we invite clients to test - if someone is not the target group, we can take into account completely unnecessary comments,
  • plan your test script and don't get left out of it too often,
  • ideally, you let users run on your prototype themselves without much explanation, which is exactly how they could use it,
  • our observations of customer behavior are much more important than their words - in tests, they will often want to explain too much and look for the causes of problems,
  • prioritize comments and notes - which require more profound thought and change, which is only a nice-to-have.

After implementing changes, it is worth planning another feedback to see whether the improvements we have made really solve users' problems.


Besides having a prototype that looks and works, we also need to rethink how the entire service related to this product will perform. Of course, the components will differ depending on whether it is a physical product or an application.

  • Where will the device or application be sold? Where will customers come into contact with it?
  • How do we want to convince them to buy? How does our proposal stand out from the rest?
  • What will the packaging and the entire unboxing process be like?
  • How will we plan the first use of a device or application?
  • How will the installation and onboarding work?
  • How do we want to involve the user in the regular use of the device and/or application?
  • How will we provide support to clients in the most common problems? How do we deal with the less typical challenges?


At this stage, after Phase 4. Feasibility study, we have most of the specifications and costs. It is worth taking a second look at all hardware or software elements we must consider. This list should include:

  • Software requirements, languages, connectivity methods, firmware etc.
  • All hardware components, requirements, bill of materials (BOM), printed circuit board (PCB) specification, strength, appropriate temperatures etc.
  • Packaging specification.
  • Legal requirements, necessary certificates, depending on the country in which we want to sell the product.

I will repeat myself once more - these requirements may change when testing various solutions, but it is worth starting somewhere.


As in the design process, we tried to build a visual prototype as cheaply and as quickly as possible. Now we are making it from the functional side to check if everything works as planned.

We check every element, PCB operation, and basic functionalities. You can start with simple 3D printing going to increasingly complex forms and advancement. We should pay particular attention to the PCB, which is the heart of the device. Usually, it requires creating several versions before we achieve a satisfactory result.

Usually, it requires creating several versions before we achieve a satisfactory result.


When the design, materials and form of the device have been refined, it's time to assemble them with the engineering part. At this stage, we finally verify whether everything works as expected. We check weak points and verify costs.

After completing the electrical part and on the implemented firmware, we enter the work with software engineers. More about the beginning of mobile app development we wrote here

At this stage, we combine the looks-like prototype and works-like prototype and check their functioning very carefully. Most often, we need a few more models before we move on to the next stage.


This stage aims to verify all the functionality and look of the device so that it can lead to the next phase, which is for EVT, DVT, PVT hardware, i.e., manufacturing.

In the case of applications, we go straight to the MVP phase.

If you are developing a project in which you need support in the design & development phase, see what we can do for you.

By Bartek Hugo Trzciński

Head of Technology by day and software engineer by night. Recently solving more problems in business and mangement than in code - hard to tell which one is more fun. Local dev groups activist. Automotive enthusiast. Boosted Board shredding champ. The best companion to dance and to give you a ride.