GitLab UX Scorecard, 11 Apr 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: UX Scorecard: New Docs search, heuristic evaluation

Description

https://gitlab.com/gitlab-org/gitlab-design/-/issues/2280

Dan Mizzi-Harris Product Designer, Manage: Foundations

A

A product designer in the foundations group: this is my heuristic evaluation of the new Doc search just to walk through for the ux scorecard.

A

This one summary I think the new Doc search will have a result of a c plus. um My top recommendations are ensuring the browser back button doesn't cause data loss. Crease I think we can increase the use of confidence when there are no Auto Suggestions. By showing their search term, we can help shape the mental model and how people use the search better. If we recommend useful or popular searches and I, think the usability in the visual polish can increase if we use consistent search input.

A

Styling I've linked the research issue, where there's more details and links to all of the raw files and data used.

A

So first just give a disclaimer, but this is a heuristic evaluation. No users were consulted or observed as part of this and I've used the heuristics. The guidelines that are listed in in our handbook.

A

There's also no jobs to be done presented as part of this effort, and so I've created a pseudo job to be done. I've listed here and a testing scenario after testing. It was pointed out that the main use for docs isn't troubleshooting, but it's for feature Discovery and learning about specific features. I re-ran the study with that framing in mind, and there were no real differences so um rather than rewrite that new study app we're looking from this job to be done, but whichever way we frame it, the results I think is the same.

A

So here's, let's have a look at the user Journey that I followed. This is documented in a mural where I've marked my expectations for user thoughts, their pain points opportunities and the experience and some notes about some of the particular heuristics, as well as documenting the steps and the stages as part of this experience.

A

So, let's walk through that now, Step One is arriving at the Docks like I mentioned, I, think showing recommended or popular searches near here can help make.

A

Help shape the user's mental model for how search works and help them make good construct. Good searches, useful searches, that'll help them find the answers that they need, but a caveat to that these recommendations must be good recommendations, so there's some work there to ensure that there'll be good ones.

A

Next step is starting searching, the auto suggest is really responsive. It starts working really quickly, even after a single character, which I think is great, um but if, if the the term doesn't have any auto suggested options, this might look like it's broken or there will be no results, so I'd recommend keeping the same style in, but having the user searched him as an option underneath something else. I noticed, especially when I did the rerun of this with a different job to be done.

A

If we've got high confidence that this is only one realistic result clicking, this should go straight through to the page rather than having that intermediary step. It could help users get to where they need to go faster and also increase. Their trust and confidence in these Auto suggests.

A

Search results then, after searching either with the enter key or hitting the search button or tap in one of these bottles suggested searches.

A

There's a lot to like here, filter Supply straight away, but they do rely users knowing how the dock sites are constructed for them to be really useful and there's also not a lot of information about where, in the site structure a page exists, so, for example, Services here turned out to actually be only for CI CD and wouldn't have helped our user.

A

With this query, so there might be an opportunity to bring more of the metadata out of this View to help users decide which would be most useful for them so clicking on the results takes us through to the results page.

A

This information in the preview is lost. This is a really long page and what's visible here, doesn't match what was visible here so consider highlighting the part of the page that was visible in the preview and there's a couple of different techniques you could use to help people get there faster hit. The back button to amend the search great search term is retained. I can easily edit my query, but I've lost my filter selection and if I was on page four and scrolled down the page, I get reset to page one.

A

So it's really important here that the back button matches user's expectations of bringing the link back exactly where they were before.

A

It's really easy to start a new search from anywhere in the darks. We have the search input in the header and on there search results page something that might be helpful when making a new search has been able to see a bit of your search. History might help with workflows that are often repeated, but infrequent and help users retrace their steps if they found something useful in the past and then the last page I looked at is the no results.

A

It's great, that this isn't a dead end, and there are a couple of different uh opportunities here if we wanted to improve or try and improve the performance of this page.

A

So some of the key opportunities I'd like to call out as mentioned bringing some sense of useful or popular searches, might help users use the search better, and the author suggests, if we've got high confidence, that the page that their Auto suggested suggesting is one single page, another bunch of pages that needs to go to a search results, skip that results page and go straight to the docs page with the information again. This is uh where we've lost. The information from the preview of a snippet of an answer was seen there.

A

It can be hard to refine that on the docs page and there's an opportunity around search history and how that might help some users in their workflows.

A

So some of the big pain points I noticed the returning to the search results loses some of the user's work. It might take them a little while to find out to retrace their steps work out where they were um do a bit of rework.

A

The search is where there are no autocomplete or to suggested results. Micro Zeus uses confidence in search. They might think that there's no point researching this, because there will be no results and so I think there's some opportunities around that and like we saw that serious example. When the page titles aren't explicit, there's limited information about the scope and context of a page, so some of the stuff I thought was really good is also suggest.

A

If it gives good suggestions is really likely to benefit users both with how they build their Search terms, but also confidence that they're gonna find what they're looking for the search input was um styled in a way that was easy to find and great best practices like no placeholder text having a real clickable button for a submit, it's great to see their no results, page not be a dead end and the speed of the auto suggest and the filters how they're applied automatically makes the docs feel very responsive.

A

So also, while looking at this I noticed a few areas where we could add, some visual polish one is add in a bit of depth to the page visually, emphasizing the active search when I searches in progress really bring the user's attention in bring back some of the other distractions on the page, which we could do by adding an overlay like. In these examples.

A

Because it adds some Polish by having consistent search inputs, we've got three different search inputs out on the current implementation, using different icons, different, clear buttons If. We bring these all to use the same style. It should help increase the balance between the pages, but also allows for matching height with other elements in this bar.

A

These examples use the pajamas component.

A

Another opportunity is building a shared visual language between the input and the suggested results, primarily these use in two different styles they're, quite um jarring.

A

Here's an example of what it could look like if we created some Styles based on. Perhaps the drop down component.

A

And the last visual polish that I'd like to call out twos I anything we can do to prevent layout shift. So currently, when you load the page there's a moment where there is no input and any input appears and the rest of the page gets pushed down. If we added a placeholder that had the right dimensions, we could mitigate this and it would think also have the benefit of letting users know what's happening. There's something loading here.

A

The best case scenario is we get the performance to the point where we don't need one of these mitigations, but if we can't something like this could work so again, just to recap: uh I think this would score a c plus using our heuristics.

A

um My top recommendations are around the back button, behaviors how we can increase Comfort user confidence when there are no Auto suggested Search terms how we can shape users. Mental models help them usage better by recommending useful or popular searches and increase the usability and some of the Finesse with consistent search input. Styling again, there's more detail in the research issue, but thanks for listening, I hope this was helpful.