|
| 1 | +# Delegation notification for application instance access - User discovery and navigation |
| 2 | + |
| 3 | +- Status: Accepted |
| 4 | +- Deciders: Signing Task Force |
| 5 | +- Date: 2025-12-06 |
| 6 | + |
| 7 | +## Result |
| 8 | + |
| 9 | +- A1: Send correspondence message to delegatee's inbox with direct link to application instance, in addition to existing instance message under relevant "Aktør". |
| 10 | + |
| 11 | +## Problem context |
| 12 | + |
| 13 | +When implementing user-delegated signing flows, users are granted read access to application instances they need to sign. However, the current inbox structure creates a significant user experience problem for delegatees trying to find and access these instances. |
| 14 | + |
| 15 | +Currently, when a user (delegatee) is granted read access to an application instance, the only way to access the instance is through an instance message that appears under a different "Aktør" (the instance owner) in their inbox. This creates several usability issues: |
| 16 | + |
| 17 | +1. Delegatees cannot find the application instance in their usual work-in-progress section |
| 18 | +2. They must know to look under a different "Aktør" section |
| 19 | +3. They must know which specific "Aktør" owns the instance |
| 20 | +4. The discovery path is non-intuitive even for developers with internal knowledge |
| 21 | + |
| 22 | +User testing with internal team members showed conclusively that the current approach is too difficult to navigate, leading to the expectation of support cases from end users who cannot find delegated instances. |
| 23 | + |
| 24 | +## Decision drivers |
| 25 | + |
| 26 | +- B1: Reduce user confusion and support burden |
| 27 | +- B2: Provide intuitive discovery path for delegated instances |
| 28 | +- B3: Maintain existing functionality for instance owners |
| 29 | +- B4: Work within constraints of correspondence service architecture |
| 30 | +- B5: Ensure consistent notification experience (inbox + email/SMS) |
| 31 | + |
| 32 | +## Alternatives considered |
| 33 | + |
| 34 | +- A1: Send correspondence message to delegatee's inbox with direct link to application instance |
| 35 | +- A2: Modify inbox structure to show delegated instances in main work-in-progress section |
| 36 | +- A3: Add notification banner or widget to highlight delegated instances |
| 37 | +- A4: Keep current approach and provide user education/documentation |
| 38 | + |
| 39 | +### A1 - Correspondence message to delegatee (CHOSEN) |
| 40 | + |
| 41 | +Send a correspondence message directly to the delegatee's inbox containing: |
| 42 | +- Clear indication that they have been delegated access |
| 43 | +- Direct link to the application instance |
| 44 | +- Context about what action is required |
| 45 | + |
| 46 | +This is sent in addition to the existing instance message under the relevant "Aktör". |
| 47 | + |
| 48 | +### A2 - Modify inbox structure |
| 49 | + |
| 50 | +Restructure the inbox to display delegated instances alongside user's own work-in-progress instances, potentially with special visual indicators. |
| 51 | + |
| 52 | +### A3 - Status quo with documentation |
| 53 | + |
| 54 | +Maintain current approach and provide user guidance on how to navigate to delegated instances. |
| 55 | + |
| 56 | +## Pros and cons |
| 57 | + |
| 58 | +### A1 - Correspondence message to delegatee (CHOSEN) |
| 59 | + |
| 60 | +- **Good**: Supports B1 - provides clear, discoverable path to delegated instances |
| 61 | +- **Good**: Supports B2 - delegatees receive direct notification in their primary inbox view |
| 62 | +- **Good**: Supports B3 - does not modify existing functionality for instance owners |
| 63 | +- **Good**: Supports B4 - works within existing correspondence service capabilities |
| 64 | +- **Good**: Supports B5 - creates consistent notification experience across channels |
| 65 | +- **Neutral**: Creates duplicate pathways to the same instance |
| 66 | +- **Bad**: Increases number of messages in delegatee's inbox |
| 67 | + |
| 68 | +### A2 - Modify inbox structure |
| 69 | + |
| 70 | +- **Good**: Supports B2 - would provide most intuitive user experience |
| 71 | +- **Good**: Supports B1 - eliminates confusion about where to find delegated instances |
| 72 | +- **Bad**: Does not support B4 - would require significant changes to correspondence service architecture |
| 73 | +- **Bad**: Potential impact on B3 - structural changes might affect existing workflows |
| 74 | +- **Bad**: High implementation complexity affecting multiple teams and services |
| 75 | + |
| 76 | +### A3 - Status quo with documentation |
| 77 | + |
| 78 | +- **Good**: Supports B3 - no changes to existing functionality |
| 79 | +- **Good**: Supports B4 - no technical implementation required |
| 80 | +- **Bad**: Does not support B1 unless the end users somehow find the documentation |
| 81 | +- **Bad**: Does not support B2 - maintains unintuitive discovery path |
| 82 | +- **Bad**: Does not address underlying UX problem |
| 83 | + |
| 84 | +## Decision rationale |
| 85 | + |
| 86 | +The decision favors A1 (correspondence message to delegatee) based on user testing results and the need for an immediate, practical solution that works within existing system constraints. |
| 87 | + |
| 88 | +Key factors in the decision: |
| 89 | +1. **User testing evidence**: Internal testing demonstrated that even technically knowledgeable users struggled with the current approach |
| 90 | +2. **Practical implementation**: Solution works within existing correspondence service capabilities without requiring architectural changes |
| 91 | +3. **Immediate relief**: Provides direct path to delegated instances without waiting for larger inbox restructuring |
| 92 | + |
| 93 | +While A2 (modifying inbox structure) might provide the most elegant long-term solution, it would require extensive cross-team coordination and architectural changes. A1 provides immediate value and can coexist with future inbox improvements. Note that this has been discussed with "Arbeidsflate". |
0 commit comments