Two systems, one customer experience
Connecting the systems was the technical problem. The design problem was helping people understand ownership, consequences and recovery.
Altus customers with large or complex schedules often used Microsoft Project for detailed scheduling and Altus for resource management, financial management, portfolio visibility and reporting.
I owned Product Design for Altus for Project from its initial development through multiple releases. The difficult questions were rarely about individual screens. They were about what happened when two mature products with different rules began sharing responsibility for the same schedule.
Which system owns the information? What changes when data moves between them? What must be protected? What happens if an action only partly succeeds?
We could not remove that complexity, but we could make the important consequences understandable and predictable.
Designing around what the system knows
Three principles guided much of the interaction design.
Make ownership visible. Users needed to understand whether a schedule was connected and which system was responsible for different parts of the workflow.
Protect information people already trust. Historical and approved information required stronger safeguards than ordinary edits. Where the system knew an action was unsafe, the better experience was often to prevent it.
Support informed decisions. When the system could not safely decide for the user, the interface needed to explain the consequence before asking them to act.
These principles shaped connection states, publishing, resource mapping, protected historical information and recovery when processing failed or only partly completed.
Changing the job of unlinking
To a user, “unlink” sounds relatively low risk. In Altus for Project it could stop synchronisation and change what happened to information previously managed across both products.
The early experience treated unlinking mainly as a command requiring confirmation. Support and partner feedback showed that the user first needed to understand what would be true afterwards.
I reframed the question from “How do we make the warning stronger?” to “What does someone need to know to make this decision deliberately?”
The revised experience made the affected project explicit, explained that synchronisation would stop, clarified the consequences of each choice and gave clearer guidance about what happened next.
The interaction changed from confirming a command to supporting an informed decision.
Designing beyond the happy path
As the capability matured, reliability became increasingly important. Publishing could involve large schedules, mappings, historical data and processing across two systems. A useful experience had to account for more than the happy path.
My work included validation before consequential actions, progress feedback while processing, and clearer recovery when publishing failed or completed only partly.
Microsoft's planned retirement of Project Online later increased the importance of Altus for Project for organisations migrating while continuing to use Microsoft Project Desktop. Other teams owned the migration tooling. My responsibility remained the experience customers depended on once their schedules were operating across Microsoft Project and Altus.
The strongest outcome was not making two complex systems feel simple. It was helping people form more accurate expectations about what the system would do, what it would protect and what they could safely do next.
If the system knows an action is unsafe, protect the user. If it does not know the right answer, help the user understand enough to decide.
Continue with access
For a deeper look at the work, including additional screens, decisions and supporting evidence, enter your passcode or request access.