Month: October 2026

First, a quick shout-out to SuzanneR on the Content + UX Slack for catching the fact that The Interconnected was displaying my name incorrectly. Yeah. Since I was writing about name policing, I’m feeling a bit silly for not checking before hitting “publish”. Call it a bad design decision 😉

---

This is a story about team dynamics and things that you may be able to look for in your own teams when the pressure is high. It’s also a story about the realities of research, and what to do when it fails to be the black-and-white solution we want it to be.

There’s a tale that’s gone around for years in science fiction writing circles about a famous author who got about 2/3 of the way through a new book draft and called their editor and said, “I’m sorry. This book is awful. It’s fallen apart. There’s no way I can save it.”

The editor replied, “…You’re about two thirds of the way through it?”

The author said, “Yes, how did you know?”

The editor responded “Because you call me at this point in every one of your books and tell me the same thing. You’ll be fine.”

Mary Robinette Kowal retold this story during one of her short story classes this past weekend, and then she added that she was thrilled to find out that this condition of feeling like everything is falling apart when you’re past the halfway point has a name. Astronauts call it the third quarter phenomenon.

The phenomenon (or problem, depending on the author) goes like this:

• One or more people go into isolation for a fixed period of time.
• The group is productive through the first half of the project, with productivity peaking at the midpoint of the mission.
• During the third quarter of the mission, productivity suddenly falls off, people suddenly stop getting along, and chaos ensues.
• Generally, by the beginning of the fourth quarter of time everyone gets their act together, productivity rises again, and the project completes as planned.

It is worth immediately noting that the folks who have written about this topic ^[1]Coping During Conventinal Submarine Missions: Evidence of a Third Quarter Phenomenon? by Charles H. Van Wijk for theJournal of Human Performance in Extreme Environments, The Psychology of Time in … Continue reading are the first to point out that surveys of the literature about different isolated missions including submarines, space missions for both US astronauts and Russian cosmonauts, and research missions in Antarctica, are inconclusive over whether this phenomenon exists. There are definitely projects that fit the model, but there are also definitely projects that don’t fit the model.

Writing, especially if one is writing a book one has already sold, would definitely appear to match the phenomenon’s pattern of “isolation, fixed period of time”. The fact that the “famous author hits wall” story is so popular indicates that this isn’t an isolated phenomenon either. (Rarely does anyone bother to repeat a story that doesn’t resonate, especially authors.)  This means that the phenomenon may not require people to be physically isolated the way that they are in outer space. It may be enough to say that any project that constricts your free time for a set time period could experience a drop-off in productivity, mental health, and cohesion as a team.

Certainly if asked to make a list, I could describe quite a number of projects in Enterprise software development that seemed isolating  (no, not that Enterprise, though that one would definitely qualify) with tight, sometimes unreachable time constraints. And yes, they did experience issues with productivity, dissonance, and mental health issues.

On the other hand, the lack of a firm conclusion on whether the condition exists points to other possibilities. Why Q3 Always Breaks: The Hidden Pattern Behind Third Quarter Failures at timeliny posits that the problem isn’t a psychological phenomenon, but rather “a predictable failure mode with identifiable causes and preventable triggers” ^[2]At least it is if your project calendar and the Gregorian calendar line up, and you’re in the Northern hemisphere such that people are on their summer vacations during Q3 which you clearly … Continue reading at least, for Enterprise software projects.

It’s certainly possible that for every one author who has trouble wrestling themselves through the murky middle of a story there may be two or three that didn’t. ^[3]Conversely, there for every author that swept right through the middle with no issues, there may be two or three that didn’t! We don’t know, because it hasn’t been studied.

What we do know is that we can’t say that the problem consistently occurs, even for the astronauts, sailors, and researchers for whom the phenomenon occurs.

We also know, according to NASA, anyway, how to combat it. Megan Finnerty of the USA Today Network writes in From Astronauts: 5 ways of coping with anxiety, loneliness:

1. Pursue meaningful work.
2. Communicate with loved ones.
3. Get exercise.
4. Make meals matter.
5. Keep reminders of a loved one nearby.

Arguably, these are all examples of best practices for our mental health anyway. ^[4]Arguably, tech workers — at least those below the C level — have little control over #1, pursue meaningful work, even if we wanted to. If we’re doing this research because (as service designers or as managers) we are personally responsible for the success of a team that is working on a project with long, potentially isolating hours and a fixed, possibly aggressive timeline, then those five tips may be the only thing we need to move forward. And if they aren’t, a dive into the deeper research at the Translational Research Institute for Space Health may provide the rest of what we need.

If we’re doing this research in the process of developing a new product or platform, though, we need to be very mindful of the part where the data drawn by the previous researchers was inconclusive. In this example, we’re doing a literature review, so the quality of the conclusions drawn by the researchers we’re reviewing is critical to our conclusions being valid. But “inconclusive results” can happen in any kind of study, and knowing how to professionally handle those results is key in maintaining respect for UX research.

What are safe next-steps we designers can make when the research we’re handed doesn’t answer the question we asked?

We could investigate whether our sample size is too small. If every submarine mission around the world was gathering data, we’d have a better idea of whether, for submarines, Third Quarter Phenomenon was a concern. Similarly the missions that didn’t experience Third Quarter Phenomenon could tip us off to differences in management or structure that prevented it, and suggest ways we can ensure projects are more consistently successful.

But we probably ^[5]Definitely won’t get time to do that research, because this is 2026 in UX Design, not 1660 CE at the Royal Society.

We could use recommendations provided by the researchers themselves. As designers we don’t necessarily want to take someone else’s research as automatically valid, but it’s NASA, and they’re known to be a reliable source.  Starting with someone else’s deeply-researched recommendations is always a good idea, so long as we wrap those recommendations in the context of where they came from, why they might (or might not) apply to our project, and what the risks are.

A third option is to shelve the data we received in this round of research and go back to our initial question set, checking to see if our research approach contains biases or incorrect assumptions that would cause our results to be invalid or unclear. Once again, we probably ^[6]Definitely won’t get time to do a second round of research, so there’s a good chance we’re going to have to guess.

And that takes us to our last two options: ignore the whole question, or guess.

If having this data was a throwaway, one-off, not-critical-to-the-happy-path question that we added into the research because this was the opportunity to get the answer, we may decide “heck with it, we didn’t need it anyway”, write up our conclusions (that there were no conclusions) and go on our merry way.

On the other hand, if this actually is critical research to have, our best bet is likely to be to dive into the research as best we can and then, with a great big caveat about inconclusive data wrapped around it, guess. While this isn’t ideal, it will still be a much more educated guess than if we had guessed with no research at all, and most likely there will be something about the initial data set that we can still use.

So: the Third Quarter Phenomenon describes the absolute funk your team of isolated hard-working people go through when they pass the halfway point of a project and suddenly can’t cope. Not every team in a truly isolated fixed-timeframe project experiences it, and to date we don’t know why. We think authors experience it, but we don’t have metrics to prove it. Development teams might also experience it, or that might just be bad planning.

At the surface level, we can take lessons on how to manage ourselves and/or our teams during a third-quarter funk using recommendations that come from NASA’s astronauts.

At a deeper level, we can use this information as an example of what happens when we research something and the results come back inconclusive, leaving us with questions both about the quality of the research study and about how to proceed. The most important point is to communicate what we know and what we don’t know, so that those who come after us understand the risks of the data we used.

 

If I had a nickel for every time I couldn’t figure out whether there would be chicken on my chicken caesar salad, I would have two nickels. Which isn’t a lot — but it’s funny that it’s happened twice.

---

---

---

I do a lot of food shopping online. It always comes with mixed results because almost all of these systems are asking humans to choose how to list their own products in vast systems that have no idea what products are or why they might have different fields. So I don’t blame the people adding the salad to the menu so much as I do the menu system itself. ^[1]Don’t get me started on the checkboxes used for “select up to one” scenarios. That’s what radio buttons are for, people!

No, this is more about assumptions. When we’re shopping for salad, we expect that a caesar salad would have no chicken, and a chicken caesar salad would have chicken. We don’t expect either of them to have shrimp, because that would be a shrimp caesar salad.

But what happens when you want a plain caesar salad (no protein addition whatsoever) but the restaurant only lists the grilled chicken salad? There’s no option that says “no chicken”, but the options to “add chicken” seem to imply that there isn’t chicken there to begin with. Then again, it could be adding chicken to the chicken.

The top example is, in fact, adding chicken to the chicken. The bottom example should be listed as a caesar salad because if you don’t add chicken to your chicken caesar salad you get no chicken.

In both cases, the title “chicken caesar salad” by itself is harmless, as is “add chicken”. It’s in the context where they’re put together but no explanation is given for what you will actually get that matters.

I’m going to write about “bad” design.

When I write about “bad” design, I want you all to understand that a design that’s bad for me might be a perfectly good design for a different user. It might even be the ideal design. It’s about the context.

For example, I recently applied to speak at a conference. The form asked me for the speaker’s name.

A half a dozen years ago, I stopped capitalizing my name. Why? Because it felt right. Names are labels, my label needed to change to match its contents, so I stopped capitalizing it.

Except not every website has the flexibility to handle a lowercase name, apparently.

The form won’t let me put my name in lowercase! But when it’s not in lowercase, it’s not my name! I know how it should be capitalized! Because it’s my name!

I won’t deny that having had my name misspelled and mispronounced as Ann most of my life ^[1]Yes they have different pronunciations, at least in the Delaware Valley, don’t @ me. has wrapped a bit of bitterness around my soul that my choice of capitalization has not eradicated, but instead fed as if it was Miracle Grow.

That same bitterness has led me to defend users’ names from overthinking designers and developers on many occasions. There’s a reason why we have a list of Falsehoods Programmers Believe About Names, and there’s a reason why I now use it as a checklist of experiences instead of a warning.

(One through eight, seventeen obviously, twenty five, thirty one — shout out to everyone whose last name is “beaver” — and thirty nine, so far.)

But when we critique, we have to recognize that sometimes a “bad” design is being viewed in the wrong context.

Not always, and if you bring me a design where you’re putting yellow text on white (or any other inaccessible color combination LOOKING AT YOU SHAMPOO BOTTLE DESIGNERS) you’re still going to hear from me about it.

But sometimes.

The name on this form is the one automatically fed into the conference program. That’s good! That means the organizers don’t have to take the data from the proposals form and retype it into the conference program form. They can’t mess up the spelling during the retyping, they can’t miscapitalize, they can’t get the spacing wrong… the speaker is the only one responsible for the way the speaker’s name displays.

But this poses a problem: what if the speaker who would normally write their name as Anne Gibson entered anne gibson because they were in a hurry and it’s just the proposal form, so someone will fix it later when they write up the conference program?

There is no “someone to fix it later”, because that step doesn’t exist. When a bunch of speakers half-ass their own names, the programs look less professional, and the speakers get upset at the way their names are presented.

From the standpoint of conference organizers, having an enforced name format ensures  consistency, avoided mistakes, and programs that are visually less jarring.

Do I think there should be better instructions on the intake field? Yes, yes I do.

Do I think that ^[2]outside of “user would like that context” this is a workable solution to the problem? Actually, yes I do. That doesn’t make the Falsehoods Programmers Believe About Names any less true; now that the constraints on the designers are visible to me, I can understand the decision.

The tech support rep I complained to (who explained the constraints) used an override to allow me to (un)capitalize my name correctly. Presumably, everyone whose name is outside the bounds of “beliefs about names” can still get their name displayed correctly if they contact support.

The key is the context. With only the context of the user in mind, this looks like a bad design. Within the context of the conference program publication, it’s a better design. ^[3]If I were the designer I would question whether the cost pressure put on the support team was worth the extra guardrails on the field.  But I’m not, and that’s the point. For all I know, … Continue reading

When I write about “bad” design , I don’t know if my context is the only context. I’m going to anonymize the designs as much as possible. These posts aren’t about shaming a company and its designers. They are about saying “in this context, this choice can backfire and here’s how”.

I hope that everyone who reads these posts will keep that context in mind 🙂 ^[4]ha! see what I did there?