Incident Form

[Image]

This is an incident reporting experience that shows up when something has already broken and someone needs help. Users are trying to explain a problem clearly so it can be understood and acted on without back and forth. For the business, this moment supports reliable intake, prioritization, and resolution of issues that affect teams and systems.

We tested ServiceNow’s incident form to see how people interpret the fields, make decisions, and move through the reporting process. Participants were asked to imagine encountering an issue at work and submitting an incident using the form. The test focused on appeal, comprehension, success, sentiment, and effort to surface how clearly the form communicates expectations, how confident users feel completing it, and where momentum slows.

This type of experience often breaks down not because people are lost, but because they hesitate. Small moments of uncertainty can add friction, delay reporting, or reduce the quality of information submitted. Testing at this level helps teams see where confidence holds and where it softens, so decisions can be made with a clearer understanding of how structure, clarity, and cognitive load shape real-world behavior.

---

User Needs & Business Goals

This experience balances the need for accuracy and completeness with the user’s need to report an issue without overthinking every detail. Users want to feel confident they’re providing the right information, while the business aims to capture enough clarity to route, prioritize, and resolve incidents efficiently.

Audience

This concept was tested with working professionals in a B2B context, primarily familiar with internal IT or service desk tools. Participants reviewed a ServiceNow incident form and were asked to imagine reporting a problem they had encountered at work, then assess how clear, usable, and manageable the form felt in that moment.

User Needs

When something breaks, users are focused on explaining the issue quickly without making mistakes.

• The experience should feel familiar and trustworthy so users believe the issue will be taken seriously (credible).

• The form should be easy to move through without confusion or unnecessary effort (usable).

• Required information should be easy to locate and understand as users scan the form (findable).

• The experience should help users understand what details matter and why (insightful).

• Users should feel confident they can complete the form without second-guessing their input (empowering).

Together, these needs support clarity, confidence, and forward progress in a moment where users are already under some pressure.

Business Goals

From the business perspective, this experience supports consistent and reliable incident intake.

• Improve incident quality — Capture clear, complete information that supports faster triage and resolution.

• Increase operational efficiency — Reduce back-and-forth caused by missing or unclear details.

• Support timely resolution — Enable teams to prioritize and act on incidents with confidence.

• Maintain user trust — Reinforce that reporting an issue leads to real follow-through.

• Scale support operations — Handle high volumes of incidents without adding manual overhead.

These goals create long-term value by helping users get help faster while allowing the organization to manage incidents at scale without friction.

---

Choose Metrics to Test Your Incident Form

We tested the ServiceNow Incident Form as a structured reporting experience that supports problem intake when something has already gone wrong. A design stack of UX metrics was selected by mapping core user needs to observable signals in the form experience. The metrics used were Appeal, Comprehension, Success, Sentiment, and Effort.

Credible → Appeal

Users need to feel that this is a legitimate place to report an issue and that their time won’t be wasted. Appeal helps capture that first impression, before users start filling anything out. In this experience, it reflects whether the form looks official, familiar, and appropriate for a serious task.

Findable → Comprehension

Users scan the form to understand what information is being requested and how it’s organized. Comprehension captures whether field labels, sections, and structure make sense at a glance. It reflects how easily users can interpret expectations without needing to stop and reread.

Usable → Success

Success measures whether users believe they can complete the form as intended. In this context, it captures more than navigation. It reflects confidence in making the right choices and providing acceptable detail from start to finish.

Empowering → Sentiment

Sentiment captures how users feel once they’ve spent time with the form. It reflects whether the experience leaves them feeling capable and supported, or cautious and unsure. This matters because emotional confidence influences whether users follow through or delay submission.

Efficient → Effort

Effort reflects how hard users feel they have to think while completing the form. In an incident scenario, lower perceived effort helps maintain momentum when users are already under pressure. This metric captures cognitive load rather than physical interaction.

---

Establish Hunches to Direct Your Testing

Before testing, the team started with a set of hunches about where this experience might help or hinder users. These hunches reflect common uncertainties teams face when designing structured forms under pressure. Each one shaped a focused question meant to reduce ambiguity before looking at any data.

Example: ServiceNow Incident Form

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Hunch</p></th><th colspan="1" rowspan="1"><p>Question</p></th><th colspan="1" rowspan="1"><p>UX Metric</p></th></tr><tr><td colspan="1" rowspan="1"><p>The form’s structured layout may help users feel oriented, but the number of required fields could create hesitation as users decide how much detail is enough. This uncertainty could affect confidence partway through completion.</p></td><td colspan="1" rowspan="1"><p>Do you feel confident completing this incident form with the information you have right now?</p></td><td colspan="1" rowspan="1"><p>Success</p></td></tr><tr><td colspan="1" rowspan="1"><p>Familiar patterns and enterprise styling may establish trust early, but could also feel heavy or impersonal. This might influence how users feel about engaging with the form at all.</p></td><td colspan="1" rowspan="1"><p>What impression does this incident form give you?</p></td><td colspan="1" rowspan="1"><p>Sentiment</p></td></tr><tr><td colspan="1" rowspan="1"><p>Clear labels and grouping may make the form easy to understand at a glance, even if it takes time to complete. Understanding expectations could remain high despite form length.</p></td><td colspan="1" rowspan="1"><p>How well do you understand what information this form is asking you to provide?</p></td><td colspan="1" rowspan="1"><p>Comprehension</p></td></tr><tr><td colspan="1" rowspan="1"><p>The experience may feel standard and reliable, but not especially motivating. Users might accept it as necessary rather than feel good about using it.</p></td><td colspan="1" rowspan="1"><p>How do you feel about this incident form overall?
</p></td><td colspan="1" rowspan="1"><p>Appeal</p></td></tr><tr><td colspan="1" rowspan="1"><p>As users move through the form, the mental effort required to interpret fields and make decisions may increase. This could slow momentum even if the interface is usable.
</p></td><td colspan="1" rowspan="1"><p>How simple or difficult does this incident form feel to use?</p></td><td colspan="1" rowspan="1"><p>Effort</p></td></tr></tbody></table>

Together, these hunches aim to understand how structure, clarity, and cognitive load affect confidence and momentum in a moment when users are already dealing with a problem.

---

Turn Hunches into Test Questions

Hunches only become useful once they’re turned into questions people can actually answer. Pairing each UX metric with a specific question type makes the signals clearer and easier to interpret. This approach keeps the test grounded in real reactions, not assumptions.

**Appeal (Likert scale)**

Question type: Attitudinal rating

Example: How do you feel about this incident form overall?

**Comprehension (Likert scale)**

Question type: Attitudinal rating

Example: How well do you understand what information this form is asking you to provide?

**Success (Likert scale)**

Question type: Self-reported task confidence
 Example: Do you feel confident that you could complete this incident form successfully?

**Sentiment (Multiple-choice impressions)**
 Question type: Impression selection
 Example: Which of the following best describes the impression this incident form gives you?

Effort (Likert scale)
Question type: Perceived effort rating
 Example: How simple or difficult does this incident form feel to use?

---

Calculate UX Metric Scores from User Feedback

We tested the ServiceNow Incident Form to understand how people experience reporting an issue when something has already gone wrong. Participants were focused on explaining a problem clearly and deciding whether they could complete the form with confidence. The design stack included a mix of attitudinal and behavioral signals: Appeal, Comprehension, Success, Sentiment, and Effort.

• Very Good = 90% and above

• Good = 70%–89%

• Average = 50%–69%

• Poor = 30%–49%

• Very Poor = below 30%

**Appeal (80% — Good):**
Most participants reacted positively to the form at first glance. It feels familiar, structured, and appropriate for a serious task. This helps establish trust before users begin making decisions.

**Comprehension (85% — Good):**

Users largely understand what the form is asking and how information is organized. Labels and sections make sense, and people can orient themselves without much effort. Understanding holds steady even as the form grows more detailed.

**Success (62% — Average):**

Confidence dips when users consider whether they can complete the form correctly. People hesitate around how much detail is required and whether their input will be sufficient. This suggests uncertainty at the decision-making layer rather than confusion about the interface itself.

**Sentiment (55% — Average):**

Emotional response is mixed after spending time with the form. While it feels reliable, it can also feel heavy or demanding. That tone affects how confident users feel about moving forward.

**Effort (Score not displayed):**

Effort feedback points to rising cognitive load as users progress through the form. The experience requires careful thought, even when navigation is clear. This contributes to slower momentum.

[Image]

Taken together, the scores describe an incident form that is clear and credible, but mentally demanding. Understanding is strong, yet confidence softens when users must judge completeness and correctness. The dominant pattern is not confusion, but hesitation at the point of action, which shapes how smoothly issues get reported.

Click here to check out the raw survey data and UX metric scores for ServiceNow’s incident form.

---

Draw Signals from Your Design Stack

Here’s how signals were surfaced from ServiceNow’s Incident Form test results by following five steps:

1. Focus on poorly scoring or imbalanced metrics

[Image]

The overall test score landed in the Average range. Comprehension and appeal were the strongest signals, while success and sentiment trailed behind. People generally understand what the form is asking, but hesitate when deciding how to complete it correctly.
Signal: Clarity is present, but confidence drops when users have to judge what “good enough” looks like.

2. Identify patterns across metrics

[Image]

Comprehension and appeal reinforce each other early. The form looks familiar and structured, which helps users orient quickly. Where the pattern breaks is at the decision layer. Success and sentiment soften as users weigh field relevance, level of detail, and potential consequences. This points to a tension between thoroughness and ease of completion.

3. Determine if user needs are being met

[Image]

• Credible: Met — The experience feels official and trustworthy from the start.

• Usable: Partially met — Navigation is clear, but effort increases as the form progresses.

• Findable: Met — Fields and sections are easy to locate and scan.

• Insightful: Partially met — Users understand what’s required, but not always why it matters.

• Empowering: Partially met — Users can complete the form, but often second-guess their inputs.

4. Compare outcomes to business goals

• Improve incident quality: Partially supported — Information is collected, but uncertainty may affect completeness.

• Increase operational efficiency: At risk — Hesitation can lead to slower submissions or follow-up clarification.

• Support timely resolution: Partially supported — Clear structure helps, but confidence gaps may delay momentum.

• Maintain user trust: Supported — The form feels legitimate and dependable.

• Scale support operations: Partially supported — Structure scales, but cognitive load may limit consistency.

5. Surface signals & establish a direction
Signals derived from the data:

[Image]

• Users quickly recognize this as a legitimate place to report an issue.

• Understanding is high, but decision-making slows progress.

• Confidence weakens when users must judge detail, not when they read instructions.

• The experience favors accuracy over speed once users are inside the form.

Direction based on business context:

The evidence points toward an experience that prioritizes control and completeness, sometimes at the cost of momentum. The form works best for users who already know how incident reporting functions and what details matter.

This is a reliable, structured incident form that supports clarity and trust. Its main tension is not comprehension, but confidence at the point of action, where users pause to make sure they’re doing it right.