Support CEG team with Customer Rating form

[foxintherain]

What

Design a feedback pattern that uses the new global forms component to collect customer feedback in a quick and easy way. Needs to work on multiple websites and different contexts.

The method used is CSAT scoring: a question with a range score of 1-5, where 1 is the least favourable experience combined with a question that elicits a simple qualitative answer.

Why

The CEG team would like to make the touch points across the journeys on our websites visible, comparable and actionable in the simplest way we can. In doing so we will be able to see which parts of an experience are causing the most issues in relation to the experience as a whole.

Done when

• [x] Design options shared from Niamh are reviewed by @foxintherain
• [x] Technical approach agreed with @benjclark @Heydon and @amyhupe
• [x] Interaction design finalised with Niamh
• [x] Content reviewed by @amyhupe
• [ ] Design Documentation drafted for elements and reviewed by @amyhupe and Niamh

Background information:

https://docs.google.com/document/d/1OPJf1YbSQ26F7x1XzrwU7uJYw6G-_f934OhpB0Cn9lc/edit

Draft for component documentation:

https://docs.google.com/document/d/1g4kaOj65_aV7OgOKMmjaHXVYlgCkq_AG6X8rkI_71uo/edit#heading=h.q35wsrq0a8eu

[foxintherain]

[foxintherain]

After discussion with Niamh and co, we've arrived at 2 interaction patterns:

Option 1

• Button would link straight to surveymonkey.

Option 2

After feedback from Nancy, Stephen C and Ed Hallet, Option 2 is preffered where the user is able to enter a response to the 5 point scale in the page.

• we need to do a little work to find out of this would actually be possible using the api of the standard tools we have available, and specifically Survey Monkey
• Next step is to explore this with FEDs from RE and CoCo domains. We will also get some advice from Holly on accessibility issues that could arise via Survey Monkey.
• After that, we will work with the domains to get this implemented

[benjclark]

Myself, @foxintherain, @amyhupe and @Heydon had a meeting yesterday. The summary:

• We think it should be its own component because:
  • It will have custom javascript
  • It does have its own distinct purpose that is separate to Global Forms (GF)
  • There is benefit to independently versioning it (not an issue when we move to design system level versioning)
• It is a composition of GF elements/styles therefore we should define a dependency on GF
  • If the concept of patterns (compositions of components) existed this would potentially be a candidate however would it be consumable as a pattern? how would consumers receive version updates to it, particularly its custom client side js?
  • We should document the dependency on GF clearly in the README
  • We should instruct consumers of this to import the stylesheet for GF which should cover the styling entirely (hopefully)
• We should implement pictographic radio buttons in GF regardless, that makes sense as something GF should have available
• Where possible we should abstract any client side js to brand context if it is a reusable helper or utility (e.g. something that dispatches dataLayer events)

[foxintherain]

Latest design iteration based on discussion with Niamh:

Questions for Frontend

• Can we hide some of the labels for the ratings to reduce cognitive load? Check on accessibility issues
• Can we progressively enhance the button so that a user only needs to select a rating to submit the form?

Next steps

• [x] Review content with @amyhupe
• [x] Show design in context for certain products: Pre-submission, Editorial Manager, Springer.com, Nature.com
• [ ] Look at testing emoji/pictograms to ensure user comprehension

[amyhupe]

@Heydon to review Ben's PR: https://github.com/springernature/frontend-toolkits/pull/792

[amyhupe]

To do: Talk to SPA team, user researcher for Snapp, Identity or user research team about whether we can observe and integrate some questions about this and our forms component, to validate our design and implementation.

@foxintherain

[foxintherain]

Had a catchup with Niamh where we discussed next steps for implementation and started an early draft for design documentation: https://docs.google.com/document/d/1g4kaOj65_aV7OgOKMmjaHXVYlgCkq_AG6X8rkI_71uo/edit#heading=h.82xuitcx5fqk

Niamh clarified that the question should be generic and not customisable.

[foxintherain]

Draft document now on GitHub: https://github.com/springernature/frontend-toolkits/blob/d79d22c812bdfaba7b254fc74ae77d5adf65336b/toolkits/global/packages/global-ratings-survey/README.md

[foxintherain]

Summer of last discussion on documentation:

Naming conventions

• For the “Experimental version” on the current page - we need a consistent approach terminology

How do people visit this page:

• Developers: Assumption is to first go to the overall documentation site
• Designers: More likely to go to the elements site

Demo

• First example could just be the component by itself for easier scannability

How we need explain how to use the component:

• This is when to use it, This is the process to use it for, This is who talk to:
• Use is decided by you / team
• Need to have a discussion between teams / product areas who are sharing the same journey
• Go through with Niamh so they know teams that are using it
• Designed for specific page location
• Elements should be there to help teams manage conversations
• Hand of to documentation site + overall documentation

[amyhupe]

@amyhupe to review documentation and send final version to James and Ben to review

[amyhupe]

We met a couple of weeks ago to discuss this. We agreed to:

• remove the pictographic radios from the forms demo and documentation for now, as we don't know of another use case for it apart from the customer satisfaction input (@Heydon)
• @amyhupe needs to review customer satisfaction input docs draft

[foxintherain]

Draft for component documentation: https://docs.google.com/document/d/1g4kaOj65_aV7OgOKMmjaHXVYlgCkq_AG6X8rkI_71uo/edit#heading=h.q35wsrq0a8eu

[amyhupe]

@amyhupe check with Ben what the agreement is in terms of documenting this.

[foxintherain]

RE this thread on slack on internationalisation: https://springernature.slack.com/archives/CNBTFLBLP/p1677848666832329?thread_ts=1677846487.105809&cid=CNBTFLBLP

We may want to include an instruction that we don't want to allow people to change the question for internationalisation purposes because of the risk of data corruption (which is why its hardcoded).