Developing a custom Android device starts with a concept. From that concept a journey begins that has no end. Along that journey the concept turns into a plan. That plan turns into a history as progress happens. Documentation of the plan, changes to the plan, and lessons learned as the plan unfolds creates the foundation of a successful project. Engineering optimizations, design changes, and new technology are some of the factors that cause a product to evolve over time.
This article goes over two key documents, a Spec Sheet/BOM and a testing feedback list, that every product development team should use. Luckily these documents are simple to create and easy to maintain. The key is knowing what information goes in these documents.
Spec Sheet / BOM
In the case of an Android device the Spec Sheet should include, at the very least, the details of key components of the product. These include the CPU, memory, screen (size and resolution), camera(s), wireless specs (Wi-Fi, Bluetooth, mobile bands, NFC, and others that may be required), battery, touch panel, and any special electronics or firmware requirements. A basic Spec Sheet includes the generic specs of each component. For example ‘6GB DDR’. A more mature Spec Sheet will also include the specific part number. For example ‘K4EBE304ED-EGCG’. At this point the Spec Sheet turns into a materials list, also known as a BOM (Bill of Materials).
When a new custom Android development project initially kicks off, defining the broad specs of the product, like in the ‘basic’ example above, is the first step from concept to plan. The broad specs of the hardware, what we call ‘product architecture’, come from understanding the performance needs of the product’s use case. This topic could go into more detail, but that’s not necessary for this article.
Once the basic architecture of the product is roughly defined there are two ways forward. One option is to evaluate individual components in other products. For example if LCD screen color tone really matters to a product then the customer may want to evaluate samples of different screens to find the best match. If there’s not one specific element of the product that has a special requirement then Hatch would select components based on quality, sourcing reliability, and cost (in that order) to build an initial working prototype. Either of these approaches are acceptable. Choosing the right approach just depends on the circumstances surrounding the specific project.
As the components are decided on, the Spec Sheet matures into the BOM. The BOM includes defining the final specs and specific part numbers of all the components. For example, initial specs may call for a 13 mp camera, but it turns out that the product only needs a 8 mp camera. To avoid paying for extraneous technology the specs will change to 8 mp. The opposite happens if the initial specs are too low.
Going through product development from concept to prototype to trial production and finally mass production generally causes changes to specs. The BOM evolves during this process. Once final parts are decided upon, the BOM freezes. At the point of mass production the components can’t change as most (read: all) products get a certification like FCC, CE, etc. Mass production products must match the certified samples. After multiple mass productions (or maybe just one), a customer may want to release a new version of the product. The BOM gets updated again. A ‘live’ Spec Sheet and BOM that show the current device details are key documents in managing the ongoing evolution of a product.
Testing Feedback List
Just like with the Spec Sheet, early iterations of a new product will have untold amounts of problems. Usually these are small issues that arise from using new hardware or custom Android firmware that, once identified, can be fixed. As the issues come up they must get recorded in a Testing Feedback List. Over time this list gets longer as new issues come to light.
Recording feedback becomes useful because a lot of the issues are unique to the specific custom Android product. Hatch uses a combination of standard quality control protocols and device specific quality control protocols to our custom Android products. Feedback recorded in the Testing Feedback List becomes the basis for a bespoke quality control protocol to ensure proper functionality of the unique device.
At the beginning of a new custom Android project the customer will include a list of custom firmware requirements in the Spec Sheet. These requirements serve as the starting point for the product specific quality control protocol. Additional observations recorded in the Testing Feedback List build on the initial custom requirements. Each custom Android product has its own idiosyncrasies. Ideally an Android product supplier knows the normal things to check for with a normal Android product. This makes the bespoke quality control protocol a very powerful tool in testing for and ensuring product quality.
Summary
Both the Spec Sheet/BOM and Testing Feedback List are simple, non-technical documents that your manufacturing partner should maintain in order to provide consistent and high quality products.
