Visual review is hard to find / confused with review app (#227049) · Issues · GitLab.org / GitLab

Visual review is hard to find / confused with review app

Problem to solve

As a product manager, I want to quickly launch a review app from the MR page, so I can review changes and leave feedback for my team async so they aren't disturbed by my comments.

From a GitLab PM "I always click on Review, before I remember I want the other button. I get this wrong every single time 🤦"

Intended users

Any user who can make use of review apps and/or visual reviews. Especially:

Parker (Product Manager) - who has the user story above.

User experience goal

The user should be able to click a button and open a review app without guessing what they mean.

Let's take advantage of changing this experience to also make starting to use Visual Review tools easier. We know that users with muscle memory / ignore memory will get caught up on a visual change so let's take advantage of that by introducing an easier VRT experience at the same time to drive adoption.

Proposal

Further details

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

### Problem to solve

As a product manager, I want to quickly launch a review app from the MR page, so I can review changes and leave feedback for my team async so they aren't disturbed by my comments.

From a GitLab PM "I always click on Review, before I remember I want the other button. I get this wrong every single time :face_palm:"

### Intended users

Any user who can make use of review apps and/or visual reviews. Especially:

* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) - who has the user story above.

### User experience goal

The user should be able to click a button and open a review app without guessing what they mean.

![Screenshot_2020-07-06_09.43.02](/uploads/e4d6ccd497cec23f7620aef3479e7a95/Screenshot_2020-07-06_09.43.02.png)

### Proposal

### Further details

### Permissions and Security

### Documentation

<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change

* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

### What does success look like, and how can we measure that?

### What is the type of buyer?

### Is this a cross-stage feature?

### Links / references

Edited Jul 22, 2020 by James Heimbuck