A Google Forms grid groups several row questions under one shared set of column choices. Use a multiple-choice grid when each row needs one answer, and a checkbox grid when a row may need several. Then decide separately whether every row must be answered and whether a column may be reused.
Those decisions have different effects. A participant might need to give the same rating to several topics, so limiting a rating column to one row would change the meaning of the survey. A compact table is useful only when it preserves the answers you need.
This guide builds two original examples: a topic-understanding survey and a workshop-availability question. The examples are design plans, not records from a live Google Forms test.
Last verified: September 22, 2026
Start with the meaning of a row and a column
Google's Forms API defines a grid as separate row questions sharing column choices. Its choice types distinguish a single radio-button selection from multiple checkbox selections. Those definitions provide a clear basis for the distinction between the two grid types. Google Forms API Grid and ChoiceType definitions
In a topic-understanding survey, the rows might be “Finding the correct procedure,” “Preparing a handover,” and “Recording the next action.” The columns describe the same level of understanding for each topic.
In an availability question, the rows might be workshop topics and the columns might be time slots. Several time slots may be suitable for the same workshop, so the answer structure differs even though both questions look like tables.
Before opening the editor, finish this sentence: “For each row, I need the participant to choose…” If the answer varies by row, you may not have a good candidate for a shared grid. Separate questions can be easier to understand than a table containing unrelated tasks.
A note about inconsistent help wording
The current Google question-type help page uses wording that does not consistently distinguish single and multiple selections in its grid descriptions. The rule-help page also contains mixed wording around checkbox grids. I have used the API's explicit radio-versus-checkbox distinction rather than repeating those ambiguous sentences.
This is a documentation comparison, not a claim that I tested the editor in a Google account. Check the actual participant view after selecting the type, especially when copying an older form or following screenshots from another interface version.
You do not need to use the API to build the examples. It is cited here to explain the underlying answer model when the help prose is unclear.
Example 1: one understanding answer per topic
Suppose a coordinator wants feedback on three topics after a practical session. Use one shared question stem, such as: “How clearly could you explain each topic to a colleague now?”
The working design might be:
| Row topic | Shared column choices |
|---|---|
| Finding the correct procedure | Not clear yet; partly clear; clear; very clear; did not attend this topic |
| Preparing a handover | The same choices |
| Recording the next action | The same choices |
Choose a multiple-choice grid because each topic should receive one answer. Keep the response categories consistent from row to row. The participant should not need to reinterpret the columns halfway down the table.
Do not apply a one-use-per-column restriction to this example. Someone might feel “clear” about all three topics. Preventing that combination would force an artificial difference between topics rather than record the participant's judgment.
The answer is a self-assessment, not an observed demonstration of skill. If you need evidence that someone can perform the procedure, use a suitable assessment separately. A grid changes the layout of the questions; it does not make the answers more objective.
For fuller guidance on labels and distributions, see the five-point survey scale guide. The main concern here is whether the same set of choices makes sense for every row.
Example 2: several possible times per workshop
Now suppose an organizer is gathering availability before deciding a timetable. The rows are “Introduction,” “Practice session,” and “Questions clinic.” Columns are a few clearly labeled time slots on specified dates.
Use a checkbox grid if a person may select more than one suitable slot for a workshop. Write an instruction such as: “For each workshop, select every listed time you could attend.”
Avoid combining different time zones or vague labels such as “Morning” without a date. The grid should not require the participant to infer which week or location applies. If the labels become too long to read together, split the question rather than abbreviating away essential context.
Decide how to represent no availability. You might provide a “None of these times” option or make rows optional with a clear explanation. If you include a none option alongside time choices, tell respondents not to combine them, then test whether the form's behavior matches the intended rule. Do not assume the wording creates an automatic exclusivity constraint.
This collects availability. It does not reserve a seat, prevent another person choosing the same time, or confirm a booking. A column limit within one response is not a shared capacity limit across all participants.
If you only need one list of suitable times, ordinary checkboxes may be simpler. The multiple-answer question guide covers that option without the additional row structure.
Configure the Google grid and review each constraint
Add a question, choose the grid type, enter the row labels, and add the shared column labels. Then inspect the row-required and column-limit settings. Google documents Require a response in each row, Limit to one response per column, and row-order shuffling among its grid controls. Google's grid rule instructions
Treat these as separate choices:
| Setting decision | What you are deciding | Example where it matters |
|---|---|---|
| Single or multiple selections in a row | How many answers represent that row | One understanding rating versus several available times |
| A response required in every row | Whether any row may remain unanswered | Topics some participants did not attend |
| A column used by only one row | Whether different rows may share a choice | Repeated ratings versus a deliberately unique assignment |
| Row order | Whether the order carries meaning | A procedure whose stages should remain in sequence |
Do not enable every available control by default. Each one should support an answer requirement you can explain. If the requirement is unclear, record an example of a valid completed grid before deciding the settings.
Required rows and not-applicable answers
A required row can be reasonable when everyone can give a meaningful answer. Problems arise when a participant must rate something they did not experience and has no honest response available.
For the topic example, “Did not attend this topic” serves a different purpose from a middle rating. Keep it separate in your analysis. Otherwise, the result may imply moderate understanding where you actually have no self-assessment.
Choose the wording according to the reason a row may not apply. “Not applicable,” “Did not attend,” and “Have not used this” are not interchangeable in every survey. A short explanation can prevent respondents from using the option as a substitute for uncertainty about the question itself.
There is also an interaction with column uniqueness. If several rows may legitimately be not applicable, a one-use-per-column limit conflicts with that requirement. Test the combination before deciding the grid is ready.
When you cannot offer a sensible shared exception option, consider separate questions. That gives each topic its own context and avoids using one vague column to cover several unrelated situations.
Check that the requested combination is possible
A grid can look tidy while making the intended completion impossible. For a single-choice grid that requires every row and permits each column only once, there must be enough columns to accommodate the rows. This follows from the proposed rules, not from a special limit on the number of questions.
For example, requiring four separate rows to use three columns without reuse leaves no possible completed answer. More subtly, a valid participant may need the same “not applicable” column twice even when the total numbers look sufficient.
Before release, draw one normal answer and one awkward but legitimate answer on paper. If the rules reject either, decide whether the data requirement or the settings need to change. Do not tell participants to select a false answer simply to move forward.
Unique-column behavior is sometimes useful for an intentional assignment exercise. However, do not casually describe an ordinary rating grid as a ranking question. Rating several items independently and allocating distinct positions are different requests.
Make the grid readable on a phone
The desktop editor gives you room that a participant may not have. Test the actual form on a narrow screen, with the wording you intend to publish. A diagram of the planned grid cannot establish that the final interface is usable.
Ask a tester to identify the row and column of a selected answer without help. Watch for labels that wrap into several lines, ambiguous abbreviations, and a table so wide that the relationship between a choice and its heading is hard to follow.
A useful revision order is:
- Remove any row that does not support a decision.
- Replace long row labels with concise, distinct wording.
- Keep essential context in the question's introduction.
- Reduce unnecessary choices without hiding meaningful differences.
- Split the grid into smaller groups or separate questions when needed.
Do not shorten “Not applicable” into an unfamiliar abbreviation solely to fit the table. Saving space is less valuable than preserving the answer's meaning. If there is only one item to select from a long list, the dropdown guide describes a different structure that may fit better.
Use a concrete pre-publication test sheet
Write expected outcomes before trying the form. The following cases cover the two example designs, but you should adapt them to your actual settings.
| Case | Intended result | Reason |
|---|---|---|
| Select a second rating in the same single-choice row | Only one remains selected | One judgment per topic |
| Give the same rating to two different topics | Allowed in the rating example | Equal judgments are legitimate |
| Select two suitable times in one checkbox row | Both remain selected | Several slots may be possible |
| Leave a required row blank | Completion requires resolving that row | The row-required setting is intentional |
| Mark two topics as not attended | Allowed in the topic example | Nonattendance may affect several topics |
| Open the form on a phone | Labels and selections remain understandable | Readability is part of the task |
These are intended outcomes, not recorded Google test results. Fill in an observed-result column after checking your form. If an error appears, note which row or constraint caused it rather than recording only “submission failed.”
For other rule types and error-testing principles, see the response-validation guide. Grid constraints should be tested alongside the rest of the form, including a valid completion path.
Read the results according to the answer structure
Keep a separate interpretation for each row. In the topic example, compare the distribution of answers for each topic, and retain “did not attend” as its own category. Do not silently turn it into a midpoint or zero.
For the availability example, one person may select several times. The count of selected cells is therefore not the number of participants. A popular column indicates reported availability, not a confirmed attendance list.
Before collecting real responses, decide which report the organizer needs. If you cannot explain what a selected cell will mean in that report, revise the question while it is still easy to change. This prevents a convenient layout from dictating a misleading analysis later.
FORMLOVA matrices have different required behavior
FORMLOVA's current matrix field defines rows, columns, and an option for multiple selections within a row. Its renderer uses row-by-row cards on narrow screens and a table on wider screens. These implementation details support a similar visual task, but do not establish feature parity with Google Forms.
In particular, FORMLOVA's current required-matrix validation checks that at least one answer exists. It does not require an answer in every row. The current matrix schema also does not provide an equivalent column-uniqueness setting. Do not transfer Google's setting names into a FORMLOVA requirement and assume the same behavior.
If every item must be answered, separate required questions may fit the requirement better than the current matrix. Review the draft and test the actual response path before publishing.
You could ask an AI client connected to FORMLOVA:
Draft an unpublished feedback form for these three topics. Each topic needs one clear answer, including a did-not-attend option. Compare a small matrix with separate required questions, and explain the required-answer behavior before I choose.
For the broader choice of how to collect and manage responses, return to the Google Forms, Sheets, and Apps Script operations guide.
Disclosure and Verification
I develop FORMLOVA. I checked the Google help pages, the Forms API Grid and ChoiceType definitions, and FORMLOVA's matrix schema, renderer, and validator on September 22, 2026. I did not configure a live Google grid or submit a response in a Google account while preparing this article. The examples and test outcomes are original design recommendations to verify in the actual form.
