Design for the place the work actually happens

A mobile layout can fit a phone perfectly and still be inconvenient at the moment someone needs it. The person may be standing, interrupted, holding something, or trying to keep attention on another activity. A compact interface does not automatically account for any of those conditions.

I have a practical reminder of this in Dugout, the youth baseball lineup planner I created as a personal project. Planning positions and playing time was useful digital work. During a game, I needed a quick reference without another screen competing for attention.

That led to a printable lineup card as part of the experience. The product's value did not have to remain inside the application. The useful result was a plan I could bring to the field and share with the people involved.

The environment changes the task

Dugout came from my own experience coaching youth baseball. I needed to plan beyond the first inning, account for absences and substitutions, and think about fair playing time. A visual board helped make those relationships easier to see before the game.

The game itself introduced a different context. I was already using GameChanger, and coaching required attention on the field. A planning tool that demanded continued interaction during play would have solved only part of the problem. The printable card gave the plan a form suited to that setting.

I developed the concept and design, then used AI-assisted development to begin building the application. It remains a beta and an ongoing personal project. I treat it as a practical example of designing around a familiar problem, while keeping its current status clear.

Ask what the person is paying attention to

When reviewing a product, I want to know what else the person is doing. A task performed at a quiet desk can support a different amount of reading and decision-making from a task performed between interruptions.

Imagine a contractor checking the next job on a phone. They may need the address, the agreed scope, and a contact route immediately. Detailed reporting can remain available, but it should not obscure the information needed to continue the work. The priority comes from the situation rather than the size of the screen alone.

The Workhorse concept explored mobile workflows for contractors, connecting estimates, jobs, schedules, invoices, and communication. My role included helping define scope and sequencing with design and engineering. One important constraint was that the experience needed to work in short bursts in the field. That is a product requirement, not simply a responsive breakpoint.

Separate preparation from execution

Some tasks have a planning phase and a use phase, with different needs in each. Trying to put both into one interface can make the product feel equally cumbersome in both settings.

For a hypothetical event tool, preparation may involve reviewing detailed records, assigning responsibilities, and checking conflicts. During the event, the same person may need only the next action and an exception path. The product can carry the preparation forward without requiring the full planning interface at every moment.

I would map those phases explicitly. What decisions can be made beforehand? Which information must stay current? What can be exported or printed? What happens when reality changes after the plan has left the application? These questions help the team decide where interaction is necessary and where a stable reference is more useful.

Consider the handoff between people

A product's output may be used by someone who never opens the product. A printed plan, an email summary, or an exported document becomes part of the experience. It needs enough context to be understood independently.

With Dugout, the lineup card can provide a shared reference for assistant coaches and others involved in the game. That changes what the output should contain. It needs to communicate the plan clearly without depending on the visual controls used to create it.

For other products, I would ask who receives the result and what they need to trust it. A schedule may need a version or an update time. A work order may need a clear distinction between the agreed scope and internal notes. A generated summary may need a source link. The handoff should preserve the information that matters in the next setting.

Design for interruption and return

Real work is often interrupted. Someone begins a task, answers a call, talks to a colleague, and returns later. If the product assumes continuous attention, a short interruption can create confusion or lost work.

I would inspect what a person sees when they return. Is their progress preserved? Can they tell which changes were saved? Does the interface explain whether information has changed while they were away? A useful return state can prevent someone from repeating steps or acting on an outdated assumption.

For an AI-assisted workflow, this becomes particularly important when generation takes time. A person should not need to stare at the screen to preserve the result. The product needs a clear place for the output and an understandable account of what happened while they were doing something else.

Be selective about automation in the moment

AI could support preparation by drafting a summary or organizing information. That does not mean it should introduce another interaction during the most attention-constrained part of the task.

If I were exploring AI for a planning product, I would first ask where assistance would reduce effort without taking away useful control. A suggested plan might be valuable before an event, when there is time to inspect it. A conversational assistant during the event might add more attention cost than it removes.

I would also keep the distinction between a suggestion and a confirmed plan visible. The person responsible needs to know what has been accepted and what still requires judgment. That is especially important when the output is going to be used away from the software.

Test in a setting that exposes the constraint

A desktop review can establish whether a flow is understandable in ideal conditions. It may say little about use in the actual environment. I would choose tests that expose the condition the design is supposed to accommodate.

For a phone workflow, that could mean short tasks with realistic interruptions and content. For a printed output, it could mean reviewing the actual page at a usable size. For a collaborative handoff, it could mean asking another person to interpret the result without the creator explaining it.

These tests do not need elaborate staging to be useful. They need a clear question and a realistic constraint. If glare, noise, limited connectivity, or shared equipment matters, the team should understand that before making assumptions about the interface.

Let usefulness travel beyond the device

I like products that recognize when their job is to prepare someone for something outside the application. The result might be a decision, a conversation, a reference, or a plan that can be used without continued interaction.

That perspective changes how I judge features. More time in the product is not automatically a better outcome. A person who can prepare well, leave with what they need, and return when the work changes may have a more useful experience. Designing for the place work happens means giving that outcome equal attention to the screen that helped create it.