The circuit design public
The condition that defines and knits the circuit design public is the singular passion to do circuit design. Yet, within this larger emotion features an array of smaller issues that add depth and character to this public. Jack, a member of this public, is frustrated at the various things that are a hindrance to doing what he is passionate about. He does not like the organizational dynamics that force him to do something that he is not interested in doing. He does not appreciate why he has to spend majority of time looking at the data that is thrown at him by these “new tools”. Also, he is not happy that the art of doing circuit design is transforming from being an intuitive and challenging process to becoming a meandering and cumbersome process. He feels that yet another fast simulator is not what he needs but an efficient way to organize and get his day-to-day work done smoother so that he can spend time on things that are important to him.
The semiconductor industry public
The condition that defines and knits this public is the belief that technological advances are needed to create better user experiences. The industry always is looking for ways to advance the current state-of-art by designing chip solutions that are innovative, feature rich and widely applicable. With an increasing demand from its consumers to deliver feature rich products fast, the semiconductor industry has always focused on time to market and product features. The complexity of a chip increases with the features and the time to market pressures significantly impact the business decisions. This public, hence, is concerned mainly about the issues of speed of achieving the time to market goals. The EDA tool vendors have to sell “speed” to keep this public interested.
Designing for any public
To understand how designing for a public works, we need to take a look at the concept of public in detail. Also, it is prudent to look at interdisciplinary areas of psychology and human factors and understand how design is perceived.
I think that the empathy associated while designing can drop significantly with increasing cloud or size of the public for which the designs are created. We invariably find that smaller publics are connected by traits that are core to their existence or daily lives. The central characteristics that constitute this public are very well defined amongst the members of the public itself. For instance, let us take a small group of individuals who share a passion for a brand like Apple. It is perfectly plausible to attempt understanding the value system and problems faced by this public. On the contrary, a huge public like “residents of America” will present more challenges in understanding the value systems and problems.
There is a great deal of research being done on “Designing with” vs. “Designing for”, which is also known as co-creation. This is the process in which a designer engages the end user to participate in designing a solution. This is a very interesting topic that has been successful in tackling several social problems [2,3]. In , Le Dantec talks about democratizing design process at the margins of the different publics involved. This work, though not directly related to the semiconductor/EDA industry, offers a lot of insights that could be applicable for creating better products. Here, Le Dantec urges a designer to design at the common boundaries of both publics. He maintains that designs should be democratized and for doing that, it is imperative that we follow the “design with” method and not the “design for”. In a simplest explanation, designing for someone is akin to sympathizing while designing with someone is empathizing. Quoting Emily Pilloton , “To take it one step further, you can’t design effective solutions for people unless you make your clients or end users part of the design process —co-creating systems that will work for and be owned by them. To do either of these things, you simply have to be there, present in a place, and part of the community.” Again, this is in the context of solving a social problem. We can take a step back and apply it in the context of the semiconductor industry. What Emily Pilloton talks about is the process of making the client part of the design process. Though, there is no concept of a client owning the solutions in the semiconductor industry, getting them involved in the tool design process will enable the EDA companies to design a product “that works for them”.
A marketing trainer once suggested that I 'spend a day in the life of my customer'. I did exactly that, and after one day on a film-set I came away with what became a $2M product series. Not so easy to repeat, of course, but the raw input you get from watching people struggle with inadequate tools while actually they are trying get quite another job done - powerful stuff.
Hi @sharps_eng- Your analogy is quite spot on and so is your example of user-interface.
Normally, when a company is at a launch stage, the first few customers inevitably shape the product. Then, like you said, the customer base grows and companies start extrapolating the customer needs instead of actually repeating their initial customer identification process. Part of the reason is that, it is quite hard and at times impossible to talk to every customer group who will use the product (windows is a good example). However, the problems comes when the extrapolation is based on market observations and trends and partially reliable usage data. When their calculated product guess is accurate, then they might drive new customer behavior and the products drive the need of the customers and not the other way round. However, in the semi-conductor (and EDA) industry, this rarely happens. The market research information is incomplete because it does not really capture some hard to quantify, but super-important data like usage patterns in an organization, process flow, customer's mental models about the product,etc. Hence the product that is designed out of incomplete (or worse, inaccurate) data. This creates a chasm between what the customers think the product should do vs. what does it actually does. This gap widens for ever.
Hi @Saranyan: Thanks for the ack :-)
'only customer integrated product development practices can fill in the missing holes'; would you translate please?
Are you talking about the ecology that forms around flawed products like W*ndows?
My analogy is the village blacksmith, who would fettle a tool for a local craftsman, until it was 'just right' for him. This tool would be copied for a tool catalog and mass-produced, sold to all sorts of people worldwide who would be disapointed to find that the tool they received didn't fit, didn't work in any way they could relate to. Until you have made and improved a hand-tool with your own hands, you can't understand what efficiency gains can be made by such personalisation. Actually, on reflection, user-interface customisation comes a close second, I must say...
Hi @sharps_eng - Yeah, you have touched an important aspect of workflow and time. That is why, I think that it is important to change our product design practices. One thing I always think about is that application engineers can move from being support guys to working with engineers/companies as consulting employees. That way they get to "participate" in core engineering work and understand how things are done and derive insights about actual needs. If a new entrepreneur is venturing out in this (or any) area, then they can identify a customer and work closely with them to identify a product need before even designing a product.
While it is true that great products are result of visionary entrepreneurs, only customer integrated product development practices can fill in the missing holes after a product has been launched. The product ecology will create new needs that will eventually turn into gaping holes if we don't do that.
Your last point about "potential rivals" is an interesting one. That brings me to another question - how much should we collaborate before we get competitive? We need to value collaborative advantages over competitive advantages too. Let me brew over this thought for a bit and I will get back to you.
Thanks for chipping in! :)
@Saranyan - Hi, nice to read some deep thoughts here. I have a parallel mission; how to get any 'user group' to take responsibility for the design of their tools. Who else can possibly know what their tools should be like? But believe me, corralling a group of busy folk (in any sector) and getting them to take time out to even think about their ideal tools is tough, let alone getting them to fund development and actually buy the end result. But that is the only way forward, otherwise astute entrepreneurs from other areas will, almost as predators, descend on this visualisation vacuum and fill it with 'tools' that can at best be only a guess and at worst, not so effective as the tools they replace.
I think one key is that 'busy' factor; plus the fact that other members of the same group are potential rivals. That may explain why the medical world often manages to make custom tools 'by committee' but engineers don't even get to first base. There may be another psychological element; a known characteristic of those with borderline ADHD is to labour on with indequate facilities, beyond the point of common-sense. Their ability to hyper-focus can also make some great engineers...
Hi @IqbalSingh, Thanks for sharing your thoughts. I agree that the problem is multidimensional. But, I think an effort should be made to integrate with the customers who are sub-publics. Also, the roles of Application Engineers should change from pure support to needs identification and research.
This is an interesting article that shows how customer emphasis could lead to better products that are tuned to specific needs of a "sub-public". Here, it may be noted that the requirements of a "sub-public" may be changing with time, due to complex interplay of overall industry trends, or even due to lack of clarity at the outset. Often, it may not be possible to freeze the complete requirements of a "sub-public" at the initial stage of a product development cycle. Several iterations of the product may be needed over time to fine tune the final set of requirements. So, the problem is really multidimensional, with the requirements changing across different "sub-publics" and also changing over time in a "sub-public".
Visit us at uspurtek.com
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.