11 minutes
Sign-ins, privacy and the words on the screen Identity checks, security settings, shared devices and error messages decide who finishes an online process, and they are usually written by people who never get stuck.
What you’ll be able to do Explain how identity checks, security settings, privacy conditions and on-screen wording create or remove barriers in an online process, and describe one change that keeps the requirement and removes the barrier. Compare the responses to this question and explain your choice: What is the most useful thing the grants team can do with this finding? Document a next step for Sign-ins, privacy and the words on the screen: Find the last error message, sign-in instruction or timeout warning your team wrote or approved. Rewrite it so it says what happened, what a valid answer looks like and who to contact, then check that the contact is answered by a person. The requirement is not the barrier; the way it is met usually is Identity checks, sign-ins, timeouts and file rules exist for reasons that are easy to defend. Personal information has to be protected. Public money has to reach the organization it was awarded to. A state system cannot be open to anyone who finds the address. None of that is the barrier. The barrier sits in the assumptions underneath the implementation: that everyone has a personal mobile phone that receives text messages, that one individual alone speaks for an organization, that fifteen minutes is enough to read a page, that any document can be produced as a particular kind of file under a particular size.
Each of those was a decision somebody made, usually quickly, usually without anyone in the room who would be stopped by it. Almost all of them can be met another way while keeping the requirement whole: a code delivered by voice call as well as by message, printed backup codes, a second named person on an account, a longer session with a warning and answers saved when it ends, a wider range of file types, an alternative verification route for a person who has never held the usual documents.
Privacy has a second face here that is easy to miss. A design that assumes a private device forces some people to borrow one, or to hand a sign-in to a family member, a support worker or a neighbor in order to finish a state process. The process has then created a confidentiality problem it will never record, and the person carries it long after the form is submitted.
Four tensions worth naming out loud Protecting the account, and being reachable A second factor at sign-in protects an account, and sending the only code to a personal mobile phone assumes a phone, a number that does not change, a plan with messages included, and coverage where the person actually is. A voice call, a code by email, printed backup codes and an in-person route each keep the protection and remove an assumption. The requirement is the protection, not the text message.
A private process, and a shared device Confidentiality rules picture a person alone at their own screen. Many people share a device with family, use one at a library or a community organization, or live somewhere the device belongs to the setting. Save-and-return, short forms, no password stored by default, a clear way to sign out, and a route that is not online are what respect privacy in those conditions.
Preventing fraud, and the burden of proof Verification steps are aimed at a small number of people acting in bad faith and are paid for by everyone. The heaviest payers are those least likely to hold the standard documents: people who have moved often, people whose name has changed, people who have never had a driver's license, people leaving an institution or a shelter. Ask what the check establishes, and whether anything else establishes the same thing.
Efficiency, and processing time Timeouts, short windows and fast-moving screens are built around a reader who is quick and uninterrupted. Anyone who reads slowly, listens through a screen reader, composes on a communication device, or is caring for someone in the same room is penalized by a design that was only trying to be tidy. A warning before the session ends, and answers that survive it, cost almost nothing.
Wording on the screen that decides whether someone finishes An error that says what failed, where it is, and what to do next — not a code, not a red outline on its own, and not “invalid entry”.
A required field that says what counts as a valid answer before the person has to guess at it.
A sign-in instruction that says what to do when the phone number or email on the account no longer works.
A warning before a session ends, early enough to act on, with the answers saved when it ends anyway.
A confirmation the person can keep, in plain words, saying what was received, what happens next and roughly when.
A named contact with a phone number that a person answers, published in the same place and the same size as the online route.
Terms explained where they appear: what an account is for, what submitted means, and what happens between submitted and decided.
I could have done it myself if the code had come to the house phone. Instead my daughter signed in for me, so now she knows everything about my services, and the system thinks she is me.
Composite participant perspective, illustrative Ask what the requirement needs, not whether it is required What you can change You control the question you bring to the business owner and to the staff who set the rule.
What to watch for Do not stop at “it is a security requirement.” That answer closes the conversation without telling anyone which part is the obligation and which part is only how it was built.
Your next step Take one step people get stuck on, list everything it currently assumes, and ask which of those the requirement actually needs. Bring the list, not the complaint.
Private reflection, kept by you and not collected anywhere: who could be burdened, excluded or misunderstood by the checks in a process I help run, and if someone has been shut out of it for a while, what would accountability and repair require beyond a quiet correction?
Try a situation A DSD grant opportunity for community organizations moves to an online application. Fiscal and grants staff notice that several small organizations, including two disability-led groups and a culturally specific organization, created accounts and never submitted. The system is working as designed: each account belongs to one named individual, signing in requires a code sent to a mobile phone, the session ends after fifteen minutes without activity, and attachments must be one file type under a set size. The help line is listed at the bottom of the page.
What is the most useful thing the grants team can do with this finding? Send a reminder to the organizations that started and did not finish, with the deadline and a link back to the application.
Write down exactly what the sign-in and submission steps require — a personal mobile phone, one named individual, a fast reading speed, one file type — take that list to the business owner and the staff who set the security rule, and ask which of those the requirement actually needs and which are only how it was built.
Record that the sign-in is a security requirement and therefore outside the scope of a grants review.
Consider your choice Try another response Carry this forward Security and privacy requirements are real obligations, and they are not the barrier. How they are met is the barrier: a code sent only to a personal mobile phone, a session measured for a fast reader, an identity check that asks for a document a person has never held.
Almost every one of those can be met another way without weakening the requirement: a code by voice call, a printed backup code, a second named person on an organization's account, a longer session with a warning and saved answers, a wider range of accepted file types, an alternative verification route.
Privacy assumes a private device and a private place. When a design forces someone to borrow a screen or hand a sign-in to a family member or support worker to finish a state process, the process has created a confidentiality problem it will never see, and the person carries it.
The words on the screen are part of the access design. An error that says what failed, what a valid answer looks like and who to call is an accessibility feature. “Invalid entry” is a dead end with a friendly font.
Every online-only process needs a route that is not online, published in the same place, at the same size, and staffed well enough that it is a real option rather than a formality.
A scenario about small organizations that started a grant application and never submitted it, an accordion naming four tensions honestly, and a knowledge check on error wording.
Find the last error message, sign-in instruction or timeout warning your team wrote or approved. Rewrite it so it says what happened, what a valid answer looks like and who to contact, then check that the contact is answered by a person.
Browse and download only. Course notes are not typed or saved on this page.
Reset this lesson
Previous lesson Next lesson Participation and course completion in this program do not count toward DHS-required training credits unless management, a director, or DHS leadership expressly approves an exception.
