Design Review Boredom: Is There an Alternative?

One of the jobs of working professionals in the design community is to attend design reviews. I imagine that many of us have attended design reviews in the past or will in the future. I am sure that those engineers who have been working in the industry for many years have attended so many design reviews they've lost count.

For those of us that have attended many design reviews, I would suggest in some or possibly many of the reviews attended there is a tendency to lose interest after the first 30 minutes. In addition, I would like to suggest that you would be able to testify to the endless slides of data presented in these reviews, much of which may seem relevant to the presenter but in reality are not that important.

If you are fortunate enough to have clear and concise design review meetings, I commend the management and technical leads that have instilled practices that produce crisp outcomes. However, if you are like the rest of the community of analog engineers, then you must wonder if there is a better way? Why does the presenter have a tendency to fill his or her presentations with reams of data that are difficult to see, or plots that are difficult to read? I would like to suggest that this tendency arises in part because the engineer believes in the necessity to present data showing how the simulations and data collection align over variations. Is there a better way to have design reviews? I believe there is and would like to suggest options.

Before I suggest my proposal for an improved design review methodology, I would like to set a precedent for conducting design reviews. First, the attendees in the design review must remember that its purpose is more than a check-off procedure, but to ensure that the product being designed meets the criteria deemed necessary by the goals established. This means that the engineer must feel comfortable exposing his or her weaknesses in the design without the threat of management blasting the engineer in the meeting. (If needed, that can be handled outside the meeting on a one-on-one basis.) Second, the design review attendees list should include a key technical guru to review the data presented. It is important for the design review to be crisp and to the point.

Now, to present my argument for a more concise presentation in the design review, I would like to introduce the idea of a one-pager. Obviously, it would not be possible to put all of the relevant data on one page for a design review, but the concept is important to strive to meet. The items presented as part of the concept of a one-pager should include a concise list of key topics relevant to the design.

For an effective and engaging design review, the one-pager idea should have a concise set of defined outcomes presented in very few slides or pages.

The one-pager should present:

  • Design goal
  • Architecture (also include difference from prior architecture)
  • Pro/cons of design. Highlight weaknesses in design and how you overcame the design weakness
  • Specification targets (including power and area targets)
  • Design simulation summary in the form of a compliance matrix to design targets
  • Special considerations for design (special power routing needs, etc.)
  • Additional supporting material in backup as needed

In addition, the design review process outlined should also include the option for less detailed review during a feasibility study or initial stages of the design process. For instance, during an architectural review, a subset of the information may include just the architecture pros/cons and specification targets.

If design reviews are carried out in the manner suggested, the design community can engage in shorter discussions that are synergistic and can accomplish the same goal early in the process. Engaging the design community and management in changing the culture is not easy, but the benefits outweigh the pain associated with expense and time to implement costly design changes because critical design weaknesses were missed during the design review.

Let me know what you think. What methods have you tried to streamline design reviews?

Brandt Braswell is a distinguished member of the technical staff at Freescale.

38 comments on “Design Review Boredom: Is There an Alternative?

  1. amrutah
    February 25, 2014

    Brandt: I agree that the design review has to be precise and to the point discussion otherwise it is just figures for some of them in the conference room.

      On the contrary,  there are people in the room who ask for additional data and if you don't have them then it will call up for an action item and next round of follow-up review.

      I often face questions like, what is the variation of this or that, what is the contribution of external noise, offset, mismatch, contribution of temperature variations.. etc. etc….  If you say that you have checked it and have not highlighted it in the slides since their contribution is meagre, still people would want to quantify it and document it.  somebody would say, it would help for future re-use of the same IP.

  2. amrutah
    February 25, 2014

    Brandt: I like your idea of one-pager or template.

       We follow a somewhat similar template for our reviews, but are never one-pager :P.  We have 4 checklists that has to be ticked-off before calling for a design review, which just confirms that I have looked at most of the situations/issues from previous project learning. 

      I think there should be check on the lessons learnt which is missing from your list.

  3. etnapowers
    February 26, 2014

    I think that for an effective design review process the attendees of the meeting should be not only the design team but also engineers in charge of testing , product developing: this could make the meeting really interesting.

  4. Davidled
    February 26, 2014

    I wonder if any sales or marketing engineer will be invited for design review meeting including manufacturing engineer. It could be more interesting as a different background engineer participates with design review meeting.

  5. chirshadblog
    February 27, 2014

    @DaeJ: Yes, I also feel that they should too be included for these kind of decision making meeting. They do know what the customer feedbacks are exactly so they can provide an input or two for this surely.           

  6. chirshadblog
    February 27, 2014

    @etnapowers: Yes the majority should be the engineers and the developers but there should be others too involved in the decision making providing their inputs too. That will make the process designing a much more fruitful one for the future.            

  7. Netcrawl
    February 27, 2014

    @etnapowers I agree with you engineers must take charge of product development and research, they must also involved in some strategic decision-making, their presence is very important. The reality is engineers run the “game” we need to get them on board.

  8. amrutah
    February 27, 2014

    @etnapowers : I understand the need for all the engineers involved with the project to be a part of design review but I totally disagree with you “this could make the meeting really interesting”.

       The design reviews should be totally concentrated on the aspects of design, discussion about why a transistor/circuit is present, pros and cons of a particular articture. A technical guru/experts who can pinch you with questions that you may have missed while designing. 

    What a testing engineer needs or a application engineer needs is totally different from the implementation.  May be a seperate review may be scheduled with the test team and application team (which should happen even before the design process has started, so that the design engineer add sufficient DFT and application programmable options).


  9. amrutah
    February 27, 2014

    @Netcrwal: I don't think “engineers run the game” .   The systems are getting so complex that everyone needs to be at their toes to deliver a product. If the testing time is more the cost is more, so enough DFT has to be put in place to make it smooth and fast.

      I have seen test and verification engineers yawn and dose-off during the design reviews as they don't understand when gm-gds, necessity of a sub-threshold operation of a particular device, pros and cons of different architectures etc. are discussed.

  10. eafpres
    February 27, 2014

    @Brandt–I think you are on the right track.  If you are familiar with the work of Edward Tufte, among other things he despised Power Point as seriously undermining the process of engineering review.

    I attended one of his seminars and it was well worth the price of admission.  There is one idea he promoted for meetings that I think is close to your one page.  Tufte called it a Supergraphic.  Essentially he said that a well thought out one page (he allowed it to be bigger than 8.5 x 11) data visualization along with the necessary technical verbiage could take the place of most traditional presentations.  He also believed you should provide it to everyone in advance, and the meeting was to talk about it and answer questions, not look at it for the first time.

    Nowadays we are all in a hurry, PowerPoint is easy to use, and so people fall prey (I still do) to the urge to make it all look nice and sound coherent, often at the cost of content density.

    By the way, Tufte also pointed out that printing on paper still beats most computer displays hands down for resolution, which allows you to get more information per square inch.  Unfotunately, in some cases where I tried the high density approach, other managers thought I had some kind of graphics disability.  If the couldn't read it from the back of the room they thought I had lost my mind.

  11. eafpres
    February 27, 2014

    @DaeJ–in a past comapny we had a good stage gate process.  There were four or five key gates.  Each of those was a review, although not a full design review, sometimes the stage had more to do with validating business objectives etc.  The way the process was designed a cross functional team was assigned to the project for the entire life.  There was sales, engineering, manufacturing, supply chain, quality, reliability, product management.  Every stage gate review had to have all of them.  The lead on most projects was an engineer, most of the time a mechanical engineer (even though we made RF products, the RF engineers tended to be too flighty to be good project leads).  These leads learned to have everything in order before these meetings becuase at any time there were maybe 100 of these projects going on (all custom design work for OEMs) and time was a precious commodity.  In order to reduce all those extra questions at the meetings, behind the stage gate there were a lot of requirements like tolerance stack analysis, reliabilty test results, DVT testing, component first article reports, FMEAs, etc.  All of these had been learned over 25 years to be important; there was very little that was just “pushing paper”.  I have to say it was very well done and very efficient.

  12. studleylee
    February 28, 2014

    We also used to make reviews fun by giving incentives for finding errors or design issues.

    These could be anything from the designer having to put a few dollars in a pizza friday fund, or the 'finder' getting movie tickets or similar.

    This helped reduce the tendency for reviewers to just skim the material briefly.

    Most importantly, It all should be kept in good fun and not as a finger pointing exercise.  

    A happy group wants to do well. A whipped group just wants it out the door.


  13. eafpres
    February 28, 2014

    @studleylee–I believe the same approach is used to find bugs in software–a small payment for each bug found.  Some companies outsource this which can be very effective since they only pay for bugs found, not for time spent looking.

  14. geek
    February 28, 2014

    @studleylee: What you suggested is something close to what I witnessed in my last company. Frustrated by the inability of QA team to catch bugs in the applications, the CEO decided to give a reward of $5 for every bug a QA person caught. Of course they got their normal salary and everything but this was a way to motivate them further.

  15. geek
    February 28, 2014

    ” Tufte called it a Supergraphic.  Essentially he said that a well thought out one page (he allowed it to be bigger than 8.5 x 11) data visualization along with the necessary technical verbiage could take the place of most traditional presentations”

    @eafpres1: I like the idea a lot. I think visual explanation of concepts are a much better way than series of text. Not only do they help the user understand the concepts, it also gives a lot of clarity to the person explaining them and many a times he/she may have to rethink about ideas before proceeding further.

  16. SunitaT
    February 28, 2014

    @Brandt, thanks for the post. Creating slides for Design reviews is as tedious as doing Design itself. I think its also very important to stick to the topic when Design review is on.

  17. SunitaT
    February 28, 2014

    I think visual explanation of concepts are a much better way than series of text.

    @tzubair, I agree with you. I think visual explanation helps the presenter to catch the attention of the audience.

  18. SunitaT
    February 28, 2014

     CEO decided to give a reward of $5 for every bug a QA person caught. Of course they got their normal salary and everything but this was a way to motivate them further.

    @tzubair, such gestures always helps to keep the employees motivated. I think all the CEO's should implement such awards to keep the employees motivated and increase their productivity.

  19. SunitaT
    February 28, 2014

    We also used to make reviews fun by giving incentives for finding errors or design issues.

    @studleylee, sometimes just appreciating the effort of the employee infront of the full team also helps to motivate the engineers. Companies can list the top performing employee names on the notice board to encourage all the engineers.

  20. SunitaT
    February 28, 2014

    The design reviews should be totally concentrated on the aspects of design, discussion about why a transistor/circuit is present, pros and cons of a particular articture. 

    @amrutah, true but its always better to have a representative from the test team so that he can give his perspective from testing point of view. I agree it doesnt make meeting interesting but it atleast helps in exchange of ideas.

  21. SunitaT
    February 28, 2014

     I think there should be check on the lessons learnt which is missing from your list.

    @amrutah, I agree with you that the lesson learnt is an important part of design review process. Sharing lessons learnt with other team members definitely helps them to resolve the issues quickly.

  22. SunitaT
    February 28, 2014

     It could be more interesting as a different background engineer participates with design review meeting

    @Daej, I agree with you. But sometimes we need to differentiate between team meeting and top-level meetings. In top-level  meetings all the teams can participate but in team-meeting it should be limited to teams which are actively working on the project.

  23. Davidled
    March 1, 2014

    Employee level could be minimized. Too many steps and meeting cause the cost in the company. Also, sometimes presentation of all information might be distorted through the report process from top to bottom. Personally, I prefer one group meeting for design review instead of a different level meeting.

  24. Netcrawl
    March 2, 2014

    Too many meetings is not good, its already disruption. Disruption is the main enemy of innovation and productivity we should avoid that. Presentation can be done during high level meeting with top management.   

  25. eafpres
    March 4, 2014

    @Netcrawl–you are definitely correct about too many meetings.  I'm involved in an Agile software development.  Although the process is very powerful, when we add up each day brief meeting, every other week 6+ hours meeting to review, perform retrospective, plan next sprint, and detail tasking and time estimates, then another 1-2 hour alignment meeting every 2 weeks, where does that lead?  The actual resource time per developer is 27 hours out of 40 hour week.

    The process is very good, but challenging for many reasons.

  26. etnapowers
    March 4, 2014

    @DaeJ: It could be really interesting to me, the marketing people could realize what kind of product are effectively feasible and the product or process engineers might share effectively the roadmap of the company for future developments of innovative products.  

  27. RedDerek
    March 4, 2014

    The incentive idea should keep people awake.

  28. RedDerek
    March 4, 2014

    In the old days, so I have been told, designers would essentially gather around the schematic and then nit-pick every component selection to ensure that power, voltage, current ratings are sufficient to deal with all contingencies, and to discuss why one circuit topology was used over another option. These were the detailed, in-depth design reviews. (OK, this is from the Apollo days.)

    A design review can be as detailed as what is described above, or superficial as “here are the specs and here how they are met” slides. Then there is the discussion as to why parts are placed at certain locations on the PCB.

    Real design review challenge is when one is the only designer at a company, such as a consultant. This is the situation where one has to be able to nit-pick their own design, yet be able to show to the customer that all the specs have been met. And any design reveiw meetings have to be on a high-level since all others in the room may not have the technical competence to understand the details of why one resistor value was selected over another value.

    To summarize, all the comments seem to agree that a design reivew can range in meaning and can have specific or general attendees.

  29. jlinstrom
    March 4, 2014

    Maybe a bit of 'no fairsies', but an engineer I worked with would put an obvious oops in a schematic to see if anyone was taking the design review seriuosly, or just another nap session with pictures…          The boss got a bit upset, be the point was made.

  30. eafpres
    March 5, 2014

    We required DFMEA for all designs at an antenna company I worked for.  Later, when we started making antenna assemblies for automotive, we got a bit of a lesson on how to do DFMEA (and PFMEA) more properly.  In most industries that are relatively mature and large, the FMEA rules have been worked out in detail.  So, for instance, using a certain type of component had defined risk levels etc.  Soldering got a lot of attention, as did connectors.

    I think if an FMEA were done correctly and before the design review, then aside from checking design details, it can form the basis for most of the design review.

  31. Davidled
    March 5, 2014

    -> Soldering got a lot of attention

    Today, most soldering is done by SMT machine for electronic module. For DFMEA, SMT machine may be executed through DFMEA, unless hand soldering is required for antenna assembly.  Antenna engineer may review the antenna performance as well as soldering condition in the PCB board.

  32. eafpres
    March 5, 2014

    It might be a surprise to some that there is a lot of hand soldering done even in Tier1 automotive suppliers.  For example, all those roof-mount antennas on cars (which have satellite radio, gps, AM/FM, etc.) have 1 to 3 coaxial cables.  Those are hand soldered to PCBs to get the signal off the board onto the cable.  The process has proven very reliable and lower cost than some kind of SMT part to act as a connector on the PCB.

  33. Sachin
    March 31, 2014

    There was a time when I dreaded design reviews; that was about the time when I started out as a serious designer and I wanted to prove myself to the world. I thought by paying attention to every new design presentation and taking it all in I could achieve that goal but with time, after attending many such reviews, I learnt that this was practically impossible. From inarticulate presenters to very tiny plots that were extremely difficult to review, it just wasn't possible to keep up and today I can hardly sit through a single review. Yes, it's about time some change was seen in this area.

  34. amrutah
    March 31, 2014

     “Sharing lessons learnt with other team members”

    @SunitaT0: Is there a mechanism that you follow for sharing the lessons learnt.   I usually document the things I learnt and the way I want to take forward the design. Whoever is using the IP needs to refer to it along with the design review documents.

  35. SunitaT
    March 31, 2014

    There are some challenges with design review, like for example consider being one and the only designer in a company; it is evidently true that for one you will be overworked. You have to show customer that the specs have been met, which you do after picking on your own design. Since people differ in their level of competence and understanding, therefore, design review meetings have to be of a high rate.

  36. SunitaT
    March 31, 2014

    Even though most design professionals, especially those from the older generation, will probably not agree with me on this, I believe that the best way to reduce the boredom associated with design reviews is by introducing some element of humor within the presentation. I have tried that in a few of my own presentations and I generally find that the attendees are usually more attentive when I introduce the humor. However, the humor should be in closely guarded quantities.

  37. yalanand
    April 30, 2014

    I agree totally that for effective design review different people should be involved, this is for the obvious reason that there are some critical details that could have been overlooked by designers. This can be pointed out by inclusion of product developers and those engineers who will be in charge of testing the effectiveness and suitability of the designs. It should therefore a process that involves team work to be able to put into consideration the feedback from the customers.

  38. yalanand
    April 30, 2014

    I agree that design reviews can generally be a lengthy and boring process especially to those who are listening to the reviews. This can be pegged on the reviewers desire to ensure a comprehensive presentation without leaving out any single detail. This will lead to the compilation of numerous data that may at times be boring to the listeners. However if the reviewers applied certain tactics such as the use of humor and lively demonstrations the extent of boredom of the reviews will be greatly reduced.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.