Commit a85ec4e1 authored by Taurie Davis's avatar Taurie Davis Committed by Paul W
Browse files

Product Design workflow pages: fix copy issues (follow-up to !20275)

parent 239a95f5
Loading
Loading
Loading
Loading
+6 −6
Original line number Diff line number Diff line
@@ -11,8 +11,8 @@ For how you should **use AI in your design work**, see [AI usage](/handbook/upst

The main difference between designing AI features and traditional features is uncertainty. With Large Language Models (LLMs), we face uncertainty in both:

What users will do or write
How the LLM will respond
- What users will do or write
- How the LLM will respond

As designers, we have less control over user inputs and system outputs than we're used to. This guide provides tools and methods for working in this uncertain environment, supplementing your existing design toolkit.

@@ -42,7 +42,7 @@ Instead, use the following page to help you:

#### AI Engagement Guidelines

We recommend that designers create AI Engagement Guidelines before moving into the design phase. This is a framework proposed by [People + AI Research](https://pair.withgoogle.com/) at Google that we propose to use here. This framework provides a foundation for establishing alignment on AI related design and technical requirements. We have adapted the framework into our own Figjam template {tbd link}.
We recommend that designers create AI Engagement Guidelines before moving into the design phase. This is a framework proposed by [People + AI Research](https://pair.withgoogle.com/) at Google that we propose to use here. This framework provides a foundation for establishing alignment on AI related design and technical requirements. We have adapted the framework into our own Figjam template.

Resource: [Interaction Design Policies: Design for the opportunity, not just the task.](https://medium.com/people-ai-research/interaction-design-policies-design-for-the-opportunity-not-just-the-task-239e7f294b29).

@@ -135,7 +135,7 @@ Example: You’re building an automated API documentation generator
- Structure: Standardized sections for endpoints, methods, parameters
- Style: Technical reference format with standardized terminology

While we can't predict exact outputs, defining these elements helps create consistent user experiences and better prompt engineering. Experiment with creating your ideal output using Claude, LangSmith, or locally.  {link to docs}
While we can't predict exact outputs, defining these elements helps create consistent user experiences and better prompt engineering. Experiment with creating your ideal output using Claude, LangSmith, or locally.

#### LLM Judge Evaluation

@@ -216,7 +216,7 @@ UX testing ensures designers identify any potential issues that evaluation might

- UX testing
  - Focuses on how to interact with the interface
  - Tests specific features, workflows, happy pathes, unhappy paths
  - Tests specific features, workflows, happy paths, unhappy paths
  - Identifies usability issues and friction points
  - Helps refine interaction patterns
- LLM Evaluation
@@ -230,7 +230,7 @@ UX testing helps stakeholders better understanding user behaviors, strategies, a

For example, where the LLM Evaluation might measure if an AI properly refactored a function to be more efficient, UX testing examines how developers iteratively describe their refactoring goals, interpret suggested code changes, handle merge conflicts, and learn to trust or verify the AI's recommendations.

To to UX testing for a new generative AI feature, return to the data set created at the beginning of the project. You will use that data set to test the performnace of the solution. If you are testing a conversational feature, you'll need to ask followup questions related to the data set to ensure the model retains proper context and answers properly.
To do UX testing for a new generative AI feature, return to the data set created at the beginning of the project. You will use that data set to test the performance of the solution. If you are testing a conversational feature, you'll need to ask followup questions related to the data set to ensure the model retains proper context and answers properly.

UX testing should include testing happy paths and unhappy paths.

+1 −0
Original line number Diff line number Diff line
@@ -12,6 +12,7 @@ Our primary design tool is [Figma](https://www.figma.com/). As a product designe
Anyone else in GitLab can access your files when you either share the file URL or invite them directly via email, but we ask that you only give them “can view” permissions. Anyone with “can edit” permissions is considered a paid seat and must have approval. A user with “can view“ permission will still be able to comment on and inspect design files.

If you want to invite team members to collaborate on your FigJam boards, you can do this by starting an [open session](https://help.figma.com/hc/en-us/articles/4410786053911-Invite-visitors-to-an-open-session). This feature allows for team members with or without a FigJam license to have edit access as long as the board has been enabled for an open session and the link for the board is shared with them. Open sessions will only run for **24 hours** at a time. If you want team members to be able to edit your files across multiple days, you will need to restart the open session each day.

If there are concerns about keeping information on your Figjam board SAFE, you can add [password protection](https://help.figma.com/hc/en-us/articles/5726720100247-Add-password-protection-to-files). That way only those with the password can edit the board when the open session is enabled.

GitLab has a public Figma profile where anyone can duplicate or remix files we have published. You can view our profile under the Community tab of the GitLab team section, or navigate to https://www.figma.com/@GitLab.
+1 −1
Original line number Diff line number Diff line
@@ -42,7 +42,7 @@ Single Engineer Group (SEG) MRs should be reviewed by the design DRI of the impa

MR review requests are the [top priority for Product Designers](/handbook/upstream-studios/product-design/workflow/capacity-management/#priorities). Respond according to our [review-response Service-Level Objective](/handbook/engineering/workflow/code-review/#review-response-slo).

Balancing MR reviews with other tasks can be challenging. To avoid disruptions, block daily time to review MRs (for example, 30 minutes or 1 hour per day). If you struggle with reviews, [manage expectations](/handbook/engineering/workflow/code-review/#managing-expectation)) with MR authors and reassess your capacity, considering any upcoming time off. If needed, work with your manager to reassign the MR.
Balancing MR reviews with other tasks can be challenging. To avoid disruptions, block daily time to review MRs (for example, 30 minutes or 1 hour per day). If you struggle with reviews, [manage expectations](/handbook/engineering/workflow/code-review/#managing-expectation) with MR authors and reassess your capacity, considering any upcoming time off. If needed, work with your manager to reassign the MR.

### Monitoring MR review workload

+1 −1
Original line number Diff line number Diff line
@@ -81,7 +81,7 @@ Resources:
- [Use Review Apps in MRs](https://docs.gitlab.com/ci/review_apps/#how-review-apps-work)
- [Log into Review Apps](https://docs.gitlab.com/development/testing_guide/review_apps/#log-into-my-review-app)
- [Prevent auto-stopping](https://docs.gitlab.com/development/testing_guide/review_apps/#auto-stopping-of-review-apps)
- [📺 Toggle feature flags](https://www.youtube.com/watch?v=VBo667LiwBQ). You can enable feature flags using tools like `curl` or [Postman](https://www.postman.com)..
- [📺 Toggle feature flags](https://www.youtube.com/watch?v=VBo667LiwBQ). You can enable feature flags using tools like `curl` or [Postman](https://www.postman.com).

## Help