Originally the plan for this month was to do a follow up article regarding quality control tests for functional defects of custom Android tablets.  Then I got caught up dealing with a little setback on a current project and had to refocus my attention.

Here’s the reality of custom Android hardware development, or any custom product development for that matter.  Development is a process of resolving questions and problems.  Even the best companies in the world go through multiple rounds of ideation, prototyping, and revisions.  There’s no shame in saying problems arise, however it would be a shame if those problems don’t become lessons to grow from.

The below text is based on an email between Hatch and a client, with some modifications to better suit the blog.  This is a great project that we enjoy working on.  It’s a complete custom product, from case to electronics, even the terms of the project are unique.  The issue revolves around an oversight in requirements.  It happens.  Not the end of the world and it shouldn’t have a big impact on this project as we were running ahead of schedule.  Read on for insight into a problem and how we can learn from it.

Dear (Client),

When dealing with product development, decisions should be based on research as much as possible. Taking time to research how to do something right is almost always a good investment compared to the time required to fix a mistake. In some instances, when there are too many variables, it takes more time to form a theoretical opinion than to move forward with a best guess.  In that case choosing the trial and error approach is still a calculated decision.  By identifying possible risks, everyone will pay closer attention to the variables at the earlier stages.  In this case, calculating the parameters of case design, since we need to work within the confines of the charging tray, the inputs are straightforward.  There’s not much theory involved.  It would take 1-2 hours to have sufficiently researched the original decision.  Now we’re going to spend 3 weeks redoing the case design, mechanical engineering, and PCB to fit the new case design.

That’s not to say we can always prevent changes.  Sometimes there are new ideas or innocent oversights.  But to minimize these kinds of situations, it’s safest to make decisions based on checking and testing.  Whenever any of us have questions, let’s share them with each other.  That way we can work together to figure out the best approach.

Much of the considerations that go into making a product decision are based around the use case of the product.  I do my best to thoroughly understand this from the beginning of an engagement, even before any deposit is paid, as a means to make applicable product suggestions.  In this case, I wasn’t aware that the end users put the tablets into the charging tray themselves.  I assumed it was done by the institution’s staff who know exactly how to do it and have a vested interest in not breaking the charging ports.  As I gain more detailed insight into the usage environment, I’ll do a better job identifying things that look risky at an earlier stage.

On that note, we noticed that the charging plug in the tray is an independent component.  I’m wondering if you’d be open to redoing that charging plug to make it shorter.  We can make a new one.  At the same time we can change it to USB-C if you want.  That would avoid having to make the tablet longer, which looks strange and increases costs of both shipping and the actual case.  I’m trying to find a solution that works today, taking into account the present limitations, while also focusing on a better result for the future.  Let’s try to avoid having relics of the past limit the potential of the future.

Efficient hardware development is a process based on many general principles combined with product specific experience.  All custom projects have unique nuances that impact the development choices.  The issue we face today highlights two valuable tools we can use moving forward:

1. Check design files and test whenever possible before making a design decision that involves incumbent parts.
2. We should have more general discussions about the environment where the product is used.  Any images or videos would help as well.

Luckily we found this issue at the early stages of the project and we were running a bit ahead of schedule.  By learning from the experiences we’ll keep getting better for this project and whatever comes next.

Thanks,
Ben