Increase the quarterly average of researched issues from 12.7% to 20%.
Average of 11.11 (16%), 12.0 (10%), and 12.1 (13%) milestones is 13% (total researched issues/total issues).
GOOD:
Average for 11.9 and 11.10 milestones was 7%. 13% represents a large increase.
BAD:
We fell far short of our Q2 goal.
The team noted that research that either invalidates a solution or that is performed on an issue that ends up getting pushed to a later milestone does not end up counting toward our total.
TRY:
Change how we're tracking validation issues.
All validation related activities will have their own issue.
We will apply the UX label and either the problem validation or solution validation label to research issues.
Our goal will change from being focused on a percentage of effort to instead reflect a number of "validation" issues. This will make it easier to track where and how validation efforts are occurring.
Christie Lennevillechanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community. Increase the quarterly average of researched issues from 12.7% to 20%. to FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community.
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community. Increase the quarterly average of researched issues from 12.7% to 20%. to FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community.
Christie Lennevillechanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider Gitlab community.
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic (and less reactive) by basing a larger percentage of our experience decisions on feedback from the wider Gitlab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider Gitlab community.
Mark Pundsackchanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider Gitlab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community.
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider Gitlab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community.
Christie Lennevillechanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 0%
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 0%
Address current friction and risk when trying to submit request and get actionable research?
Maybe set research runway expectations so teams know how far in advance they need to submit a research request to get the actionable research they need on time?
Reduce research request process friction if we can?
Make stage-level research via designers easier and more "official"?
Maybe give designers access to users and research templates so they can conduct research (e.g. user test email script, user testing script, findings doc).
Work with PM's to see UX research as a valuable form of milestone work?
@sbouchard1 These are great points! My hope for the future is that the research team can focus more on strategic and exploratory research, and only support and guide us Designers in stage/issue specific research, where we are more responsible for the execution. This would make the process a lot faster and more flexible.
I also just started another initiative where the Editor team is going to have a recurring Think Aloud usability study each month gitlab-org/ux-research#237 (closed). These will not only be recorded, but I'm going to have at least one engineer joining each of these sessions so that we have a counterpart to our dogfooding approach that focuses more on another user group with other challenges. It also helps a lot with one major goal of mine, which is exposing other user types and common problems with our UI directly to our engineers.
My hope for the future is that the research team can focus more on strategic and exploratory research, and only support and guide us Designers in stage/issue specific research, where we are more responsible for the execution. This would make the process a lot faster and more flexible.
100% yes
I also just started another initiative where the Editor team is going to have a recurring Think Aloud usability study each month gitlab-org/ux-research#237 (closed). These will not only be recorded, but I'm going to have at least one engineer joining each of these sessions so that we have a counterpart to our dogfooding approach that focuses more on another user group with other challenges. It also helps a lot with one major goal of mine, which is exposing other user types and common problems with our UI directly to our engineers.
Maybe give designers access to users and research templates so they can conduct research (e.g. user test email script, user testing script, findings doc).
I hear you. This has been on my mind for a very long time (Skip to 8m12s to hear me discuss 'open sourcing' UX Research). Unfortunately, we've not had the capacity within the UX Research team to drive this effort forwards - until now! We will be adding a host of training resources and templates for designers, PMs and anybody else who wishes to conduct research to the handbook.
The UX Research team will lead this effort, but we welcome input from designers:
Review the content and let us know whether it's understandable/where we can improve.
As you hone your UX Research skills, share your expertise. Add your own tips and tricks.
Address current friction and risk when trying to submit request and get actionable research?
I'm curious to understand more about the current friction. What difficulties are you experiencing with the request process?
I don't have specific friction feedback, but I thought others might as we increase requests and stress test the process.
Fair enough. If anybody is starting to feel friction, please do reach out to me (this can be 1:1 in confidence if preferred). It's important that we understand where bottlenecks are occurring so that we can address them.
Christie Lennevillechanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 0% to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 50%
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 0% to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 50%
Christie Lennevillemarked the checklist item Track relevant issues with a "researched" label. as completed
marked the checklist item Track relevant issues with a "researched" label. as completed
Christie Lennevillechanged title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 50% to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 65%
changed title from FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 50% to FY20-Q2 UX OKR: Make GitLab UX more strategic by basing more of our experience decisions on feedback from the wider GitLab community. => 65%