Key elements for Product Design

Key elements for Product Design

Design Rush offer an index of service categories covering a wide range of design capabilities from mobile development, web development, product development, and a fairly comprehensive range of design and marketing services.

I was recently asked to contribute to an expert insights discussion on Product Design versus Industrial Design and found some of the other contributions quite useful.

The big take away from me is the lack of clear differentiation between terms like Design, Development, Industrial Design, Product Design, Engineering Design and… you get the idea. How can first time buyers navigate this space or tell if a particular offering covers everything they need?

If this is of interest to you then you might also find this post on the overall Product Development Process useful in navigating some of this territory.

Product Development Process

Product Development Process

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 40 years.

You can also follow us on LinkedInFacebook and Twitter.

This post is Copyright © 2024 Successful Endeavours Pty Ltd

 

 

Lessons in Product Development

New Product Development

In Product Development Process we looked at all the steps in Product Development. The need can vary a lot and so it is also useful to hear from those who have bright new products to market. So it is with pleasure I can direct you to an excellent resource with eight lessons from top executives.

 

Here is the list of lessons:

 

  • Melissa Perri: Learn what your users want before shipping
  • Marc Rubner: Deliver a tangible impact for your customers
  • Christophe Gillet: Assess market viability
  • Brian Tubergen: Prioritize the best opportunities
  • Andrea Schneider and Lauren Gilchrist: Educate stakeholders on modern best practices
  • Jeff Gothelf: Define objectives in terms of business problems
  • Jeetu Patel: Build teams that are motivated to execute
  • Eric Ries: Prioritize experimentation

The collation is by Mike Fishbein who interviewed each executive and there are also podcasts expanding on the ideas.

Mike Fishbein

Mike Fishbein

 

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2018 Successful Endeavours Pty Ltd.

 

 

Electronics Design: Prototype

What is a Prototype?

A Prototype is done in order to explore some aspect of a new opportunity without having to fully commit to it yet. Prototype has a number of potential meanings including:

 

  • the original or model on which something is based or formed
  • someone or something that serves to illustrate the typical qualities of a class; model; exemplar
  • something analogous to another thing of a later period
  • biology. an archetype; a primitive form regarded as the basis of a group

So a Prototype is either an early model or a smaller scale development to test a new idea.

 

Why Prototype?

So for engineering, we Prototype to reduce risk, and we learn from Prototypes to improve the likelihood of project success by being better informed for the next round of design. So a Prototype is a core Product Development Process Risk Management strategy.

 

Product Development Process

Product Development Process

A Prototype can also reduce other risks such as financial risk or market risk and isn’t always done for technical risk reasons.

 

Financial risk can be managed by breaking a project up into a series of stages and only committing funds to a stage when its predecessor has been successfully completed. A Prototype is often done ahead of a major block of Product Development to test whether the technical approach is likely to succeed and provide early warning of unexpected problems or interactions.

 

Market risk can be managed by trialling a new product idea with a smaller group of candidate customers to gauge their acceptance of the product. This has to be well managed however as history has shown that this approach, especially in the case of focus groups, can often just elicit the outcome the company hoped for and not a real example of how the market will react. Just look at all the failed Coca Cola new flavour launches.

 

And of course, technical risk can be managed by making Prototypes that implement the highest risk features as early as possible. We covered this in Improving Product Development.

 

A Prototype can often be used during Engineering Analysis in order to evaluate the effectiveness of different options for addressing the Requirements. This is covered in Electronics Design Process.

 

Successful Endeavours Development Process

Successful Endeavours Development Process

And then having designed a product it is normal to build a Prototype to ensure the final solution works as expected. This manages the risk that production tooling might need rework or even redesign.

 

How to Prototype?

This depends on the problem you want to solve. For this section we will focus on technical risks. A Prototype is very useful to allow you to measure some essential elements of the final product without committing to a final solution. So you can explore:

 

  • modelling a problem and simulations
  • noise and interference
  • power consumption
  • performance versus cost (compare several different prototypes)
  • responsiveness
  • system resources required
  • hardware versus software solutions
  • temperature rise
  • materials properties
  • shape and usability / ergonomics
  • fit (especially PCBs in mechanical housings)

And the list can go on. The key is to determine where the risk is and manage that. In Project Management Pre-preparation we looked at using a Prototype to reduce both technical and financial risk at the same time. In this case, other developers hadn’t been able to produce a working product so the client had a clear risk to manage. And our approach was to make a jig that allowed us to explore the sensing that was needed and get real data to then analyse and develop a solution. The same jig allowed the solution to then be tested before we designed the Electronics PCBs and Embedded Software needed for the final product. And the client was able to authorise each next level of expenditure with confidence based on us having delivered against the requirements for the previous stage.

 

Simulation

Simulation

And of course, 3D Printing for Electronics has enormously expanded the possibilities for mechanical prototypes by allowing anyone to quickly build and test the fit of objects together. It is also a viable option for low volume manufacturing.

 

3D Printed Spacer

3D Printed Spacer

3D Printed Spacer Fitted

3D Printed Spacer Fitted

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2017 Successful Endeavours Pty Ltd.

Visualisation: Part 4

Viewpoints matter

How does the world look to you?

 

This is often one of the areas where Engineers and Customers can get out of step. And in particular, is a big issue for Software Development and IT systems. Check out the image below.

 

Round or Square Columns

Round or Square Columns

Technical professionals such as Engineers and Software Developers tend to be detail driven and so probably look at the system from the ground up. So we would see round columns.

 

Entrepreneurs and Business Owners tend to see the world from the top down and so would see square columns. And this difference in perspective can be a problem in implementing a solution that works for the customer.

 

So here we have an image that represents the potential difference between the Engineer Viewpoint and Customer Viewpoint.

 

Requirements Management

The real issue here is Requirements Management. This is one aspect of Software Development where I like the V Model for Software Development and the European Space Agency Software Engineering process. It splits the problem down into steps and also lets you know whose language the documents at the step are written in. So User Requirements are written in the language of the user. Technical Requirements are written in the language of the technical professionals. And Requirements Analysis is required to determine the relationship between the different viewpoints. For most projects the analysis is used to translate User Requirements to Technical Requirements. So now we can all have a viewpoint that we understand and it is linked.

 

The V Model for Software Development

V Model

The general steps are:

 

  • User Requirements – in the language of the user
  • Product Requirements – in the language of the user and relevant standards and market needs
  • Technical Requirements – derived from both the above and in the language of the technician
  • Functional Decomposition – breaking the problem down into specific functions to be performed
  • Architectural Decomposition and Requirements Allocation – working out that is done in hardware, software, locally, remotely …
  • Detailed Design and Module Specifications – specific modules to be designed and tested

 

So we move from user language to technical language in a structured way that allows us to understand was is required and make sure nothing has been missed.

 

User Requirements and Technical Requirements

Requirements Analysis

Product Development Process

The Product Development Process is intended to ensure that the product meets its requirements and is delivered on time and on budget. And regardless of the size of the project the above steps are required. Who does them and how they are done is less important than that they are done. Smaller projects might not require a formal approach but any significant project certainly does. And this also helps to overcome the difference in viewpoint between Technical Professionals and their Customers.

 

The image for today’s blog post was provided courtesy of Dr Marc Dussault, The Exponential Growth Strategist who is always on the look out for examples of antimimeticisomorphism, which I am sure you’ll agree this is!

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd

Product Development Process

Product Development

As a technical professional, I tend to think of the Product Development Process, also known as New Product Development, as the creation of the product technology through to a working unit that can then be manufactured. And of course managing risk to Improve Product Development Outcomes. The only thing wrong with this picture is that this is only a part of the overall process of bringing a new product to market. So I’ve put a diagram together that shows a more complete picture.

 

Product Development Process

Product Development Process

One thing I noticed when I did this is that there were four areas that had the most influence on the overall process. These are:

 

  • design capability
  • development capability
  • funding
  • production capability

 

And of these, the ones that had the most influence were:

 

  • funding
  • development capability

Products Have Stakeholders

A successful product is successful within a market and has multiple stakeholders. A developers, we might not be as aware of all these stakeholders as we could be. For instance, a product must not only work from the technical performance perspective, but it must also work from the perspective of the manufacturer, the sales person, the installer, the service technician, the shareholders, those tasked with public safety and clear mobile communications, those who have to dispose of the product at its end of life and of course the end user. That is a lot of people to please. And they aren’t all on the chart above either.

 

This is why exceptionally good Product Development is not just a case of following a specific methodology. So we are mostly involved in the Product Development Process but it does help a lot to see that there is a bigger picture and that even if you do a good job technically, it is just one of the the ducks you need to line up in order to get all your ducks in a row and a successful product into the market and making money and adding value to everyone.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.