Built for Ann Arbor, and for every trip from A to B. This iOS app guides students from one classroom door to the next, blending outdoor paths, indoor shortcuts, live buses, and the weather into one route.
In progress. The research and design are done, and the build is next.
University of Michigan students often have ten minutes to get from one class to the next, sometimes across two campuses. The maps they use will point at a building. They won't say that the third floor is really the main floor, or that you can cross three buildings without stepping outside.
A2B is built around that gap. It plans one door-to-door route that can walk outside, cut through buildings, ride a bus, and change its mind when the weather or the bus does.
Ask someone what's wrong with campus navigation and they'll shrug. Ask about the last time they got lost and you get a story. So every question starts with "tell me about a time," and none of them can be answered with a yes or no.
We planned to find students where the problem actually happens: Shapiro Library, the CCCB atrium, the Diag, DUDE, the BBB atrium, and Ross, ideally during the ten-minute gap between classes when the trip is still fresh. We wanted four kinds of people:
Easy questions first, to hear how a normal day actually runs.
The heart of the interview: real moments, good and bad.
Two broad questions to catch anything we didn't think to ask.
Counts show how many of the five students raised each point. Every one of these comes straight from the interviews.
When it's cold or wet, students stay indoors whenever they can.
“The colder it is, the more likely I am to use buildings as a tunnel...”
The fastest trip is often a bus, a switch, and a cut-through, not one straight route.
“I’d rather take a faster bus... and then switch over to Commuter North.”
Floors, rooms, and entrances don't line up from one building to the next.
“It’s built into a hill so the floors make no sense...”
Inside big buildings, everything looks the same and it's easy to lose track of where you are.
“You’ll enter on the third floor and it becomes the first floor.”
Shortcuts are learned by trial and error, or by asking someone who already knows.
“Navigation apps don’t really tell you that you can switch.”
Arrival times slip, buses skip stops when full, and one delay can sink the day.
“It says it’ll be there in two minutes and it won’t come.”
Signs, arrows on walls, and asking around all worked. Students want that feeling in an app.
“[You] can go from GGBL to EECS without exiting the building, following the arrows next to the walls.”
Watching where a bus really is helps them decide when to leave or wait.
“It even has a live bus view, so you can see where the buses are at on campus.”
Easy to follow, and clear about which entrance to use.
“I like having a map with routes and directions. Usually one that’s more simple...”
“I literally had to ask around... and then, yeah, I made it.”
The best routes on campus aren't missing from campus. They're missing from the apps. Every example below was figured out by trial and error, or by asking someone. A2B's job is to know them on day one.
The direct bus to the far end of North Campus goes the long way around the hospital. One student rides a faster bus first, then switches. The app only says to take the slow one.
In the cold, students walk through the Chemistry Building to reach the Dow or the CCTC instead of crossing outside.
You can get from the GGBL to EECS without ever going outside, if you know to follow the arrows next to the walls.
During the career fair, full buses drove past one stop. One student walked to the CCTC stop and boarded there instead of waiting 30 minutes.
Under the hood, A2B treats campus as a graph: a web of points and lines where every hallway, sidewalk, stairwell, and bus stop is a possible step. Because indoor corridors and outdoor paths live in the same web, the app can plan one trip that goes inside, outside, onto a bus, and back inside.
Planned design
Campus shortcuts and building connections are part of the map from the start, so the app can say things like “Cut through EECS to stay indoors.”
Built-in AI reads what you say, like “It's freezing, keep me inside,” and adjusts the route using live weather and campus bus data.
Each classroom number is tied to an exact spot in the map, so directions end at the room, even where floor numbering is confusing.
| What students told us | How A2B answers |
|---|---|
| Maps stop working indoors (5 of 5) | Indoor maps of corridors and floors, with room numbers tied to exact spots. |
| The good routes are secret (4 of 5) | Cut-throughs, side entrances, and building connections live in the map from day one. |
| Buses are hard to trust (3 of 5) | Live bus positions and the weather decide whether a bus or a walk wins. |
Door to door, not just building to building.
The app is built in three layers, so there is always something useful working before the harder ideas arrive.
The layers above are the full vision. A first version has to be much smaller, so we sized each idea by counting its hard pieces. A hard piece is something that needs live data, an outside service, or memory that lasts across a whole trip. Plain screens and simple saved lists don't count.
Each idea also got an importance score from how often students raised the problem it solves, with the most common problem scoring 100. Then we asked how many hard pieces each one needs, and aimed for around four.
| Idea | Importance | Hard pieces | Score |
|---|---|---|---|
| Transit-aware route comparison | 40 | 4 | 40.0 |
| Classroom-to-classroom indoor navigation | 100 | 2 | 33.3 |
| Context-aware route choice (weather, preferences) | 60 | 5 | 30.0 |
On its own, transit scores highest. But the table hides something important: all three ideas lean on the same foundation, a verified map of the buildings and an engine that finds paths through it. Transit can't compare routes that don't exist yet, and weather can't rank them either.
Count that foundation once and the picture is clear. Indoor navigation is the foundation. It solves the problem every student raised, and it needs only two hard pieces. Everything else becomes an add-on with a known price.
The risk with add-ons is that they quietly become required. If a weather outage could stop you from getting directions, the app would be less reliable than the map it replaced. So the design only allows information to flow one way, and the engine that finds routes is the only part that decides what a valid route is.
Weather, preferences, and bus data come in from the side. They never edit the routes.
| If this goes wrong | A2B does this |
|---|---|
| Weather data is missing or out of date | Uses the normal route order. Directions keep working. |
| A request like “keep me inside” can't be understood | Ignores it and keeps the original route. |
| Bus data is missing or out of date | Leaves the bus option out. The walking and indoor route stays. |
| The ranking or comparison step fails | Falls back to the route engine's own order. |
AI should never invent a hallway. The map of the buildings is built and checked by hand first, and ordinary routing code decides which routes exist.
AI earns its place where things are fuzzy: understanding “I'm late” or “keep me inside,” weighing competing preferences, and explaining the tradeoff in a sentence. Finding the route is not its job.
Add-ons can rank and compare routes. They can never rewrite them.
An illustration of how the route should change. Each version is built from a move a student described to us. It is not a live build.
Take the faster bus to North Campus, then switch to Commuter North for the last stretch. No need to sit on the slow direct route.
Same ride north, then stay out of the cold: cut through EECS and FXB to reach the Naval Building without going back outside.
Don't wait at a stop that keeps getting skipped. Walk to a stop where a bus is actually due, the way one student did at the CCTC.
We're starting small on purpose: five connected buildings, the new computer science building (LCSIB), BBB, Dow, GGBL, and EECS, the cluster students found most confusing. The first goal is reliable classroom-to-classroom directions there. If the map works, new buildings can be added by mapping them, with no hardware to install.
The interviews, the problem definition, the product design, and the plan are finished. Code is not written yet. Everything on this page about how A2B behaves describes the design we're about to build, and I'll update this page as the build moves forward.
AI has two habits that quietly ruin planning. It tends to agree with whoever is typing, and a long chat gets attached to its own earlier answers. To plan A2B, I used a method from Dave Rensin's essay on "elephants and goldfish," which is built to work around both.
The elephant holds the whole project in its head and does the drafting. It knows everything we've said. The catch is that it grows attached to its own ideas and starts agreeing with me.
A goldfish sees only the documents I paste in, with no memory of how we got there. It can't be swayed by the conversation. It also tests the writing: if a goldfish can't explain the project from the page, the page is missing something.
A fresh goldfish every round, so no critic gets used to the plan
The method only works if the prompts do real work. These are the four I leaned on, and why each one is there.
The prompt: every session started by saying we were not writing code. We were having a design discussion, and it should ask clarifying questions and challenge my assumptions instead of accepting them. I also asked for plain English with minimal jargon.
Why: AI jumps to building before the problem is understood, so this keeps it in the thinking phase. The plain English rule matters just as much. Jargon makes weak ideas sound solid, and if I can't read an answer easily, I can't judge it.
The prompts: "Why do you think that?" whenever an answer sounded confident. And when the AI started praising my ideas, I told it that its best use was challenging my thinking.
Why: agreement feels good and teaches nothing. Asking why forces the reasoning into the open where I can check it, and naming the flattery pulls the conversation back to being useful.
The prompts: each fresh goldfish got one job and only the documents it needed.
Why: "review this" gets vague feedback. A specific role asks a specific question, and a fresh chat can't be talked out of its answer.
The prompt: for sizing, I told the elephant to act as a strict data parser. Read the finished documents, then output only a structured list of ideas, importance scores, and hard pieces, with no commentary. A small script did the scoring math.
Why: AI is good at reading messy text and unreliable as a calculator. Splitting the job meant the numbers were repeatable, and I could change one input and rerun them. It is the same rule A2B follows: AI interprets, ordinary code decides.
A review is only worth running if it changes something. These are four places where it did.
| What a critic found | What changed |
|---|---|
| The pain list mixed what students said with what we guessed, and assumed everyone wants the fastest route. | We split observed pain from inference, and treated weather and transit as things that change which route is best. |
| The AI concept had seven overlapping features, and some didn't need AI at all. | We merged them into three systems and kept AI only where plain code can't do the job. |
| The scoring ignored that every idea needs the same routing foundation. | We counted the shared parts once and reran the math. |
| A weather or bus outage could have broken basic navigation. | We made the add-ons optional layers, each with a fallback. |
If a fresh reader can't explain the plan, the plan isn't finished.
The best routes weren't missing from campus, they were missing from the apps. The interviews changed our question from "how do we draw a better map" to "how do we capture what students already know."
Counting the hard pieces of each idea showed that one job, finding the way to the room, carries most of the value for the least work. Everything else became an add-on that can fail without breaking it.
If I can't point to something a student said, the feature doesn't belong in the plan. That rule kept the idea small and honest.