feature article
Subscribe Now

It Won’t Fit in a Box

System Engineering the User Experience

A few weeks ago, my esteemed colleague Bryon Moyer wrote an article entitled “Just Who Is the Customer?” In this article, he identifies the “toll-taker” or “gatekeeper” as a sort of semi-villain who takes decision power away from the consumer for his own gain. Bryon makes a well-supported case, but I’d like to propose an alternative question and an alternative explanation:

Just What is the Product? 

As electronic engineers, we design things like circuits, chips, boards, boxes, and “systems.” It is very rare that we design something that stands atomically and autonomously alone. Just about everything we envision and engineer is a cog in some larger machine, and just about everything we design uses someone else’s end product as a component. We take the products of others’ work, add our value, and hand that up the food chain to some other team who adds their value, and so on. 

At some point, of course, an end-consumer buys the thing. Usually, in our mind’s eye, the “thing” comes in some shrink-wrapped box. Historically, that box has defined our concept of the product. Over the past couple of decades, however, that box notion has begun to break down. We don’t really buy a “phone” – we acquire a device that provides one component of a complex communications service. The phone is meaningless without the network, and much of the actual product is behind the scenes – cell towers, switches, millions of miles of fiber and microwave links, countless computing engines, and the services of a small army of technicians, maintenance personnel, customer service agents, and other parties – all of whom are essential to the successful operation of the “thing” we are buying.

As a customer, then, what we are buying is often more an “experience” or “service” than a simple product – even though we plunk down the cash for something in a shrink-wrapped box. We are purchasing the ability, as I did last week, to stand on top of a glacier in Canada and communicate with an associate in California about a meeting with a company in Asia, then pull in help from Oregon to coordinate the meeting. Then to immediately post a vacation photo of the glacier to a social media site (on a server located who-knows-where), which was seen by my mother in Texas only moments later. This is not something that comes in a box. (This is also where one might point out that I should get a life and not be that guy walking around on the glacier looking at his phone, but – back to the topic at hand…)

It’s pretty clear, for example, that FPGA companies are designing components – meant to be used in the engineering efforts of others, but FPGAs themselves are the end product of an FPGA company. And, an FPGA as a product is a lot more than simply a chip. FPGA companies must deliver software, services, IP, development boards, and a host of other elements in order to create the experience their customers (engineers) require.

With the line between product, service, and experience becoming so blurred, and with the complexity of products rising dramatically, we are also reaching a juncture where the majority of customers use only a tiny fraction of the capability of most of the products we create. There was a time when a television set was one of the most complicated things you could purchase. That television set had three controls: power, volume, and channel. Just about every consumer who bought that device fully understood the purpose and operation of those three controls. They used all of the capabilities of the device on a regular basis. Today, the average consumer who purchases a smartphone or a computer uses only a tiny fraction of the capabilities of the device. The bottom line is – today’s consumer understands very little about the capabilities and operation of most of the electronic products we design.

This user-understanding gap arises, not because today’s consumers are less intelligent, but because today’s products are vastly more complex and capable. Nobody needs to use all of the capabilities of a smartphone. The device is so rich in features that even a small subset of those make it a satisfying purchase for the average user. 

From an engineering perspective, of course, there must be a “system engineer” responsible for the big picture of how this big product operates. One of the jobs of this system engineer is to figure out the sandbox in which the user can play. If the system has options, configurations, plug-ins, applications, or other means of customizing the services it provides, someone needs to define the boundaries of those user-modifiable parameters. When those add-ons and modifications can come from third parties, system engineers need to determine the consequences and the adaptations required to accommodate this third-party addition to the value chain.

When products were simpler, so was this role. Today, though, with product ecosystems that sometimes span thousands of features and potentially hundreds of third-party expansion or alteration possibilities, it’s a daunting task. Further complicating the matter, the difference between the level of understanding a system engineer must have of the system and the level of understanding the average user attains is enormous. This gigantic gap in familiarity directly attacks one of the most important skills of the system engineer – customer empathy. The system engineer, with an immersive wealth of knowledge about the complex product they are creating, must be able to put themselves in the mind of a user who knows (and cares) almost nothing about it.

So, often, the “gatekeeper” that Bryon’s article describes may be nothing more than a visionary system engineer trying to manage the quality of a complex product by exercising some control on the number of possible variables affecting the behavior and performance of the thing they’re designing. While it might seem attractive to leave this somewhat in the hands of the potential customer, the complexity of many of today’s products, combined with the limited scope of use of the average customer, can make that a dangerous gamble. 

Further complicating the matter is the scale of production required for many of today’s products to hit their price targets. When you have to mass-produce devices in enormous quantities in order to be competitive, you lose the option of offering a wide gamut of options and product variants. The cost and complexity of creating and supporting a wide array of versions of a single product can be prohibitive. By the time a phone support technician wades through the long list of questions required just to establish which version of the product the customer is using, what aftermarket add-ins are installed that might affect the problem at hand, and which components may be missing from this particular customers’ configuration, patience may have worn thin. In order to create a product use and support experience that is in line with what today’s customers expect, it is usually necessary to simplify and streamline the product itself, and to restrict the flexibility we allow the user in modifying and customizing it. 

As engineers, we don’t generally like people to limit our creativity – even with products we buy. We tend to want to customize, modify, and tune everything we use to suit our own particular needs. In fact, most of us would much happier if anything we purchased for our own use also came with schematics and source code. But engineers are anything but typical consumers, and using our own wants and needs as a model for what we design is a mistake. However elusive it is, we need to build that empathy for the casual, uninformed customer, and design something that will create a delightful experience for them. If that results in a product that happens to make us happy as well – that’s a wonderful bonus.

2 thoughts on “It Won’t Fit in a Box”

  1. Bryon Moyer wrote an article asking “Just Who is the Customer?” that inspired me to write this piece – about the challenges of system engineering in the modern world, and how we make decisions about how much power and flexibility to offer our customer. What do you think?

  2. Funny thing about the phone example. When you described all of the other things behind the phone that we buy, I thought about the original phone system to figure out what was different now from then.

    And in fact the only difference is that then we didn’t buy the phone. The phone was explicitly accepted as being the end of this vast network (complex then even by today’s standards – and yet still far simpler than what we have today), and Ma Bell owned the entire thing – including the phone.

    On a separate note, you talked about managing the number of feature options. For FPGAs in particular, this started with high-speed I/Os if I remember correctly (LVDS, 8B/10B, training patterns, etc.). This is the first place I was aware of where they created “sandboxes” within which you could play. You didn’t get access to all the switches and settings and combinations. They would only support some very specific configurations, since the number of “creative” possibilities was huge and – most importantly – going rogue was likely to be really really hard for a designer to get right and would become a support nightmare.

Leave a Reply

featured blogs
Jul 20, 2024
If you are looking for great technology-related reads, here are some offerings that I cannot recommend highly enough....

featured video

Larsen & Toubro Builds Data Centers with Effective Cooling Using Cadence Reality DC Design

Sponsored by Cadence Design Systems

Larsen & Toubro built the world’s largest FIFA stadium in Qatar, the world’s tallest statue, and one of the world’s most sophisticated cricket stadiums. Their latest business venture? Designing data centers. Since IT equipment in data centers generates a lot of heat, it’s important to have an efficient and effective cooling system. Learn why, Larsen & Toubro use Cadence Reality DC Design Software for simulation and analysis of the cooling system.

Click here for more information about Cadence Multiphysics System Analysis

featured paper

Navigating design challenges: block/chip design-stage verification

Sponsored by Siemens Digital Industries Software

Explore the future of IC design with the Calibre Shift left initiative. In this paper, author David Abercrombie reveals how Siemens is changing the game for block/chip design-stage verification by moving Calibre verification and reliability analysis solutions further left in the design flow, including directly inside your P&R tool cockpit. Discover how you can reduce traditional long-loop verification iterations, saving time, improving accuracy, and dramatically boosting productivity.

Click here to read more

featured chalk talk

Datalogging in Automotive
Sponsored by Infineon
In this episode of Chalk Talk, Amelia Dalton and Harsha Medu from Infineon examine the value of data logging in automotive applications. They also explore the benefits of event data recorders and how these technologies will shape the future of automotive travel.
Jan 2, 2024