Search drives almost everything online. While lots of us bookmark pages or click on links that take us from one website to another, typing keywords into a search engine and hitting ‘Return’ is how most web users, most of the time, try to find what we’re looking for.
When using search on a specific website (versus a search engine), we want an input box that allows us to see most, if not all, of the words we type in for our search. Yet you’ve probably had the experience of typing search terms into a too-small input box. Maybe the box is too short, so the text shows up looking tiny. Or just as frustrating, your query runs too long and scrolls out of sight.
User-experience gurus Nielsen Norman Group have the data to prove that these small search boxes are not just your imagination: “The average search box is 18-characters wide, [and] 27% of queries were too long to fit into it.”
Better to design a search-input box — or really, any kind of box where the user types in text — to be too wide than too short. And on the taller side, as well, so that there’s some white space around the words.
Don’t box in your users; give them the space they need to quickly review and revise their query before they submit it.
I’m a very lucky person. I haven’t experienced anything that would qualify as a major traumatic event, and my life isn’t generally a series of inconveniences. Plenty of other people don’t have that kind of good fortune. And since I’m in the business of user experience (UX), I want to use this blog post to explore something I learned about at a recent UXCamp event that I attended: the less frequently considered usability strategy called trauma-informed UX.
Trauma-informed UX most immediately affects people during or after a traumatic experience, but also during a relapse. These are users who come to an organization because they need help dealing with trauma, including:
- Patients living with a serious disease or injury.
- The loved ones of survivors and patients.
The main secondary audiences include:
- The greater communities that these survivors and patients will return to.
- Medical, law-enforcement, legal and social-services workers serving survivor and patient and populations.
- Donors and financial entities that provide support to these workers.
Trauma-informed UX also should consider those who’ve previously experienced a traumatic encounter with an organization that was supposed to help them. A straightforward example would be a crime survivor who’s had a negative interaction with their local police department or emergency room. A less-obvious example that The Marshall Project recently wrote about: juveniles once held in California detention facilities.
In an online survey, California’s state and community corrections board asked formerly incarcerated children and their families how the state could improve juvenile detention. In addition to “the childishly predictable [comments] — I didn’t get the bunk I wanted; they punished us all as a group,” survey respondents provided thoughtful and detailed recommendations including “more vegetables, more dental care…, [and] an easier system for sending academic transcripts from school to jail and back.”
I love that corrections officials asked for feedback from their users so the state could better serve these families and their communities. Individual interviews are my preferred UX research tool, though in this case, it would have been too expensive and time-consuming to do interviews.
Regardless of the tool you use to get user feedback, with a trauma-informed UX process, there are additional and more delicate considerations that you must address:
- Are you dealing with a user population that needs to worry about physical or digital surveillance?
- Can you streamline the experience to give traumatized users more control of the time they spend dealing with your organization?
- Is a website, an app, or an SMS-based experience the best way to serve users who are concerned about surveillance and time?
- What legal requirements must your organization meet? This can include patient confidentiality or client anonymity.
While you’re doing user research for a project that will serve users affected by trauma, or getting user feedback after the project launch, focus on speaking to those who already have healed — they’ll be more open to sharing their experiences because they’re not currently living the through the trauma.
What other nuanced usability considerations have you come across?
I recently came across some client reports that, when initially run with search criteria, looked correct and displayed properly. However, that all changed once a user selected pagination.
The search results soon began to look like nothing I’d searched for, and after a few clicks of Next and Back I could produce errors. When I drilled into the code, I found that the results were ordered by date, but the pagination used the ID of the record. Using the record ID would have been fine if we were only displaying a dump of the data and ordering it by ID, but to have a functioning useful report, this did not work.
I needed a way to order by any report column header, and for the pagination to keep intact the ordered by results as a user moved between the pages. After some quick research I came across the SQL Server function ROW_NUMBER(), used in conjunction with OVER(). This was exactly what was needed to accomplish the report column sorting and the pagination honoring the order throughout the pages.
The result: Users were now able to paginate results, as well as sort by column heading, making for a logical display.
Have you found any tips or tricks for search results?
UI problem solving on mobile devices can be quite a challenge when it comes to navigation. A simple Google search for “Responsive navigation” will yield countless possible navigation formats that web developers have used so far.
We’ve recently taken on some responsive projects where we had to make some fairly large navigation work on mobile devices as well. One site in particular is The Catholic Health Association of the United States: http://www.chausa.org.
A long vertical navigation accessible through scrolling is what we aimed to accomplish in this case, allowing the user to navigate to just about any page on the site right from the home page.
Taking this a step forward, I’ve set up a demo of how this concept can work with an expanding navigation.
The scrollbar itself is hidden by the overlapping content that’s pushed off to the right.
By toggling a class on the body, the content gets pushed aside to reveal the hidden navigation. The content doesn’t fully leave the page but remains somewhat visible for two reasons:
- It slightly overlaps the navigation behind the content and will hide the unwanted scrollbar from view
- it serves as a trigger to pull the content back into full view when clicked on
Since we are dealing with big navigation in this example, the content is fixed on the screen and does not scroll along with the navigation. Doing it this way makes it less distracting for the user. It also ensures that it stays in view in the event that the navigation becomes longer than the page itself.
The +/- button is used to reveal additional sub menus in the navigation. This treatment gives the user two options on a given item with sub menu. They can:
- click on the text to go to its landing page, or
- click its expand button to see additional options within that section.
Have you worked on a big project optimized for mobile? Please share if you have!
Take a look at the banners in the background of this scene. Who knew the Yamana clan’s insignia was also a menu icon?
Are you seeing menu icons in unexpected places?