After watching the livestreams of Crew-1 and Crew-2 missions, I was curious about the certification the capsule had to go through, especially with the new control panels which seem to be largely touchscreens.

Of course, by now touchscreens are a mature technology. Using a large screen can possibly convey more information than an array of physical buttons and readouts of the same size. It also makes the whole solution smaller (and indeed, the Dragon capsule is roomier than Soyuz, for example). However, touchscreens in industrial and automotive environments have also received criticisms such as: while driving a car it is easier to reach and feel for a button than find it on a touchscreen.

It seems to me that touchscreens present another issue: you can't reliably tell whether your input has been registered or not. With a physical button, you always know if you pressed it or not. With a touchscreen, it can be more ambiguous.

My question is: surely there must have been some tests or certification done by NASA to ensure controls works as expected. Since the control panel of Dragon used such a different setup, were old standards applied or were new ones developed? Are those standards available to look through?

  • 1
    $\begingroup$ Note that there are buttons underneath the touchscreens; see, for example, here. $\endgroup$ Commented May 12, 2021 at 20:50
  • $\begingroup$ @SteveMelnikoff I also noticed that and that was what in part inspired the question. I thought that maybe there were some interface requirements. $\endgroup$
    – Mu3
    Commented May 13, 2021 at 7:15
  • 5
    $\begingroup$ There is a Stack Exchange network site devoted to just this one topic, the User Experience Stack Exchange, UX for short. I suspect all of us have become amateur experts in UX because all of us have, at multiple points in our lives, been subjected to using terribly designed devices, using terribly designed websites, using terribly designed programs, and using terribly designed whatever. $\endgroup$ Commented May 13, 2021 at 11:37
  • 1
    $\begingroup$ Loosely related: this article (and some later ones) over on the Stack Overflow blog. $\endgroup$ Commented May 13, 2021 at 12:52
  • $\begingroup$ What if you had to operate the touchscreen with gloves on, for potentially relevant example: in an EVA suit? I know I can't operate my phone with regular winter gloves on. I imagine it'd be even worse in gloves designed to be pressurized for spaceflight. (I do have a pair of gloves with special metallic fiber in the fingertips specifically for use with touchscreens, but I'm not sure whether this could be adapted for space-gloves.) Unless the screens are the old pressure-sensitive ones rather than capacitive? $\endgroup$ Commented May 13, 2021 at 20:44

2 Answers 2


As I am not privy to the contractual interactions between NASA and SpaceX, I cannot say with an absolute certainty that NASA and SpaceX had astronauts, pilots, etc. evaluate the vehicle beforehand with multiple simulators and used the Cooper-Harper rating scale to evaluate the quality of the human-machine interface and the controllability of the vehicle.

On the other hand, that I am not privy to this information means I can answer this question. (I could not do so if I was privy to this information.) I am very sure that this is exactly what was done. For one thing, the Cooper-Harper rating scale has been used for over half a century. For another, during the Dragon Demonstration Mission 2 (the first Dragon mission that involved people who were in the vehicle; Demo One was uncrewed), the crew said that the vehicle responded exactly as they had been trained in simulators.

The Cooper-Harper rating scale rates various qualities of a vehicle on a one to ten scale. The scale was published in the late 1950s, so it is old. It's older than the concept of a perfect ten, because a ten on the Cooper-Harper rating scale means absolutely awful. A one on this scale is perfect. From the wikipedia article, here's a flowchart for this scale:

Cooper-Harper Rating Scale. See text.

This scale has three major decision points, and based on the answers to these, several minor decision points. The first major decision point is "is the vehicle controllable?" If the answer is "NO", that's a perfectly bad ten. There are no minor decision points for a NO.

The next major decision point asks about the tolerability of the workload. If the workload is not tolerable, the score is a nine, eight, or seven, depending on exactly how bad the workload is. The X-15 passed the controllability test but failed the workload test. People died as a result.

If the vehicle passes the controllability and workload tests, the next major decision point asks whether the vehicle needs improvement. If it does, this results in a score of six, five, or four, depending on how much improvement is needed. If the vehicle passes all three major decision points, the score is a three, two, or one, depending on how much the pilot has to compensate for vehicle randomness.

The scale has been extended beyond ability to pilot a vehicle. The extensions retain the upside-down nature of the Cooper-Harper scale, where a one means perfectly awesome and a ten mean perfectly awful.

  • 1
    $\begingroup$ Now that I think of having a more abstract framework is a good way of handling this: run simulations and see what score you get. After all you can't avoid risk altogether. $\endgroup$
    – Mu3
    Commented May 12, 2021 at 13:46
  • 4
    $\begingroup$ @Mu3 The score is upgraded or downgraded after vehicle tests with people in the vehicle. Those crewed tests count for a whole lot more than do simulation runs. Well, at least nominal simulation runs. The nice thing about simulations is that the crew can be subjected to extremely nasty off-nominal situations, and without actually killing the crew. While the crew might die in the simulation, later in the day they do get to go home to their families. The Cooper-Harper rating for those scenarios in which the crew are subjected to simulated death is rather high. $\endgroup$ Commented May 12, 2021 at 14:10

Sorry, I can't truly answer the main question, as I don't have access to that information. This is more of a general answer to OP's statement:

you can't reliably tell whether your input has been registered or not. With a physical button, you always know if you pressed it or not. With a touchscreen, it can be more ambiguous.

In fact, the same can be true of traditional keypad/physical switch interfaces. Yes if you flip a toggle up or down it is unambiguous. But a pushbutton? Not at all, unless it lights up when activated (common in some systems for exactly the reasons enumerated here, but not in typical consumer products).

There are some different types of touchscreens in terms of hardware, but that is the easy part - I suspect that being usable with both gloves and bare fingers and other basic physical issues determined the hardware technology used.

But the big issue with touchscreens is the software. I have used a ton of absolutely horrible touchscreen interfaces. I have used some slick-but-mediocre (typical smartphones come to mind) touchscreen interfaces. And occasionally I have used some really excellent ones. There are a number of different things that can be done to make a touchscreen interface (and user interfaces in general) suitable for this type of high-stress, high-risk usage. I am not an expert, but I have been a programmer for many years, and here are some things that I expect are considered in the design of such a system:

  • Immediate and clear feedback. There should be very quick visual feedback. Audible is useful too, but typical little clicks (simulated key press) and beeps are not necessarily going to be heard over the noise of the craft, especially if there are alarms, radio traffic, etc. This can take the form of changing the color (e.g., inverting) of the "button" being pressed or some other feedback (e.g., numbers appearing immediately in the expected location when pressing a virtual numeric keypad). This is often not done well on consumer products, but those products are not critical systems like spacecraft.
  • Confirmation of critical functions. If you press a button that does something, rather than simply provide information, confirmation with a separate touch should always be required. That press should be in a different area of the screen so that you can't accidentally press twice in a spot and have the parachutes deploy early (or whatever). Again, I see this a lot in consumer products - e.g., a menu on the screen and the confirmation box always in the same location, so if you press a menu button that happens to be where the confirmation box will appear you can easily confirm without intending to do so.
  • Clear and contrasting colors. Colors should be meaningful (think green good, red bad) and should contrast (light blue on dark blue may make a graphic designer happy, but it makes things hard to read). Colors should be consistent.
  • Clear delineation of buttons vs. text vs. graphics, etc. I find this to be a very common problem on smartphones - graphic designers seem to love having everything all flow together, which is aesthetically pleasing but can make it hard to figure out exactly where to press.
  • Unambiguous usage for anything beyond a straight "button press". Swiping left or right or up or down, holding buttons for an extended time to do a special function, and other fancy UI tricks are interesting. But they are hard to control (e.g., a lot of "butt calls" are "swipes that turned into accidental calls") and can be confusing, especially in stressful situations.

The end result is that the touchscreen interface may not be as slick as Android or iOS, but can still provide cost and space savings over traditional hardware.

  • 2
    $\begingroup$ Does this address the question of what standards NASA used at all? $\endgroup$ Commented May 13, 2021 at 1:04
  • 2
    $\begingroup$ @Mu3 Of course NASA audits SpaceX's software. NASA requires that manufacturers of vehicles that go to the ISS to have an in-house verification and validation team that presents their results to NASA. NASA also requires that manufacturers of vehicles that go to the ISS must hire an independent verification and validation (IV&V) contractor that presents results to NASA. NASA also has its own IV&V teams that not only evaluate with software but also evaluate the IV&V contractor. There are other groups at NASA who also evaluate the SpaceX software. $\endgroup$ Commented May 13, 2021 at 11:06
  • 1
    $\begingroup$ The general public cannot see the SpaceX code, but NASA can and does demand that they be able to see it. NASA also agrees not to share that code with the general public. NASA also demands that NASA employees / contractors who see that code must not disclose it to the public (or even worse, to competing companies or foreign governments). There are things called nondisclosure agreements (NDAs) and organizational conflict of interest statements (OCIs) that while not signed in blood come very close to being signed in blood. $\endgroup$ Commented May 13, 2021 at 11:06
  • 1
    $\begingroup$ Bad software has killed people by giving cancer patients massive overdoses of radiation intended to kill cancerous cells (but not humans). The software on the Therac-25 sometimes killed humans. Bad software resulted in the failure of the initial launch of the Ariane 5. Bad software has resulted in the failure of multiple Mars missions. It is very easy to get things wrong with regard to safety critical / mission critical software, and this means lots of oversight and vigilance are required to ensure that things are done right rather than wrong. $\endgroup$ Commented May 13, 2021 at 11:19
  • 1
    $\begingroup$ A lot of pushbuttons make a tactile click when pressed. You can tell when you pressed them - unless the craft is shaking quite violently - which I'm sure it is! $\endgroup$ Commented Apr 21, 2023 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.