This is the fourth episode of the podcast entitled #InquelTalks. In this episode, we talk to Jarosław Cichorski - one of the presidents of Inquel and the main designer of electronic devices in the company.
From this episode of the podcast you will learn about the biggest mistakes when designing a new product that is to be approved for sale and how the customer's approach to the requirements set for the company has changed. The conversation also opens your eyes to issues related to what to avoid when you start designing.
We invite you to listen!
For those who prefer to read rather than listen, we have prepared a transcript of the entire episode.
Welcome to Inquel Talks. If you're listening to this podcast, you're probably looking to increase your competitive advantage by using technology, electronic devices, and software. If so, you've come to the right place. In this podcast we will talk about the latest trends and technological solutions. Thanks to them, you will be able to increase the efficiency and effectiveness of your business. This podcast will also include practical tips and advice that will help you fully use the potential of technology in your company. Inquel Talks is conducted in simple language, so you don't have to be an engineer to use it. Our goal is to help you better understand how technology can help you build a competitive advantage. Well, let's get started.
[T]: Good morning, welcome to another episode of Inquel Talks. Today my guest is Jarek Cichorski. Welcome back Jarek to our meeting. We had the opportunity to talk some time ago and I hope we could discuss some interesting topics. Hello.
[J]arek Cichorski: Hello to the listeners and to you.
[T]: Today, Jarek, I would like to discuss the topic of deadly sins in device design. I would like to know whether it is at all possible for us to make some kind of classification regarding the five basic sins in design, in your opinion?
[J]: I mean, there could probably be more than five of these sins, so including them in this number, I don't know if it's a good assumption. I would also talk about the consequences of committing sins. As we know, one must then atone for it. Most often, this penance is a higher cost of the project, longer implementation time, or in extreme cases even the need to do the project again, most often with someone else.
[T]: That's what I wanted to talk about, with the aim of providing knowledge that allows you to save time, money and find the optimal solution as quickly as possible. Okay, maybe it's just that…
[J]: So you are waiting for a list of sins, seven deadly sins, five deadly sins?
[T]: I suggest we go to five, we'll see how it goes during the conversation, but let's start with this. Sins are like in life, they seem to lead us to hell, maybe some people like this place. However, I would simplify it to say that such a good, exemplary entrepreneur wants to earn money, yes, a Catholic wants to go to heaven, let's stick to this analogy in our conversation. Do you know what to do to go to heaven and avoid sins, or in other words, what do sins influence when designing? You started talking about this extra money, time, etc. Tell me, what are the sins that influence the design of electronic devices and systems?
[J]: The most important, fundamental and ongoing error throughout the entire project is the error of misunderstanding or lack of understanding of the needs of the customer for whom this product is being created. This means that ignoring these needs and not noticing them is a basic, wrong approach to starting a project at all. If we don't do this analysis honestly, we will skip it, we will have a lot of problems, yes. Because we don't know what we are designing, we don't really know who we are designing for, we don't know what price we expect for this product, what functionalities, how we want to use this product. If we don't define all this, we have sin and we have a problem.
[T]: Can you give a practical example, either from your experience or from the world around us, of devices that simply, you know, resulted from, maybe never went into production, but which, where did this sin translate into higher costs or longer project implementation time?
[J]: I think I've told you about this before, a basic sin resulting from the fact that we haven't carefully thought through all, for example all, functionalities of the product - this is the sin of project development, right? This means adding new functionalities to it during the project. If we do not examine these expectations and needs well at the very beginning and say that we are implementing them and do not add anything more to them, we end up with some new expectations or needs to be met in this project. This, of course, conflicts with the previously defined ones, therefore it requires redefining the project. Some of the work goes to waste, some has to be done again, this vision of the project begins to blur. This causes greater frustration, of course, for the design team that has done something and sees that what they did is unnecessary for the client and we have to do it all over again. It is known that at the end of this project the reward is a working device, if this reward is postponed and frustration grows, we will never get this reward, paradise, having a great product, right? This religious analogy fits this very nicely here.
[T]: Yeah, I definitely think it fits. Listen, so what to do in this case, i.e. the lack of proper understanding of users' needs to prevent this sin?
[J]: Well, don't sin.
[T]: Sure, I understand that on a general level, but on a detailed level, if you could give me some tips on what to do to avoid sinning and thus, you know what you said, save yourself time, nerves and money?
[J]: We need to research and define well, determine the customer's needs, define well the product we want to create. So that we have a good starting point for this project. We need to know all the parameters we want to implement and all usage patterns, because we need to know the customer and the price. Everything that should be included in a design brief. We've already talked about this before, so I don't really want to repeat it now, but I think I would summarize this sin well and briefly, because we are talking about sins, and we need to approach it in such a conscious way to well define what we want to create and close. our ideas, dreams, expectations, close it with a design brief. Which relevant people interested and involved in the implementation of the project, after receiving, reading, picking up and reading such a brief, will know exactly what we are working on.
[T]: Ok, so I'll try to sum it up. So the remedy for this sin is, in fact, to spend enough time to understand the problems and needs of users, and then devote enough time to translate it into a design brief.
[J]: Yes, I agree with you, but I also wouldn't want potential creators, new solutions, to be frightened by the fact that they have to come to us with it, because we can also help them with it, right? This means we can help them define these needs and notice any gaps in this project vision that require further clarification. And create this design brief together. Perhaps somewhere along the way, catching up on some workshops that help us realize some things that we are not aware of, right?
[T]: Okay, the first sin, you could say we've tapped out, he's on the mat, let's move on to the second opponent to defeat. What second sin would you point to when it comes to design?
[J]: I don't know if I will go chronologically when it comes to the implementation of the project, but I think that at some stage either a proof of concept is created, or perhaps even a final version of the project and…
[T]: Sorry, Jarek, I'll come in here and I would just like to ask you to define for the listeners what a proof of concept is. For those who may not be familiar with this terminology.
[J]: We are talking about a device in a form that allows us, or a project brought to a form that allows us to check its basic functionalities or basic features that may be important to us. There may be something different in each project, it may be the appearance, it may be ease of use, it may be some technical parameters titled, I don't know, volume, brightness, various things. The idea is that, before we take the project to the end and finally decide that it was probably the wrong path and it needs to be corrected, we could possibly make decisions at a sufficiently early stage regarding the key, so to speak, technical or technological solutions. , made.
[T]: So you could say that it's about not paying attention to trinkets at this stage of checking functionality. Proof of concept is a concept that allows you to check whether the functionalities solve a given user problem, right?
[J]: Either a technical construction or, for example, adopted, if we are dealing with some research that we had to do, with a study of a technological solution, and when we start it, we do not know whether it will work. Yes it can be. After all, we never know everything in advance, some things must be empirically verified. So if we want to test it, we need to get to at least this testing phase, so this proof of concept is a very broad concept, because it can literally refer to any board assembled, and I don't want to say a spider assembled on a table. Because spiders, as we know, end badly. But it doesn't have to be a device enclosed in some housing and in a finished form, sometimes it can be something that will allow us to find out whether this is the right direction at all.
[T]: Sure, okay, let's move on to the second sin, testing. Thanks for explaining the proof of concept.
[J]: If we have this project, let's say we already have this project finished, let's skip the proof of concept for now, let's say we have this project finished, we should test it well. Before we release it to the market. Because we must remember that you can never make a good first impression twice, so if we release a product to the market and it has some very significant basic defects, this bad opinion will usually follow this product. And of course it will not be as attractive to customers, it will sell poorly. So we need to test this project well and test it in different aspects. The fact that we assumed that it would be easy to use does not necessarily mean that the interface we invented or used for it will make it easy to use. So when it comes to devices, there are certainly functional tests, yes, that check the operation, check whether the interface is appropriate. These may include strength and immunity tests, i.e. resistance to electromagnetic interference, but also tests to ensure that the device does not emit too much interference in order to pass the tests - these are very important things. They may seem insignificant at first, but they may result in the product not being approved on the market, or worse still, having to be withdrawn from the market because it does not meet certain standards. So, testing whether the product we design meets the standards is very important. Depending on the use of the product, we must check whether it will function well under the intended operating conditions, that is, whether it will function well when the temperature is too low or too high, whether it will survive a fall to the ground from a certain height, or any disturbing power outages. There are a lot of different things here. And I will say that I once witnessed a test of a device, not our design, but a test of a device that gave me a lot to think about. I won't say what the device was or who the manufacturer was, but in the research unit where such research was carried out, interference was emitted through the power supply network and reached the device. It was an ordinary kitchen appliance that contained a motor, and it turned out that with a certain design of these disturbances, which are standardized, this motor stopped.
[T]: My dear, you use very complicated topics and very complicated words. In a sense, normalization will be obvious for some people, they probably spread it on their bread. However, I want to use the simplest possible language here. So what was wrong with this device?
[J]: It means that the disturbance that reached this engine caused it to stop. While we would think that the engine should always be turning.
[T]: Okay. So I would summarize this sin, the lack of testing, that it is worth devoting time and resources to simply testing. As if the threats are such that the product may not be admitted to trading or, worse still, it will be put on the market but will be withdrawn from the market and this is a very expensive operation, right?
[J]: These are losses, it's not even an expensive operation anymore, it's just a disaster, image-wise and costly. So we don't want to commit such sins.
[T]: I don't think anyone would want to commit such sins. Okay, so we have the second sin - insufficient testing and checking of the designed product. What do you see as the third sin?
[J]: Well, another sin that would suit me here is, for example, not taking into account the limitations imposed on us by technology or real costs. If we design a device without taking into account the fact that different technical or technological solutions have different prices and this results in the cost of this product on the market, the final effect is that we have an expensive device that may be technologically oversized, but no one will buy it because of this. No one will appreciate that there is some very sophisticated technology hidden somewhere inside and they are not aware of it. So it is very important to have this in mind, already at the product design stage, to think about what the production cost will be, what technologies we will use to produce various elements, and its functionality. But also, for example, an interface or a housing. All this has a very important impact. Because, as a first example, if we have an industrial designer, and it is worth hiring one with experience, it is worth involving him in the project, because he will allow us to design a nice device, he has an impact on functionality, he has an understanding of ergonomics, but sometimes he has no ideas about, so to speak, technological limitations regarding the production of certain elements. So here it is worth supporting it with this knowledge, so that you can react at the right moment, so that at the end it does not turn out that we have a beautifully designed device that looks beautiful in 3D visualizations, but unfortunately it will not be possible to produce it, because is very difficult to do. So you have to be able to imagine that this device will have to be manufactured, right? You have to remember very strongly at this design stage that during the creation of this project, the implementation of the project, there is cooperation, continuous cooperation between the client, between the product runner, i.e. the product owner, who is a transmission belt between the client and the design team. But key cooperators, or often experts, who take part in this project and are needed are also very important. It may be, for example, an injection mold designer, the mentioned industrial design designer, who is such a very important person, but it may also be an expert in the so-called Uix/UII, i.e. user experience and user interface. This does not necessarily apply to mobile applications, although it is mainly known for this area, but remember that everything that has a display and keys and needs to be operated also requires some experience, i.e. knowledge, improving the user's experience in dealing with this product. And, of course, experts who are somewhere in the area for which this product is created, if we are creating a toy, perhaps a child psychologist, if we are creating some equipment for the agricultural industry, maybe it would be worth working with a man who drove a combine harvester. after the orchard, talk, right? Of course…
[T]: Jarek, sorry to interrupt you.
[J]: I can go on for a long time, you have to interrupt me.
[T]: I know, I know, I know, but I would also like to summarize each point, each sin, in a certain way. So you can… Tell me if I understand correctly, or confirm, or correct me that…
[J]: I don't confirm, I don't deny.
[T]: That if technical or cost constraints are not taken into account when designing, and again, the project may be more expensive, more complicated, longer…
[J]: It may not be implemented at all.
[T]: And now, as if there was a remedy…
[J]: Simplifying, this is the direction we need to go.
[T]: Okay, because I drew something different from what… A different conclusion from what you said, so that's why I say, deny or correct my thinking. That it is very important that people working together to create a solution communicate with each other and tell each other about these limitations…
[J]: Yes, this is important.
[T]: They talked about certain directions, but above all, to communicate and cooperate with each other to solve users' problems in a real way, and to do it keeping in mind some cost and technological constraints, right?
[J]: Yes, as I said, one of the important principles, very important principles, is simplification, but of course not at the expense of safety. But we also need to look at the product we are designing from a perspective perspective. This means that we see a development horizon for this product, in which direction we want to develop it, whether we will design any additional devices, add-ons that will extend it, and perhaps we will update its software. This must very often be taken into account at the first stage of designing the device; if we do not do so, certain future activities may be impossible.
[T]: Ok, I understand. Listen, I'd like to move on to… I'm sorry to interrupt you, but I'd like to keep us under some time constraints as well. Can we move on to the fourth sin? How would you describe the fourth sin?
[J]: Yes, we are trying to identify them here, but of course they are very often and very closely related to each other. I said, I said, that simplification is very important, but not at the expense of security, and this next sin is omitting these aspects of security. And possibly, I mean possibly, and also aspects related to environmental protection. And if, if we do not take this into account, this device, it is obvious, will either pose a threat to the user to varying degrees, including a threat to life, which we would obviously like to avoid, or to health. We may also threaten his health, emotional balance and mental health if he simply becomes constantly irritated by this device and is very dissatisfied with it. So we would like to avoid that too. And of course, nowadays, fortunately, environmental protection has reached the awareness of consumers, but also of device creators. Consumers are demanding it, and that's a good thing. We also have to remember this, even though sometimes it raises some conflicts of interest, right? Because, for example, we would like to produce something cheaper, but then it may affect safety, so of course we avoid it. We would also like to, depending on the device we are designing, it may turn out that even though we use replaceable batteries, they will ultimately pose less of a threat to the environment, right? Or, for example, there may be a situation where, due to who will use the device, we will not use lithium-ion batteries inside. We remember what happened to some cell phones while charging, right? So there are a lot of elements that influence this.
[T]: Ok, in the previous sins we talked mainly about the time and monetary effects, and here there is also the moral aspect, in this sense people's safety, it is difficult to measure it in terms of values in zlotys, dollars or euros. And our environment is…
[J]: It depends, it depends, right? (laughter) Because if, as a result, the company is sued for releasing a dangerous product and someone gets hurt, then it may also have a significant financial impact, right? It should be shown that every effort has been made to make it happen, and besides, I think that everyone would like to sleep peacefully that it is their device, it is…
[T]: What I'm talking about, Jarek, is that in addition to finances and time, there is also a moral aspect, as an additional, big effect. Ok super. This is very interesting, and this sin of underestimation often happens in, let's call it in the initial phases of device design, that designers ignore the issue of human or environmental safety? Has this happened to you often in your, your experience?
[J]: That is… Clients who come to us usually, even if they have not discussed this topic and we have raised it, of course, most often immediately emphasize that this is for them, I mean, it is important for them, yes ? Maybe these environmental issues are not always really at the forefront of consciousness, but if we talk about the fact that we can boast that our device is, for example, easily recyclable or does not contain any ingredients that are irritating or can then pollute the environment , then of course it is important. Well, it's partially forced by regulations, right? For example, for the RoHS II standard to be met for these devices, also…
[T]: Could you explain these, maybe not all, legal aspects, but some specific ones? You mentioned the RoHS II standard, are you able to briefly describe what it obliges anyone to do?
[J]: In short, it obliges that devices, i.e. products, placed on the market do not contain harmful substances. And the values of these substances are simply defined, yes, the point is that every element used for this construction and subsequent production should meet these standards. So that the entire device meets these, these, these, these requirements, so this is of course very important. Although not only the composition of the device itself may pose a threat to the environment, because we can imagine such a combo and the combination of various things, let's imagine that we have a device that monitors the detection of a leak in a double-shell fuel tank, right? So we have a tank with fuel somewhere in it or any other substance that may pose a threat to the environment. And such tanks must consist of two jackets in order for the leak to be detected…
[T]: Sorry, I'm going to grab my words.
[T]: A coat for the average person is what we put on our shoulders, you know, in spring and autumn to protect us from rain, wind, etc.
J: Well, we can imagine it this way: a bottle is a single-shell tank, but, for example, a thermos is a double-shell tank, i.e. it consists of two layers separated by some kind of, usually air void. Now the idea is that if this first inner jacket starts leaking, the liquid will spill out and it's between the layers, it doesn't escape into the environment. But if we don't notice it, it may come out of this outer layer after three years. So it's about us noticing it. If we put a sensor that detects such information, it goes back to, you know, what I started with, so if we put a sensor there that detects such a leak, and for some reason this sensor hangs up and stops working properly, he won't even notice it, then Due to the design error of the device, we pose a threat to the environment. This sensor was not made of elements that pose a threat to this environment, but its function influences the fact that it may pose a threat to the environment. So these topics are very complex and interconnected, depending on the application.
[T]: Okay. We close sin four. We know that some originators sometimes ignore issues of human safety or the environment. Here, in addition to financial and time effects, they also have a moral aspect. It's very interesting. Listen, I'd like to move on to the 5th final sin to close out our pentalogue, as you put it. What would you give to the 5th place of the pentalogue according to Jarek?
[J]: I have already mentioned this sin a bit, but I think that it… It would be worth mentioning it here. He's somehow connected to this budding project, right? I mean, there we talked about budding and adding different functionalities. Here I would like to talk about the sin of constant product improvement. We can even get this project to the point where it is finished. Then we decide, and it would be nice, that before it hits the market, we would add it there. Let's say we don't change anything in its design or casing, but let's add another function so that it does something else. And we start adding it. We are improving it. During this time, time flies and the money in the account disappears. It would be possible to make money on this product, collect opinions from the market, find out whether this product has been well received and whether there are any gaps in it that would be worth supplementing. And the effect of this action is that we create a product that we think will be better for the market and for the customer. In fact, instead of researching it, find out from customers who use it what functions are important to them and introduce them to this product. This process is a bit more complex, because we have to remember that if we want to add some functionality, we have to add it, I'll put it in quotation marks. Or program it for this device, if we are only talking about some changes, say in the device's software, which add additional functions to it. So if we collect such a list of expected changes from potential, actual customers of this product. We can create a special tool to collect it. It's worth doing. And we will add to this list… Should we add such parameters to this list? This means how much it will cost to add this function and we will find out from the client or the person who sponsors this product development how important it is for him to introduce this function. He may have his own vision for it because he needs it in a broader context of developing a service, for example. Then we will be able to select very well those elements that are most important for this product to develop from a market and marketing point of view. If we do not do this, we are committing a sin, I really like this name, besserwisserstwa, it means that we know better what is better for this product, and this is most often not the case. This invisible hand of the market verifies well.
[T]: What comes to mind is that very often creators think that the product was perfect, but unfortunately the market and users did not notice this greatness. So I understand that the solution here is to approach it iteratively, i.e. introduce the device to the market, test it in practice in practice and, for example, develop new versions. That this is a better approach, I understand, right? In this sense, more profitable from the business side.
[T]: Yes, definitely. This flexible agile approach is a key word that has become very popular lately. And maybe I would compare it with an analogy and try to end it. Let's compare an undertaking like building a bridge, right? That is, we are building a bridge, so we have to design it well, there is no room for experimenting and thinking. We know that there must be a footbridge for bicycles, a footbridge for the first cyclists, we know how many lanes, what load capacity, what span, goodbye, we design and build accordingly. And then we won't do anything with this bridge, we won't add another traffic lane or widen the bicycle bridge, right? As a rule, because of course there are exceptions. Well, this is a good design practice, resulting from very old engineering experience. And transferred, transferred to the needs of such a new market, which is so technologically developed and moves forward so quickly. Well, this approach means that when we release this wonderfully designed product on the market, it is simply so technologically outdated that no one will buy it. It has too few lanes, too little load capacity, the footbridge is too narrow and there is nothing we can do about it. Well, here we have such freedom that with this software we can, I will say it again in quotation marks, widen this bicycle bridge, increase the traffic lane, perhaps by one or two more, increase this number and add additional functionalities to this bridge designed at the beginning. So, it is worth doing it, as I said, based on real, market experience, not our imagination.
[T]: Great, Jarek, thank you very much for the conversation and for helping, or rather not helping, for creating your pentalogue of deadly sins in design.
[J]: Now I don't know if I will have to confess this.
[T]: I hope not, I hope that, first of all, this material will serve as a good educational contribution to actually approach the design of devices better and actually save time and money. And also some moral dilemmas in the future. And I think we will all benefit from this. I thank you very much for the interview. Thank you for listening, have a nice day and see you soon.
[J]: I also thank you very much.
