I’ve collected and revised these essays along with others written elsewhere and new material into one easy ebook. Designing Devices
“Designing Devices is great.” —Ben Bashford
“Dan Saffer’s short book on designing devices is very worth reading, even if you’re not actually designing devices.” —Basil Safwat
“Designing Devices is a great read. Highlights device design challenges and how to work through ‘em.” —Karen Kaushansky
One of the decisions facing device designers is whether or not to have a display screen on the device. The decision is both aesthetic and functional.
The moment you put a screen on an object, in most instances the object feels like an electronic device. It becomes categorized in the user’s mind as piece of equipment—a gadget—and expectations are set accordingly. The less you want your device to seem electro-digital, the less likely it should have a screen. Also some devices (like wearables) make having a screen on them impractical, either because of size, shape, or context.
Of course, removing the screen doesn’t obviate the need for feedback, or for the controls (and labels for controls) that screens typically afford. You still have to let users know when something has happened, and without the “luxury” that a screen provides. There are several ways to do this, namely:
Creating other visual cues means creating visual effects, typically via LEDs. An on/off indicator light, for example, or a status light that indicates what state the device is in. With LEDs, you have a number of variables to consider when designing: color, brightness/intensity, and pattern. Pattern can be multiple LEDs working together—for instance a string of lights that turn on in sequence—or a single LED that blinks in a distinct way, like a flashing light to indicate a warning. These variables can be used singularly in combination, such as an LED that dims, turns red, and pulses to indicate low battery.
Of course, unlike a screen where words can be displayed, an LED light(s) is open to interpretation. Does that blinking mean it’s connected to the wireless network, or not connected? Labels can help, certainly, but labels can also add to the “device-ness” of the object, not to mention visual clutter.
Audio feedback can replace a screen, although it does require a speaker. (Of course, if your device already has a speaker, it can be repurposed for feedback.) Audio feedback is of two types: sounds and voice. Sounds can be anything from the traditional beeps and boops and whines to music, sound effects, speech-like babble, and general noises of all sorts. A little of these goes a long way. The two-second sound clip of a woodchipper to indicate data being deleted is awesome the first time you hear it, a pain the 500th. Speech presents its own complications, as unlike other sounds, we are attuned to read a lot of emotional content into voices, both biologically and by training from birth. The choice of male or female voice can make a huge difference to how users feel about the device. Some people don’t like their devices talking to them at all, in fact.
One final note about sound: if there is one (and almost every digital device has one built in), make use of the clock. Sound feedback that is appropriate during the middle of the day is not in the middle of the night.
If your device is worn or handheld, another option is haptics: vibrotactile feedback. Haptic feedback is increasingly becoming more sophisticated, and a wide(r) variety of sensations are becoming available, from brief, subtle vibrations to more complex patterns and the ability to feel simulated movement “inside” the device. Unlike sound and even visuals, haptics are discrete and personal.
Needless to say, the type, kind, and combination of these different feedback mechanisms you employ work as much as the form to give the device its character.
N.B. Another increasingly employed method of getting around a lack of screen is to simply move the screen to another platform. Your beautiful toaster doesn’t have room for a screen? No problem: make a mobile app for it. Think: iPod shuffle and iTunes.
This method of moving display onto another platform has its merits and drawbacks. For devices with limited controls (e.g. a medical monitoring device, for instance), the screen might be perfectly acceptable on a tablet device like an iPad. Where this method breaks down is for many devices (as is best practice) you want the feedback and controls near the thing you’re controlling. Having to pull out another device to control the object in front of you can be tedious in the extreme. It’s best to do a functional cartography and figure out what high-use information and controls are needed, then figure out how to get those on the device itself. Features that can usually be easily (or more easily, anyway) moved off the device are related to management of the device itself, i.e. settings and any content management.
Not having a screen is difficult. It makes feedback harder and more ambiguous. You can’t make it a touchscreen and use it for both display and controls. In other words, it’s a constraint. But like all constraints, it can be a source of creativity if we let it.
Two truisms seem to be happening right now with technology:
Where then does this leave single-purpose, single-function devices? Are they to vanish into history? Some certainly will. For example, cameras, MP3 players, and video cameras are taking a beating from mobile phones. But I believe there is still a place for single-function devices, under specific circumstances.
A single-function device (an “appliance” as Mike Kuniavsky calls them, vs. a multi-function “terminal”) makes sense when:
Now I grant you some of these items are conditional—perhaps in the future the cameras in multi-use devices will be as good as professional ones. Even so, I feel there is always going to be a place for beautiful objects that one do one thing—but only if the integration of hardware and software is such that it makes accomplishing the task so much easier/more efficient/more fun than a multipurpose device would. That’s the challenge: how to differentiate your single-purpose device so that consumers will buy it instead of (or in addition to) an app that does the same thing. Designers have to not only explain why you’d want to own the chef’s knife instead of a Swiss Army knife, but also make the specialty item worth owning. That’s the challenge.
For tens of thousands of years, humans have used objects to augment our reality. We employ tools to do what we can’t do easily with our own bodies, to change our environment, and to reason through problems. Our devices are no different, only more powerful, with the ability to transform activities, spaces, even entire cities.
But what is a device? For the purposes of this blog/book, a device is any object whose mechanical and/or electrical workings are controlled or monitored by a microprocessor. In other words, objects that are made up of both hardware and software. This, however, is the definition of a modern device.
Historically, and even continuing into the present, devices have been objects with all of the following characteristics:
Using these characteristics, the first devices were powered by natural means. The first devices were likely timepieces powered by water (“water clocks”) in China circa 4000 BC and Egypt circa 1400 BC. The sailboat (4000 BC, Egyptian) and the kite (800 BC, Chinese) were both powered by wind. The lodestone compass (400 BC, Chinese) relied on the magnetic poles. Later natural-powered devices include the astrolabe (150 BC, Greece), handguns (700 AD, China), eyeglasses (1284 AD, Italy), the hourglass (1345 AD, Italy?), the microscope (1590 AD, The Netherlands), the camera obscura (1604 AD, Germany), the telescope (1608, The Netherlands), the sextant (1757 AD, Britain), and the camera (1826 AD, France) to name a few.
The first mechanical devices might be crossbows (500 BC, China and Greece). The oldest known scientific calculator, the Antikythera mechanism, dates to 150-100 BC, Greece. The spring clock (circa 1400, Germany?) and the pendulum clock (1656, The Netherlands) were the next major milestones in mechanical devices. Aside from the compass, the first truly portable device was the pocket watch (circa 1500, Germany?), which were worn fastened to clothing or around the neck as pendants. Aside from the Antikythera mechanism, other mechanical calculators were the Pascaline (1642, France), the Arithmometer (1820, France), and the Curta (1938, Austria). The typewriter (1829, USA), the phonograph (1877, USA) the gramophone (1881, USA), and the movie camera (1888, England) were some notable mechanical devices prior to the introduction of electricity.
Because of the size and heat, steam engines have not been used to power many devices, instead they were mostly for large industrial facilities and for transportation (trains and boats in particular). One notable exception is the steam donkey, a steam-powered winch (1881, USA). Similarly, the internal combustable engine proved too bulky for most devices…with the notable exception of the automobile (1886, Germany) and some farming equipment. While it is admittedly unusual to think of a car as a device, it does meet the criteria for being categorized as a device above.
Electricity really ushered in the era of the device. The radio (1893, USA), the flashlight (1899, USA), washing machines (1900, USA), the refrigerator (1922, Sweden), the dishwasher (1924, USA), the television (1927, USA), the electric calculator (1957, Japan), and literally dozens, if not hundreds more categories, stretching from home appliances to medical equipment to consumer electronics to toys.
Starting around 1970 with digital calculators, electronic devices started to be made with microprocessors built into them. The laptop (1968, USA), the mobile phone (1973, USA), the personal digital assistant (1992, USA), the digital audio player (1996, USA), and many more kinds of products started to be able to utilize the processing power of microchips alongside other electro-mechanical components.
What distinguishes the devices of today from previous eras? Aside from their appearance, construction, power source, and controls, it’s these characteristics:
Of course, with all these new characteristics and power comes complexity, which is why we need to design our devices well. Which is what this book/blog is all about.
It used to be that controls for an object were on the object. To operate a printing press, for instance, you stood next to a printing press and pulled the lever that opened and shut the press.
Later, starting around the 1890s with the introduction of electricity, controls could move away from the object itself to other parts of the room. Everything from light switches to operation of machinery could be done away from the object it was affecting. Other mechanical processes, such as shutting off the water to a building, could also be done on-site or nearby.
Telegraphs, and afterwards the telephone, radio, and television allowed people to affect objects from afar, but the controls were always on the object itself (to tune in and to adjust the signal).
Networked devices connected via Ethernet extended controls to objects in other rooms and the internet expanded this range to include the entire wired world. You can now fly robot drone planes on the other side of the globe. The controls are nowhere near what is being controlled.
This presents a bit of a problem for designers. In “traditional” interaction design, the rule is simple: if you can’t directly control the object itself (via physical controls or touchscreen gestures), you put the controls as close as you can to whatever it is you’re manipulating. The reason for this is simple: feedback. When you turn a dial, you can watch or hear something being affected; when you click an icon to make a word bold, you can see it turn bold. But when I set my DVR with a mobile app, how do I know the DVR itself is executing the command? Sure, I can get feedback from the app, but some trust is definitely involved. If I get home and Oprah hasn’t recorded, what do I blame: the device, the connection, the app?
There is also a distinct emotional impact the farther the controls move away from the object itself. Do I want to cook on my stove from a control panel in another room? Perhaps there are use cases when that makes sense, but it definitely would change the nature of working with a stove and how users feel about their interactions. Of course, it’s not always a negative to move controls to be away from the device: the introduction in the 1950s of the remote control only brought users more power and pleasure from their television sets.
So another choice then, for designers, is not just which controls to have, but where to put them: on, near, or remote. And the answer should be one of context: how important and immediate is the feedback (especially multi-sense feedback) to the task, and (related) what will it feel like to use this device from afar: is it empowering or dehumanizing?
One of the central tasks of any device designer is to create the interaction model. The interaction model is the overarching framework that ties the functionality together into a unified whole. Done right, the interaction model can be a major product differentiator; even if individual features are replicated, it may be difficult (although certainly not impossible) to reproduce the interaction model that ties all the features together.
Interaction models usually contain the following pieces:
In short, interaction models are the means to access and move between functions. Interaction models can be overarching to include the entire device, or they can be contained within a single application or feature.
The desktop metaphor is probably the most famous interaction model. You know how to launch applications, close them, navigate through folders, etc. Over time, pieces have been added to it, like OSX’s Dock or Windows’ Task Bar, but the model has remained remarkably consistent for 30+ years now.
The purpose of an interaction model is to create a logical consistency throughout the device, so that users can determine how to do something and route around any tricky situations. “I’m going to click on this, because in other places, this worked.” The device needs to make sense, to have flow that can be understood. Interaction models create the glue that holds a device together; a box that holds all the functionality.
If we consider what interaction models really are, we begin to realize that they are nothing less than the designer’s attempt to help the user generate a mental model of the device. Mental models are the cognitive method of understanding a device that may or may not be how the device actually works, but allows the user to interact with it. For example, I don’t understand how a car engine works, but I have a mental model in my head of how it does: I steer and push various pedals to make it go forward and stop. We likely create mental models of all sorts of things in the world, not just devices: everything from governments to games. We create representations of external realities and from them derive understanding. Our mental model can be wrong, of course, and that can cause confusion and worse problems.
What then, makes up an interaction model? Metaphors, for one thing. THIS works like THAT. “Your computer works like your desktop.” With devices that have abstract digital behavior, applying a metaphor can make the device more physical, and thus more understandable. A folder is more physical than a directory.
Structure is also a key component in any interaction model: how the functions of a device are positioned in relation to one another. Sometimes this is a matter of information architecture: arranging pieces into a findable information structure, such as into menus and hierarchies. Other times, this is interface or industrial design: grouping controls into a panel that makes sense. It can also be an interaction design task: how do the different panels or windows in an application interact with each other? What are the device defaults, and what can users change?
Interaction models are tied to the device’s functional cartography. Functional cartography is the mapping of features and functions to a device in order to determine which functions are controlled by physical means (mechanical controls), digital means (onscreen controls, sensors), or both. Once the interaction model has been determined, the functional cartography should spring from it.
A through-line is another component of a good interaction model. A through-line is figuring out the likely pathways through the device. A user will do A, then B, then C. Any model should work really well for that A-B-C pathway. A through-line acts as the rhythm section for a rock band does: it shows where the emphasis should be placed and keeps the tasks moving forward.
An interaction model has to fit the device’s major functions, and these can be used as a type of test for any proposed model. “How would this tiling of the screens work with email?” In fact, if an interaction model doesn’t work with any of the major pieces of functionality, it simply might not be the right model. Lesser pieces of functionality can, with some work, often be conformed into fitting into the framework, but everything important should seem “native” to the device: like the device was made to perform those actions. Which, of course, it should be.
The best interaction models are either nearly invisible (that is, they do not get in the way of using the functionality), or else they are extremely pleasing in and of themselves. Transitions and navigation can be done in a manner that is not just a humdrum menu and one screen simply appearing. Think of TiVo’s left-right transitions between screens or the many transitions an iPhone has between applications.
A device without an interaction model will likely seem disjointed and made up of pieces, instead of as a whole. Pieces of functionality will work differently and the overall concept will be hard to grasp. Many mobile phones, appliances, and consumer electronics suffer from this problem. A solid interaction model is the basis for any great device.
I was at the annual Consumer Electronics Show in Las Vegas last week. If you’ve never been, let me quickly describe it. Major manufactures and suppliers (Sony, Samsung, Nokia, Intel) as well as hundreds of companies you’ve never heard of, fill up several enormous buildings with row and row after row of booths and displays hawking their wares. Some of these booths are enormous, million-dollar affairs, while some are, well, just a table with stuff on it. It’s overwhelming, disorienting, and hard to remember one product from another.
And yet, some devices certainly are memorable. How is this, and why?
In order to create a product that stands out, you have to think strategically about it. If you design the same device that is already on the market, you create no value for your organization and no reason for a consumer to buy it instead of another device. To paraphrase strategy guru Michael Porter, your device has to be different than your competitors either by performing different functions, or by functioning differently. By doing so, you make it hard to replicate, and thus you have a strategic advantage.
A differentiator is a characteristic that, all other characteristics being equal, would cause a user to choose one device over another. Here are the major possible differentiators a device could have:
I’ve ranked these in order from easiest to replicate or do better, down to those that are very challenging to outdo. The more differentiators a device has near the end of the list, the vastly more difficult it will be for competitors to recreate and catch up. If we take the iPhone, for example, which had many of these differentiators (form, brand, quality, functionality, technology, behavior, ecosystem), some analysts believed it would take Nokia seven years to come up with a similar offering. And even though some of the differentiators (form, quality, functionality, and technology) have been replicated since its launch, and other similar phones might have other differentiators (namely price), the iPhone is still a distinct product because of the other differentiators it still maintains (brand, behavior, and ecosystem).
Differentiators feed into the value proposition for users. “If I use Device X, I will get Y as a result,” with Y being the product differentiators (although users certainly don’t think of them as such). In the past, Y was either usually price or quality, but increasingly the other differentiators play a role as well. Some of these differentiators, of course, can usually only be obtained over time, such as brand and community, but many can be built into the device, via hardware (form, quality, technology) or software (functionality, behavior).
A word of caution here: a shallow differentiator can be just bad design: making the device different for the sake of having a differentiator, not for the purpose of making it better. Worse is adding a feature to have a differentiator, even though it doesn’t support the overall goals of the product concept. This just leads to a confused product. “Our music player has calendaring functionality.” Don’t add a differentiator just because you can, but because it makes sense to do so. It won’t add value and can damage the product and your brand.
There is, however, the “feature paradox” that James Surowiecki points out in a New Yorker article:
[A]lthough consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity.
Companies like features too, for the simple reason that they are considerably easier to sell. They fit neatly into product comparison charts, and it is easy to see how your device (seemingly) matches up against another. But as pointed out above, technology and functionality (the differentiators that usually comprise “features”) will be replicated. Behavior, Data and Content, Community, and Ecosystem are much trickier (although not impossible) to recreate. Paying attention to how features are embodied in the device will make more of a difference in the long-term (and often in the short-term as well) than the fact that there simply are certain features.
It is this How where design really plays its role. How does the user get from feature to feature? How do you access the feature, and how does the device respond once the feature is engaged? How can we encourage a community of use, or create the ecosystem this device lives in?
All of these differentiators, these Hows, should add up to the “of course” moment. Of course it works like that. How else would it work? That’s when you know you’ve gotten the right combination of differentiators to create a high-value product that will be memorable at next year’s CES.
In Marc Weiser’s seminal 1991 essay The Computer for the 21st Century, he defines three general forms for devices in the 21st century:
Clearly, Weiser was thinking mostly of an office/workplace environment with his categorization scheme. If we expand our view out a little more to include homes and public spaces, I think there are some other general types that could be included in Weiser’s categories:
It helps to consider these categories, because each brings with it different expectations as to how to engage with the device and what kinds of functionality might be available, not to mention qualities such as durability and cost. Device designers need to be aware of this when considering what form a device should take.
Of course, traditionally, this is has likely been determined before the designer even starts the project: “We need a new line of washing machines. Go make us some.” But in the 21st century, it’s not quite as simple. Frequently now, the starting point is not the form, but instead the functionality, with the form enabling and enhancing that. As electronics and computer components get smaller, it’s easier for what might have been a Box at one point to become a Pad, Tab, or even a Dot and “disappear” all together. There’s more computing power in a digital watch these days than in the NASA capsules that went to the moon. Functionality, and thus form, is more fluid and cross-category.
Of course, a Vehicle is not likely to become a Dot, but the functionality such as a navigation system that might have previously been stored in a car (in the dashboard, say), might now be in the Tab that is your mobile phone.
There is also an emotional response around different forms. We have a different relationship to our mobile phones than we do to our stoves, or to our cars as to our laptops. Some of this is certainly about price point (our cars cost more than our mobile phones), but some is the pure physicality of the object itself. A large, heavy, immobile object usually has more emotional weight than a small, mobile one. If just for the fact that it has a larger spatial (and fixed) presence in a room. You would immediately notice if it was gone. This is a tricky problem as more objects dematerialize and become Dots. Will you feel differently about your TiVo/DVR if there was no Box and no remote (only gestures for control)?
Every button, slider, switch, knob, or dial represents a choice. Two choices, actually: the choice to have it, and the choice to use it.
The first choice is that of the designer. A control, in its most basic form, is the visible manifestation of a piece of functionality. It gives a cue to the user: you can do something here.
The physical characteristics of a control, what interaction designers call affordances, dictate what can be done with it. A button affords pressing, for instance. Thus, the choice of control is important as well. Sliders, for example, are best used for granular control along a continuum, where there are known thresholds at the top and bottom. Switches are good for clear states, e.g. on/off. And so on.
Every decision to add a control, even a simple button, increases the complexity of a device. After all, in this digital age, devices can do almost anything for a user, from adjusting volume to taking pictures to controlling satellites in space. Control of the device can be held completely by the device. It can be completely automatic. In some cases, like for pacemakers, say, you want this. You don’t want to have to tell your heart to beat! The less controls there are, the simpler the device is for a user (although probably not for those involved in making the device).
Of course, by reducing controls (and thus reducing complexity for the user), you also reduce, well, control over the device. Users can do far less with it, and have little to no options for customization. Again, sometimes this is desirable. But sometimes, it is a disaster. Reducing complexity means reducing control, and some users, particularly those whose skill goes beyond that of amateur/beginner, don’t just want control, they need it to perform their tasks effectively. Thus, it becomes a balancing act, with simplicity and automation on one side, and complexity and control on the other.
How you determine which side of the continuum to fall on depends on a number of factors:
No matter which side you choose, complexity just doesn’t go away. Larry Tesler, creator of such enduring interaction design paradigms like cut-and-paste, has noted this in Tesler’s Law of the Conservation of Complexity. All processes have a core of complexity that cannot be designed away. The only question is what handles it: the system, or the user. By creating a control, the designer is making a choice, saying to the user in effect, “You handle this.” But if the system has to handle the complexity, it means all kinds of decisions have to be made for the user, your defaults have to be smart, and god help you if you get them wrong.
Take for instance a digital camera in which all controls except two have been removed: an on/off switch and a button to take a picture. This means the system either has to handle focusing, picture management, exporting, employing flash, zooming, etc. or else not offer the feature at all. If it’s determined that at least some of these features are crucial to the success of the camera, the resulting complexity which might otherwise be handled by the user has to be determined and built into the hardware and software. Bad choices (i.e. poor defaults) here will ruin the device. Pictures will be overexposed or blurry, users will be frustrated at not being able to zoom, and so on.
Of course, some device manufacturers have taken to spreading the complexity of their devices around, with pieces of functionality residing on the device itself, while others are handled by an application on the web, mobile, or desktop. The obvious example of this is managing your music via iTunes, but the listening and associated functions (rewind, fast forward, etc.) can be done on the device itself. The idea is to reduce the complexity of the device without losing any functionality; it’s just handled on other devices (a laptop/desktop or mobile phone) where a keyboard (and possibly a mouse and a larger screen) might be useful.
Once a control is in place, the second choice is that of the user: the decision to use that control. Designers need to help users make that decision as best as possible by designing the controls and their surrounding environment well. The best controls have three characteristics: an affordance to let the user know the control is there; an indication (often a label) of what the control controls; and feedback to let the user know the control has been used. If any of these characteristics are missing or done poorly (such as an unintelligible icon for a label), the control will lead to doubt. Helping the user understand what will happen when a control is used (so-called “feedforward” (pdf)) is essential to building trust in the device.
Predictability is also important in building trust. Users want to know when a control is operated, it will do the same thing each time. The system has to have an inner logic that, even if the users cannot articulate it, they understand it. Which is why, unless it undoes an action (a la an on/off switch), it’s a good idea to have a control only control one function. Having the same button do different things can be confusing. This is why soft-keys (where an onscreen label indicates a change in the functionality of a physical button) are problematic.
On-screen controls (and increasingly with physical ones as well), can be disabled or hidden when to use them would be dangerous (see: The Poka-Yoke Principle) or ineffective. Hidden controls are often extremely problematic. Users become accustomed to objects (even digital objects) being in the same place, and to remove them is cognitively jarring. Disabling, particularly if, via a tooltip or other means the user is able to determine why it is disabled and how to engage it again, is usually a much better choice.
Positioning and prominence are other important cues for users. A giant green button with a label reading “PUSH ME!” won’t be ignored, while a small switch in a bank of them will need to be scanned for. The one control that will be the most used or is the most important should get visual and/or spatial prominence. It should be clear what the most important (or at least the most drastic) action is. A Hang Up button, although used infrequently (once per call, to be exact), should be emphasized.
It can be good practice to cluster similar or related controls into zones on the interface, e.g. controls for printing on the right, for exporting on the left. Avoid putting “ejector seat” (undoable) controls next to other positive controls. Having Ok next to Cancel is not good practice.
Like all choices when designing devices, arbitrary choices about controls are an anathema to good design. The best technology, the coolest features, can be ruined by poor controls.
In the beginning is the concept.
All devices start with an idea. It might not be much of an idea, but you have to start somewhere. However, most ideas are bad. You can make a device from a bad concept, but usually not a great device. Bad ideas, however, can sometimes be refined into good concepts with effort and the ability to tell when the initial idea is bad. This is often much harder than it seems. Many very smart people have chased bad ideas for years and decades.
It doesn’t necessarily matter if the idea for a device has been done, although it helps if the idea was done poorly before. Recreating a successful device is harder than resurrecting a good idea that was executed poorly. (The poor execution could be caused by any number of factors, including the product vision being ahead of the technology to execute it well. This is not necessarily bad.)
In general, ideas come from two main places: creating something entirely new, or combining existing pieces into a new whole. The former is so rare it might not even be worth discussing. Those kinds of ideas usually only exist in philosophy, science, or the arts, not in product design. Product design is an applied art; it relies on not having to recreate the wheel every time, the wheel in this case being components, materials, and the tools and factories used to create the device. Even if you’re using a piece of new technology in the device (and unique technology itself is uncommon), it is usually surrounded by “old” technology.
Ideas are easy to come by. As a theoretical construct, it’s easy to convince yourself it’s great. But until it’s considered, measured against other ideas, sketched, prototyped, refined, and built, it’s difficult to tell if it is worth pursuing. “No ideas but in things,” said William Carlos Williams. Sometimes, even after design and development, a device’s true potential isn’t known until it’s in the marketplace and people use it. But without any of these steps, an idea is just that: an idea. And, unless patented, it is practically worthless. The execution of a concept is (almost) everything.
Sometimes it is almost impossible to tell if a device concept is a bad one at first. But there are warning signs:
Of course, there are examples that overcome all of these warning signs, and some of these cannot be determined when you first have an idea, only after examining it for a while.
Device concepts are the most interesting when they use a new technology to solve an old problem or use old technologies to solve new problems.
