In the previous blog we talked about “The Design Process”. At first, to the untrained ears the whole thing just sounds like technical jargon, a punch line about something that’s very useful. What untrained ears? You may fall in this category if you haven’t worked in industry for at least a couple of years and haven’t been involved in a full product or project cycle, or if you were not one of the very few that selected a technical major in college that actually included a course called “Design” (referring to the process, not aesthetic design), and you actually took it. But what is it really? Is it the design of how a product will look or feel aesthetically? Probably not, since we also attached the word “process” to it. Or is it then the process that one follows when creating a product? And what process is that? Well, if you did take the class or know it from professional experience, then yes some would describe it as a set of steps recommended by industry, based on knowledge derived from many years (more like decades) of product development and likely polished by academia, later on. With input from these different sources, the process itself likely went through multiple iterations and refinements, to eventually reach a mature shape that, if understood and followed thoroughly, increases the developer’s or team’s chances of creating a high quality product. What follows next is merely a synopsis of what the design process actually is, in an attempt to demystify some of the terms used in the context of product development, and maybe serve as an incentive for you (Engineer, Maker, DIY’er, Tech Entrepreneur) to dig deeper into the subject.
Requirements and Design
From a technical point of view, a design process starts by determining what the system or product needs to do, and inquiring into why. Some of the key questions for defining requirements are:
Is it relevant to the customer? If so, in what way is it needed? Does it satisfy a basic need, or is it more of an "excitement" specification?
Is it necessary?
Is it clear and concise?
Is it feasible?
Is it traceable?
Can it be tested?
See also the previous blog dedicated to the “what”. Once the requirements are defined, you will need to think about how you will implement those requirements, and once again ask yourself why that way? Are there different and or better ways of doing the same?… investigate, make full use of all the technical tools you learned empirically, from books, from instructors, professors, etc. Then what? Well, there is probably a team of people working with you, right? Most of the times, yes… the stakeholders! Are they knowledgeable? Well, if they are there working with you on a product or project, it’s likely because of their merits. So yes, you and the team need to leverage each others’ knowledge. In an interview with a high-tech Dutch company, one of the interviewers told me a phrase that I hope never to forget: one plus one is not two, but three. One of the most powerful tools that classroom lectures fail to teach is the power of alignment and communication within the team. In an ideal world, communication between teammates is easy, constant and quick. In reality though, some (maybe most) work environments see a different reality.
To tackle some of the communication barriers, one can resort to review sessions: in person, through email, or both. This essentially accounts for a content-owner who presents the information to an audience or sends it out for the audience to review and give feedback on. This is easier said than done, as it involves personal accountability and project accountability (common commitment to success). From your own competency, based on your technical knowledge, what contributions can you bring to the table? Is there something wrong, something requiring a correction? This is one way in which teams can think together and be self critics. Francis Picabia said: “the head is round so that the thinking can change direction”. But if the common thinking of the team is lazy, not proactive, not self-critic, it will likely never change direction… even when it should. Maybe it won’t even evolve at all! There is also technical management accountability: if you are the project lead (whatever fancy name is used: tech manager, lead, etc…), you should verify that a significant amount of reviewers have provided feedback to the content-owner (maybe not 100%, but at least key stakeholders), before signing off and moving forward to the next phase.
From Part-level to System-level Testing
A portable electronic product will likely be divided into an electrical component and a physical casing. Among other things, the electrical component will be characterized by a PCB design and the electrical components, the code used to program the control unit (if there is one), its physical size and dimensions, thermal response and, of course, it will depend on a manufacturing process to make it a reality. The functionality of the PCB, including for instance code logic or machine states, input-to-output response (maybe governed by a transfer function), electric connections to the peripherals (I/O), etc., must be verified first before integration with the casing takes place. In parallel, the casing that holds the electronics will itself be the result of a CAD design, material and color selection (probably in accordance with outgas and thermal specifications) and a manufacturing step. Just as with the electronics, the final properties of the casing (dimensions, special material properties, color tones, etc.) will need to be evaluated against the corresponding specifications before integrating the casing with the rest of the product. Once the independent pieces are known to satisfy their independent requirements, the integration of the components takes place resulting in an initial prototype. The integration phase can be as simple as physically mounting and attaching components together; however, in many cases, interface points are the most vulnerable ones due to a multitude of reasons that are beyond the scope of this post. From simple mechanical principles, we know that materials react (form/deform) differently to different temperatures. How about humidity, or wear over time? If not accounted for, these considerations can get in the way of an otherwise successful prototype or product.
Finally, once put together, the high level requirements are validated. This means, we are not longer talking about component level evaluations such as scoping electrical signals in the PCB, or assessing rigidity of the casing, but we evaluate the product functionality as s whole and against end-customer expectations. These expectations are in fact an interpretation made by the developers (say Engineers, Makers; though in larger companies this is commonly done by technical marketing teams) of what the end-customer really wants. Such "end-customer wants” typically drive - or simply become - the so-called high-level requirements, which should be agreed on and documented at the beginning of the project, following requirement-definition best practices.
So, there is a Process!
When talking about a process, what we are doing is defining a set of actions and organizing them in a specific manner that, from start to finish, yields repeatable results – this is a highly desirable feature in the context of product development. And so, if the process is as-good-as-advertised, why would we keep it theoretical? Is this another dangerous case of “book learning”? Ok, that’s the starting point of many of the things we know, and granted most (probably all) ABET accredited engineering programs in the United States have a capstone design class that is mandatory during a student’s senior year. But is that enough? One could argue that it should in fact be applied – not just thought – in as many team projects as possible in technical schools, colleges, etc. Unfortunately, this is typically not the case.
While startups are known for their fast pace of innovation and ability to change course rapidly, such way of operation comes at a cost: lack of structure, which usually impacts quality and robustness of mass-manufactured products.
By exposing technical students early to the design process as a collaboration- and structural-tool, they will have a smaller learning curve when joining a dynamic team and the team itself will benefit from a higher yield, sooner; technical minds can focus on implementation, without putting too much effort into fitting in and contributing within the collaborative environment. The design process becomes second nature (sooner!). An analogy can be made with sports. The faster we can get all team players, junior and senior, to understand the strategy and modus operandi of the team – aka Way-of-Work – the more chances we have of making the playoffs. Meaning: maintain or increase a technical edge over the competition, develop faster, lead the industry, increase profits, etc. And if understood and experienced sooner, through multiple iterations, it should also be easier to improve on it, develop it, trim its fat, and still evolve quickly.
Comentarios