A 911 fail
The first time I had ever called 911 was for an almost non-emergency reason. Driving on an Interstate highway through Baltimore, we noticed a large ladder that had fallen off a construction truck. It was blocking two lanes out of four, and cars were veering to the side to avoid it.
Because we were one of the first ones to notice the ladder falling off, and I was a passenger, I was in a good place to call and report debris on the road. So I called 911, assuming they’d quickly route my call to the department that can easily deal with this stuff.
The call went something like this:
- Hello, I’d like to report a dangerous situation on the road.
- Ok, where are you?
- I’m on Route 95, between exits 51 and 52, heading North, there is dangerous debris on the road…
- Are you in the city or the county?
- …
After a few attempts back and forth, I couldn’t answer the dispatcher’s question because I didn’t know where the city / county border was. It was certainly not on my phone’s map apps. We were still driving, so I no longer was at the exact location. I was also getting frustrated because the dispatcher did not seem to care for my attempts to give her a location by highway exit number, or by listing the streets the highway crossed near the area. After a few minutes I gave up and the report went nowhere.
Perspectives and assumptions
I can only assume the dispatcher’s role was to route my call to the next responsible party. For her, the agency in charge of traffic safety in the city, and the other agency in charge of the county are completely different things. For me, and anyone on the ground, the difference between those territories could be invisible. The border is not marked, and could lie across two corners of the same intersection. In general, the public won’t usually see these boundaries in the same way administrators do.
However, the dispatcher had responded to my call with the assumption that anyone calling 911 locally would know if they are “in the city or the county”. Her assumption and my assumption did not match, and an emergency call failed as a result.
I disagree with that assumption: even though I lived in the Baltimore area for four years, I’d only know the city/county border location for the immediate neighborhood where I lived. Even then, it was only because the university I attended had famously lobbied to move that border so they could have a more prestigious Baltimore city address. I wouldn’t expect a typical 911 caller to know this stuff.
I don’t fault the dispatcher in this case, by the way. Even though she could have been more prepared to understand my perspective, I can see how her environment could have made the city / county distinction so obvious it became an invisible assumption.
A designer’s job is to find out
It is important to discover the assumptions built in to a project. This responsibility is shared, but designers are often in the best position to lead this discovery because we deal both with understanding a user’s needs and the tools we might use to implement a solution.
Part of this discovery process is requirements gathering: we understand and document the business goals the client aims to achieve, the restrictions that will inform the choice of design tools and technologies, and the user and industry insights that will inform the functionality can propose for an application.
But in addition to gathering requirements, we must discover the “obvious” things to people close to the product. These assumptions are so self-evident to the person who holds them that they won’t likely be included with requirements, or even communicated voluntarily. Designers must ask the “obvious” questions to uncover those things and continue asking them throughout the process.
Not communicating those assumptions makes a project ripe for surprises. If you don’t talk about the obvious things, everyone can hold on to conflicting assumptions for a long time. Making changes to address hidden assumptions after a portion of the work has been done adds cost (and frustration!) and decreases efficiency.
How to uncover hidden assumptions
To uncover hidden assumptions, designers must ensure open and frequent communication. It may feel like over-communicating at first, but will start to feel natural with practice. Here are a few of the practices we use.
Daily updates On most projects, we update the client on our progress daily. While it may seem like a chore to write up an additional description after the day’s work has been completed, the updates force us to communicate clearly and often. This gives the client an opportunity to correct our assumptions early in the process.
These updates can include questions (e.g. “How many people are likely to experience this particular use-case?”) and assumptions we need confirmed (e.g. “We have found that most users will leave this setting untouched, so we included this default value. Is this value a safe one to default to?”). Pro tip: request feedback from a client with a clear list of questions and assumptions they can quickly confirm or correct. This format makes it easier for the client to respond, so it’s more likely that you’ll quickly get the information you need to move forward.
Flow diagrams We often produce flow diagrams to map out the universe around the product we’re building. When all team members have access to a visual representation of the entire product, and things that influence it, we often find problems and special cases that were not previously considered.
Flow diagrams often include elements like triggers (what caused a process to be started), decision points (yes / no), variables (including an approximate range) and tentative bits (we are explicitly marking some part of the process as outside the scope, or as a secondary requirement).
Annotated wireframes and sketches We always annotate wireframes and sketches. We may draw low-fidelity sketches at first, but will note the type of content that might be included in a specific screen, and the reasoning and user goals that informed a specific layout. Notes like this will help frame the follow-up discussion with the client.
TL; DR
A difference in expectations is one of the most preventable causes of projects going wrong. And among all expectations, assumptions can be the most dangerous: they feel so “obvious” that we don’t even bring them up. If even a 911 call can be derailed by a dispatcher’s assumption, so can a large collaborative project.
And just like in the 911 call, it’s possible to prevent misunderstanding by asking the “obvious” questions. The dispatcher could have asked for my location in a different way - by street intersection, or exit number. And if her standard process did not include the assumption that a caller would know where the border between the City and the County lies, she would have been able to route me successfully by asking the question in a different form.
Don’t be that 911 dispatcher. Spend the time to talk about assumptions up front - and you’ll save everyone on the team time, effort, and unnecessary frustration.
