AI-assisted discovery / Context framework
Give AI a model
of people's work.
I built a framework that connected research-grounded personas with a map of how their roles depended on each other. It gave AI a richer basis for evaluating product ideas and reasoning about workflows, information needs and different users' screens.
01 / Change the context behind the answer
A believable profile is a start.
Understanding the work goes further.
Earlier outputs described a person's background and broad goals. I wanted the AI to consider what that person needed to decide, the information they relied on and the people they depended on.
Typical persona model
A work-tracking system could help a manager keep the team organized, monitor progress and stay on top of deadlines.
Bring assignments, due dates and status into one view. A manager could see who is working on each task, follow up on overdue work and adjust priorities as demands change.
Prioritize visibility. Start with task assignment, progress tracking and deadline reminders so the manager can keep work on schedule.
The system I built.
A work-tracking system could help if it makes blocked work easier to resolve. A shared task list alone would leave the coordination problem in place.
Show how unresolved dependencies affect delivery commitments and capacity. That helps a director decide which work to prioritize or resource differently.
Connect each blocker to an owner, the people waiting on it and the work it holds up. A team view should help a manager intervene before a missed handoff becomes a delay.
Keep the next task, missing input and person who can unblock it together. Reporting a blocker should update the team view without asking the worker to enter it twice.
Prioritize the handoff. Start with flagging a blocker, assigning its resolution and showing the delivery impact. More reporting is only valuable if it helps someone act.
02 / Structure what matters
Connect the facets.
Make uncertainty visible.
The persona instructions organized source material around practical work: goals, responsibilities, workflows, decision rights, collaborators, tools and data. Trust requirements and adoption barriers gave the AI reasons to question an idea's usefulness.
I used publicly available role information, whitepapers and leading industry forums. The instructions kept evidence, assumptions and questions for real research distinct.
A working-context profile
- Goals & stakes
- Success measures, motivations and risks to avoid
- Work & authority
- Responsibilities, exceptions, decisions and escalation
- People & information
- Collaborators, handoffs, tools, data and trust concerns
- Adoption & implications
- Objections, proof needed and consequences for product design
03 / Model the work between roles
The handoff connects the screens.
A cross-persona dependency sheet mapped how roles worked together. That gave UX questions a context for deciding where handoff workflows and different management views were needed.
One blocker. Different decisions.
Flag what stops the task.
Worker flags the missing permit → the manager sees who can resolve it.
Resolve the dependency.
Manager connects the blocked tasks → the director sees the delivery impact.
Make the priority call.
Access permit holds up inspection and sign-off before Friday.
Director sets the priority → the team can act on the same blocker.
I brought the role perspectives together into a use-case scenario. The framework supported reasoning about the work across screens, beyond a list of features for individual users.
04 / What I observed
Specific enough to feel
like familiar work.
The responses felt more like feedback from someone working in the industry. They reflected priorities, pains and constraints that a demographic sketch had not captured.
At a company where confidentiality and security were top priorities, colleagues asked whether I had supplied internal documents to a public AI.
This was my observed experience with generated perspectives, not a validation study or a substitute for research with real users.