Confirm layer ownership
Separate the user-level portfolio overview from each application’s lifecycle state and supporting modules.
Updated IA · Applicant / Intern
One portfolio overview above every application journey
The dashboard aggregates multiple applications at user level, then opens each application into its own current state. Layer 1 is a Multi-Application Overview; Layer 2 maps 12 user-visible application states into five reusable patterns.
Suggested facilitation
Run the session in four decisions
Move from shared principles to edge cases, then finish with named owners for unresolved business rules.
Prioritise across applications
Apply urgency and deadline rules so only one dominant action appears above the fold.
Stress-test application patterns
Check that Explore, Continue, Waiting, Progress and Completed still cover all 12 user-visible states.
Close or assign gaps
Validate the five confirmed rules and assign the six open items to Product, BA, UX or Tech.
Updated architecture
Two layers, with lifecycle state owned by the application
The overview answers what needs attention across the portfolio. The application experience explains one application’s state, action, journey and guidance.
Layer 1 · User / dashboard level
1layerMulti-Application Overview
Always exists conceptually and becomes explicit when the applicant has two or more active applications.
User-level HeroPriority ActionMy ApplicationsContextual Task GuideDefender ArchetypeAggregated Activity
Layer 2 · Individual application level
12statesApplication Experience
Every application owns one current lifecycle state and maps independently to one of five reusable patterns.
HeroAction / Status SpotlightJourneyWhat Happens NextTask GuideLatest Activity5 IA patterns
Scaling ruleOne active application may surface its application experience directly. For 2, 3 or 4+ applications, use the same Portfolio Overview and scale through compact rows or Active / Completed / Archived filters—not new IA patterns.
Layer 1 · Multi-Application Overview
One priority action across all applications
A compact overview shows what needs attention first, then lets the applicant open each application for detail.
Applicant Dashboard
Welcome back
Three active applications · Two need attention
Choose interview availability
University Internship 2027 · Interview: Action required
Due 3 Sep 2026Pattern B
Select TimeslotsMy Applications
University Internship 2027Interview: Action required · Pattern B
Choose interview availability · Due 3 SepTop priorityResearch Internship 2027Offer action required · Pattern B
Review offer · Due 5 SepReview OfferCyber Internship 2027Submitted · Pattern C
You’re all caught up — no action requiredView ApplicationSuccess test
The dashboard must answer these within seconds
Do I need to do anything now?
What exactly do I need to do?
When do I need to do it by?
Where am I in the overall journey?
What happens next?
Layer 2 · Interactive application model
12 user-visible states → 5 reusable patterns
Submitted includes the review period as one continuous waiting state. Different applications can occupy different patterns at the same time.
Layer 1 · PortfolioMultiple active applications
Before applicationNo application yet
Application
DraftSubmittedInterview: Action requiredPending confirmationConfirmedRescheduling required
Offer and onboarding
Offer action requiredOnboarding action required
Internship and completion
Active internshipCompletion action requiredJourney completed
Pattern A
Explore
No application yet
Primary user needWhat can I do now?
Main UI priorityProgramme discovery
Discovery
Start your journey with DSTA
Explore internship opportunities and find the programme that fits your interests.
Primary CTA: Explore / Apply
Explore programmes → Check eligibility → Start an application
Latest activity: Optional
Defender Archetype and “Play Quiz Again” remain visible across every state.
Rule / noteProgramme discovery is the primary purpose.
Layer 2 · Applicant Dashboard
Five reusable dashboard skeletons
Low-fidelity wireframes show which regions stay, change priority or disappear across the five application patterns.
Pattern A · Explore
No active application · discovery first
Hero
Programme discovery
Application guide
Pattern B · Continue / Action
Required task · one dominant CTA
Hero
ACTIONPrimary action spotlight
Journey
Pattern C · Waiting / Status
No user action · reassurance first
Hero · personalised greeting
STATUSStatus spotlight · no CTA
Journey
Pattern D · Progress / Checklist
Progressive tasks · next incomplete item
Hero
2 / 3Checklist
Journey / progress
Pattern E · Completed / Resources
Completion summary · consolidated resources
Completion hero
COMPLETECompletion summary
After internship
Layer 2 · Reusable component matrix
Visibility changes by application pattern—not by a new page layout
These rules apply inside one application experience. The portfolio overview keeps only compact summaries and the top-priority contextual modules.
| Component | Explore | Continue / Action | Waiting / Status | Progress / Checklist | Completed | Purpose / rule |
|---|---|---|---|---|---|---|
| Current State Hero | ✓ | ✓ | ✓ | ✓ | ✓ | Explains what is happening now |
| DSTA Illustration | ✓ | ✓ | ✓ | ✓ | ✓ | Preserves visual identity and emotional tone |
| Programme Discovery | Primary | Secondary / optional | Secondary / optional | Hidden / low priority | Hidden | Only primary before an active application exists |
| Primary Action Spotlight | Optional | ✓ | — | ✓ | Optional | Answers “What do I need to do now?” |
| Status Spotlight | — | Optional | ✓ | Optional | — | Used for waiting / no-action states |
| Journey | — | ✓ | ✓ | ✓ | Completed | Orientation only; does not duplicate CTA or metadata |
| Checklist | — | State dependent | — | ✓ | Optional | Onboarding, progress and completion tasks |
| Task Guide | Application Guide | State-specific | Contextual | State-specific | Post-Internship Guide | Explains how to complete the current task |
| Defender Archetype | ✓ | ✓ | ✓ | ✓ | ✓ | Persistent across all states |
| Latest Activity | Optional | ✓ | ✓ | ✓ | ✓ | Historical changes and events |
Decision log
What is fixed and what still needs validation
Do not treat open items as requirements. The named disciplines should close them during or after the session.
Confirmed business rules
Safe to use in the IA model.
Onboarding has three tasks
Provide bank details, accept the Use Policy and upload a photo.
Product · BA · UXRescheduling is Mentor-initiated
An applicant may reschedule a maximum of two times.
Product · BA · UXOffer moves into onboarding
Review offer → Accept / Decline → accepted offer moves to Onboarding.
Product · BA · UXDefender Archetype persists
Show it across all 12 user-visible states and keep “Play Quiz Again”.
UXLifecycle state belongs to each application
The dashboard aggregates actions and statuses across applications; the applicant does not have one shared lifecycle state.
Product · BA · UXOpen validation items
Assign an owner and record the decision.
Journey logic and stage naming
Confirm exact stage labels and system status-to-stage mapping.
Product · BA · UXInternship in-progress fields
Confirm project, Mentor, period, dates, milestone and current task.
Product · BA · UXOffboarding checklist
Confirm tasks, required/optional rules, sequence, deadlines and completion logic.
Product · BAPost-internship action rules
Confirm availability and mandatory/optional rules for feedback, testimonial, certificate and LinkedIn.
Product · BA · UXLatest Activity event mapping
Confirm which workflow events become user-facing activity.
Product · BA · UXAdd to Calendar support
Confirm technical support and whether the CTA should be included.
Product · Tech · UX