SAP Roadmap

Revamp roadmap website to make overloading release information consumable


Redesign and launch the website from scratch in 2 months to be demo'd in annual conference and customer meetings


I refined personas and user goals, prototyped rapidly and worked with engineers to launch a responsive website with a team of 3 designers


How might we deliver the vision of "consumable" roadmap for complex enterprise portfolio?

Current roadmap users felt overwhelmed by the overloading information laid out in the sea of PDFs. Even if they manage to find the right document, they could not grasp the values of releases relevant to their roles.

We were tasked to evaluate and revamp the current SAP roadmap site to support users to digest the overloading releases efficiently and know what's coming for their businesses.

Solution quick peek

A new face of enterprise roadmap

We designed, validated and delivered a new, fully-responsive website that focuses on allowing users to easily navigate and digest the complex enterprise product information.

Process overview

Iterate fast to drive project at different scales

While this time-bound project didn't start with a defined set of requirements, we iterated rapidly to drive the project with design. Not having time for a rigorous discovery research, we actually began designing at the very beginning. And along the way, every stakeholder demo and user testing at conferences became our source of data. We iterated and delivered hi-fi prototypes to prompt use cases, pain points, and feedback for interactions and UI.

This approach helped us to validate assumptions at different scales, from evaluating project goals at the beginning to examining usability later on.


Align project goals with team and stakeholders with design

I also fine-tuned our personas to align vision with the team and identify the goals and values for different type of users. This also helped us to communicate to stakeholders about why the site needed a revamp and what would the outcome look like.

Design & validate

Iterate and validate assumptions through design

Due to tight timeline and resources, we dived into delivering mockups rightaway with assumptions based on stakeholders' asks. The first version was delivered in a day to advocate and gain resources for the project to move forward. We then kept iterating and testing to uncover concrete user needs/goals from the field.

User need #1

Easy and digestible way to consume overloading information

"There are way too much info. It's hard to digest."

Previously, users had to triage through the sea of PDFs to find roadmap information. One major pain point we found out is that locating and digesting information was difficult.

User need #2

Different goals lead to different way of navigating

"I hope there would be an easy way to go to technical requirements directly. I know what I want."
"I would like to see what offerings can help my business."

Reflected on our personas, there are two types of users, business and technical, that have different goals for roadmap. While our early design failed to support locating technical details fast, we iterated on the design to serve the diverse audience.

User need #3

Relevancy is the key

"There are too much marketing fluff. I just want to find what is relevant to me."

Feedback for our early iterations turned out that customers see most of the description as marketing fluff and did not engage with the content.


Smooth cross-functional collaboration with tangible artifacts

To ensure smooth design delivery, we created sitemaps, specs and prototypes to communicate design, and synced frequently with engineers to make sure we covered different states of design. We also maintained a style guide to make sure our design was consistent among all designers.

Design highlights

Easy navigation for complex data

We broke down and prioritized the information into digestible chunks and re-defined the information architecture. It allows users to skim through the releases more easily and offered the ability to dive deeper

Multiple paths for 2 types of users

We defined 2 major user journeys based on the personas:

1. Technical users could make use of the search tool to locate specific release information

2. Business or new users can browse through the product/process offerings to find out the values that can be brought to their businesses

Personalization to drive relevancy

To make roadmap "relevant" to users, we introduced a new feature: personalization. Taking advantage of account-based user entries, the new roadmap can keep users updated about their existing solutions' new releases, and recommend them roadmaps based on their interactions with the site.

Re-evaluate product vision

Roadmaps at SAP were originally treated as a marketing piece. Our research found it against the user goal, which is to know what’s coming up for their offerings and be prepared for necessary resource allocation. Our new design brings focus to the product releases and maximize the efficiency of consumption.


"This is the right way to go!"

The new roadmap was announced in SAP's annual conference and rolled out to 100% customers with a lot of positive feedback. This project also defined an operationalized channel for product teams to collect roadmap information more efficiently.

"This makes less work on my part and provides a common language for my customers. I would copy the image for a customer presentation."  - Consultant from Mindtree
"I like the structure and simplicity. It makes finding upcoming product features easy." - Presales at SAP

While the following QA and support of the roadmap website had been handed over to another team at SAP, our design and research insights have been the foundation to keep driving the product direction. The design has won Red Dot Design Award 2020.


How to make design scalable for changing requirements?

One of the biggest challenge of this project is changing requirements. Initiating as a "proof of concept", the project goals turned into production halfway with executive decision. We strived to maintain thorough documentation, systemize design components, and work closely with engineers to support this decision. I also learned that presenting design sometimes is not for just taking in feedback and iterate, but it is also a way to communicate back to stakeholders about our vision and why we think this is important.

One thing we didn't do but I think is critical was to align and set stakeholder expectations early on. While the team tried to push forward the vision of consumable SAP, we didn't adopt the existing branding style and libraries. This took us extra time to evaluate the component interactions, accessibility, etc., and we also got a lot of pushbacks from stakeholders later on when it was close to roll out. Eventually, the product was launched branding compliant.