I see a lot of posts on this site with titles which read as statements or as a classification of the problem detailed in the body of the post.

I've edited some titles which would be better phrased as questions and was about to change another when I noticed this edit and the reason given being readability.

Is it better to ask a question in the title or classify the problem?


4 Answers 4


Unfortunately this is one of these "it depends" answers which is leading into a discussion instead of a real answer. But on Meta, we're OK with that.

For starters, if you are in any tech industry and are provided with an error message like "The UPSA failed to provision due to lack of free memory" then adding How do I solve error message doesn't add any value. It's actually worse and might make your real issue be less clear. The error message itself makes it perfectly valid as a question because of its keyword failed.

But UX professionals on UX.SE don't really do implementation stuff where you get error messages. In fact it's off-topic, meaning the question will be closed pretty soon. Our topics have a more academic approach, even if we're in the industry there is always a nudge of subjectiveness to it all that sometimes can and sometimes can't be answered in a go to X, find button Y, use a administrator account to.. and these type of crystal clear answers. Our answers are more reasoning. And so are our questions if one take a look at the questions we get here.

This all means that our questions are sometimes more of a thesis theory needed to be proven than an actual simple How do I type of question.

So what is correct? As always in the UX-field: You should title (phrase) the question in such a way which is the most easiest to understand, let go of ambiguity (if possible) and use the question mark if, and only if, it makes the question more understandable. If that means classifying the problem or make the title a statement is up to the consumers as in the target audience (our community members).

  • 1
    Given that the edit in question was my edit, I definitely agree with your answer, especially the final paragraph.
    – Alan
    Commented Jun 15, 2015 at 12:41
  • The problem for me - and it may be entirely personal - is that I read "statement" titles and find myself converting them into questions in my head to clarify my own question: "What is this person asking?" It seems to me to increase the cognitive load. I'm curious about other people's experiences. Commented Jun 22, 2015 at 13:49

I'm glad you asked this question as I've pondered it too. It's also an interesting UX question on its own right.

I've resolved this from a UX approach by asking myself "what would users most likely search for to find this answer?"

That may not resolve the issue for everyone, but for me it gets to the pith of the issue because:

  • It helps promote SE's broader role as an expert, current, subject-focused Q+A repository for the global internet community (better search compliance helps SE audience development).
  • Users tend to be habitually economical with search terms so thinking about search terms helps maximize communicability in the minimum number of words (aka pithiness)
  • The focus on pithiness may seem unnecessary, but from a UX perspective I think it also helps the site because it promotes scannability of questions for members who are volunteering time to read and answer them.

Again, this approach may not be for everyone but I've found it helpful after thinking about the issue also.

  • +1 for the likely search string approach. Really good user approach on the topic. Commented Jun 29, 2015 at 21:22

Having failed to find an answer on meta.ux.stackexchange.com, I've found an answer here on meta.stackexchange.com. However, that is cited in a later discussion as out-of-date and a poor example.

I'm not convinced by this answer, which features a particularly poor example of heatmaps. These merely show how people read search results which is offered as evidence to support the writer's view. There is no test of the two data sets - titles as questions vs. titles as statements - to allow a comparison.

  • +1 for answering your own question and also providing great references
    – tohster
    Commented Jun 21, 2015 at 18:40

In general (on all SE sites) I find that it's sometimes just plain difficult to word everything as a question and--even when it can be done--the title gets much wordier than a simple statement.

But that's just a preference. I can't say it's universally better one way or the other.

Random commentary on the first 5 titles currently out there:

Is the folder structure dying?

+1 for formatting as a question. It's enticing...slightly controversial. I think it being formatted as a question is a selling point for this one.

Jump from print into UX

+1 for a simple statement. It's not a question, but we can probably assume what the question(s) will be related to it. To word it as a question seems to just add superfluous words: How can I jump from print design into UX design? Not bad, just wordier.

Is it a good idea to redirect expected page name misspellings/typos for critical web pages?

+1 for question format. It's long, but seems appropriate for the specificity of the situation.

How can I pictorially show an option is unavailable for a time?

See previous. Seems to work well.

Using 2 tabs on a page: one for filter, and one for content?

Could this one be rewritten as a better question? Perhaps, but if you dive into the actual question, it seems that this is one of those "there's a question here, but that's actually part of the question: What question do I need to be asking?" Maybe this would have been better as a statement: Dealing with complex tabs and filter arrangement.

So, in summary: Uh, my conclusion is that, uh...I could go either way. It just seems that some question titles work best as questions, but some others are fine left as statements or fragments.

One size doesn't seem to fit all when it comes to question titles.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .