11 minutes
Where a service is actually designed The six points in a division project where the shape of a service is settled, what it costs to change a decision at each one, and why accessibility handled at the end becomes an exception process.
What you’ll be able to do Map the points in a division project where the design of a program or service is actually settled — problem definition, scope, requirements, solicitation and contract, pilot and rollout — and name which of those points your own role can still influence. Compare the responses to this question and explain your choice: What is the most useful thing to raise? Document a next step for Where a service is actually designed: Take one project you are part of. Write down which of the six decision points are still open, which have closed, and the one open point where your role gives you a real say. The design is mostly finished before the design phase starts Ask when a service was designed and most project records will point to a phase with the word design in its name: the weeks when screens are drawn, letters are drafted and a workflow is diagrammed. By then, much of what decides whether the service works for people has already been settled, usually in a handful of early conversations that did not feel like design at all.
What gets settled in those conversations? What the problem is called. Who is assumed to be at the other end of it. What counts as evidence that the problem is real. How much time the work has, and what that timeline quietly rules out. Whether the process will have one path or several. Those choices travel into requirements, then into a solicitation, then into a contract, then into a system that may run for many years, and each step makes them harder to revisit.
This is not an argument for slowing every project down. It is an argument for spending attention where it is cheap. A question asked while the problem statement is still open costs a meeting. The same question asked after a contract is awarded costs a change order, a delay and, usually, an apology to people who were already left out. Policy and program staff, contracting staff and senior sponsors each hold one of those early moments. That is why this module is a useful starting point for all three.
Six points where the design is actually set Problem definition Scope and schedule Requirements Solicitation and contract Build and pilot Rollout and after
The first description of the problem decides who the service is for. “Reduce processing time” produces a different design than “help people who currently give up at the second step get to a decision.” Ask who described the problem, from which side of the counter, and whether anyone who experiences it was part of that description.
Scope decides what is in and out; the schedule decides what the team will have time to learn. A timeline with no room for discovery with the people affected is a decision to design from staff assumptions. Ask what the schedule leaves out, and who that absence affects most.
Requirements turn intentions into things someone must deliver. Formats, channels, time windows, reading level, interpretation, accessibility conformance and testing with people who will use the service can all be written here as requirements with acceptance criteria. Anything not written here is optional in practice, whatever the charter says.
Once a supplier is selected, the contract defines what the division can require without renegotiating. Accessibility described as a general promise gives a reviewer nothing to measure. Accessibility described as named deliverables, tests and acceptance steps gives the division a way to accept work or send it back. Contracts and procurement staff hold this moment.
A pilot tells you what you designed it to tell you. Pilots placed where they are easiest to run tend to include the people the design already works for. Ask whether the pilot includes the people the design is most likely to fail, and whether they have a way to say so.
Rollout decides who hears about the change, in what language and format, and how long they have to adjust. After launch, the design keeps making decisions through its defaults. Ask what you will look at to find out who stopped, and what you will change when you find out.
Ask the two questions while the answer is still cheap What you can change You control which questions are asked while a decision is still open — in the problem statement, the charter, the requirements list and the contract language you draft, review or sign.
What to watch for Do not let “accessibility will be handled at the end” stand as a plan. Handled at the end, access becomes an exception process run one person at a time, after the design has already decided who has to ask for it.
Your next step On the project closest to you, find the next decision point that has not closed and bring two questions into that meeting: who does this affect, and what will it require of them?
What it costs to change a decision, and when While the problem statement is open
A conversation. Redefining who a service is for costs attention and nothing else, and it changes everything downstream.
While requirements are being written
An edit. Naming a format, a channel, a time window or an accessibility acceptance criterion is one line of text now and a negotiation later.
While the solicitation is still open
A revision. This is the last point where access is something a supplier agrees to deliver instead of something the division asks for as a favor.
After the contract is awarded
A change order and a schedule conversation. Almost everything is still possible. Almost nothing is cheap.
After launch
A repair project, a workaround for staff, and a group of people who have already met the version that did not work for them.
Private reflection, kept by you and not collected anywhere: think of a project you are part of now. How might your role, your authority or your familiarity with how DHS works shape what the team treats as an obvious design choice?
Carry this forward Most of what decides whether a service works for people is settled in early conversations that do not feel like design: what the problem is called, who is assumed to be at the other end of it, what counts as evidence and how long the work has.
Accessibility, language access and cultural responsiveness are inexpensive while a design is still on paper and expensive after a requirement is written into a contract or a system.
A project has a small number of hard points where change is still easy. After each one closes, the cost of the same change rises sharply.
“We will handle accessibility at the end” is a scheduling decision. In practice it usually means handling access by exception, one person at a time, after the design has already decided who has to ask.
A scenario about a solicitation six weeks from posting, a tab set on the six decision points, flashcards on what a change costs at each stage, and a knowledge check on a general accessibility clause.
Take one project you are part of. Write down which of the six decision points are still open, which have closed, and the one open point where your role gives you a real say.
Browse and download only. Course notes are not typed or saved on this page.
Reset this lesson
Course overview Next lesson Carry this into practice Examine the early choices that shape a service and include affected people before the design is fixed.
Return to the experience: What did you notice or try, whose perspective informed it, and what would you keep or adjust?
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.
