Project 1 brief 

Provide a name for the scheduling feature in SAP Analytics Cloud, the flagship Business Intelligence suite from SAP. 

​

User Research

In order to understand the capabilities of the functionality and it's purpose, as well as to get a holistic picture of the new feature related to scheduling stories a.k.a reports within SAP Analytics Cloud, I engaged with the product stakeholders as well as customer advocates such as product managers and product experts. We already had a stable and popular on-premises version of Business Intelligence.

​

I had to understand:

• Target audience

• Overarching needs

• How are they different from the on-premises customers?

• What will be the overlap between on-premises and cloud customers?

• How different or similar will the feature be as compared to the on-premises version?

 

Competitor Research and Analysis

I gathered information on applications already offering this feature, such as Tableau, Adobe Analytics, Zoho, and so on.
 

The analysis covered:

• Target users

• User workflows/User journeys

• Feature name and UX microcopy

• Onboarding support

• In-app assistance
   

I drew comparison between the workflows and devised the critical path overlap between the different workflows from the diverse list of similar applications from different companies.

 

Persona Identification

Once I got clarity on the user personas, I narrowed down on existing on-premises customers who create and consume reports. The personas included Business Analysts, Financial Analysts, Marketing Executives, CFOs, Business Intelligence Admins and so on. These end users also comprised a broader set of personas such as Business Intelligence Admin (BI Admin) working extensively on the on-premises version, Cloud users, people newly introduced to the Cloud version of the software, as well as people using other analytics applications.

 

User Interviews

With the help of the product teams and the customer success teams, the designer and I shortlisted potential customers to understand their mental model in order to propose the critical path adopted by users. I needed to understand the expectations of the users on where they would like to start their journey in the product in order to schedule their reports. It was important to understand the various intersections to be able to suggest a scalable, yet focused term for the feature.

 

Card Sorting

I, along with the lead designer, did a card sorting exercise with the target personas we interviewed, where we introduced the terms such as “Publication”, “Scheduling”, “Bursting”, “Sharing”, “Automatic Sharing”, and so on for the feature nomenclature.

 

Prototyping

Once we understood the mental model of the target personas and also keeping in mind the research findings, we drew up the most critical path, thus, creating a low fidelity prototype.

 

Challenge

Existing on-premises users transitioning to the Cloud may find it difficult to relate to the new term called “Scheduling a Publication”. In the older context, Publication is a process or more so, a verb while in the Cloud context Publication is an object or a noun.  However, in a real-world context, the act of automatically setting something to run at regular intervals is commonly termed as Scheduling.

 

Stakeholder Management

I had to engage in several rounds of discussions with the terminology team, as well as the product and design teams to convince and back up my contention supported by the research findings as well as principles of user-centered communication.

​

I had to counter argue to support my recommendation against the biased opinion of the product teams who were used to using the term publication within the on-premises version and were not considering how an end user might perceive the feature. The various research activities and design methods helped me do it with ease and conviction.

 

Terminology Team intervention

​

 

 

 

 

 

 

​

 

Outcome

On analyzing the mental model of the end users as well as the card sorting exercise and findings from the field research activities, I got a buy in from the product and design teams, and I narrowed down on “Schedule Publication”. The term was then proposed before the terminology team, whose unbiased opinion favoured the use of the term in the product.

​

The feature is now called “Scheduling a Publication”. While referring to the act of scheduling and sharing reports on the interface, it is termed “Schedule Publication”.

 

Factors that Influenced the Final Term

I’ve used the term Publication here for it to be scalable and accommodate future artifacts that can be scheduled. When the requirement was given to me, it was only Stories (Reports) that could be scheduled. I did not use the term Schedule Story, as it would’ve been very specific and further iterations would confuse customers and affect the learnability of the product. I omitted the definite article “a” between “Schedule” and “Publication”, because more than one publication can be scheduled at any given point in time. I did not use the plural form of Publication – Publications, because one can schedule a single publication as well.

​

Scheduling is now a part of the sharing workflow. I have used the verb in the present tense to represent a task-based UI label. I have adhered to one of the ten heuristics principles “Recognition rather than Recall”. As per the internal research findings it was concluded that a majority of the test subjects related easily to the term “Schedule” for automatically running activities that need to be performed at regular intervals, thus reducing the cognitive load on customers when they are introduced to a new feature for the product.

​

In the product

​

​

​

​

​

​

​

​

​

​