Backcountry
Overview
After a recent update to our global header, we needed to highlight our contact options at a higher level.
Problem
After a recent update to our global header, we needed to better highlight and centralize our contact options more prominently.
Team
1 UX Designer1 Product Manager4 Engineers
Role
UX Researcher, UX/UI Designer
Solution
We created a simple flyout of the 4 contact options, omitting any extra info in favor of comprehension and readability.
Research
After our kickoff & scoping meeting, I examined some of our prime competitors to understand how other ecommerce sites displayed their contact options. All surveyed sites had some form of contact in their footer, while most also had a contact method in their header/global navigation.
This was solid and actionable information: while we had an email sign-up in the footer, we probably should have an option near the top of the page as well.
By simply creating a second location for contact options this would improve findability. By further collecting all of the methods we had we could make this tool much more useful to our customers.
Sketches
I’m a doodler at heart, so I’m usually sketching options or scrawling down competitor designs into my iPad.
We hit a few wrinkles here, trying to fit necessary info into the space. Between contact methods, differing hours/days of operation, disabled states, and existing code components. this was a tricky balancing act to manage.
To the right you can see some ideas and features that struck me. I was somewhat stuck on how to fit a new ‘chat’ icon into the header, without it feeling bloated. Also, as we’d just finalized our new header, I didn’t want to design anything too disruptive that would send the header back to committee for approval.
Through these sketches, I was able to hone in on a few key ideas:
- Must we show each option’s hours?
- How large a footprint do we want for this option?
How would it interact with other menu flyouts?
Wireframes
I moved from iPad to Figma, translating a few sketch ideas into high-fidelity wireframes. As I’d already fleshed them out, I felt good moving straight to hi-fi mocks.
I’d landed on three different options to design and test: ‘simple’, ‘hidden hours’, and a ‘nice to have’ option. Each of these met a different point of criteria:
- A ‘simple flyout’ without hours was easiest for our developers as they could reuse an existing component. This would mean a quicker time implementing and testing.
- The ‘hidden hours flyout’ option hid the complicated hours of operation, yet still displayed them nearby. Useful for the customer as all information is accessible.
- Finally, the ‘nice to have’ was a bit more complicated, showing dynamic hours (i.e. hours until the option was available again, based on a user’s location). We had something similar on another site, but incorporating this feature here would be more complicated for the engineers.
“For me personally, I’d choose chat, and that’s pretty darn easy to find.”
User #3
“…5- very easy. I liked how many options there were”
User #5
“If I have a choice, I’d go to the help center- and then potentially call, if I need more help.”
User #4
User Testing
We use UserZoom as our testing platform and for the bulk of our user testing. I set up my client screening questions, the three design options, and three questions to gauge each design’s unique usability and efficacy:
- Where would you go to contact customer service?
- What contact options are available to communicate with customer service?
When will customer service be available to help you?
Un/fortunately, the results all came back very positive, with no clear winner! The simple option had a slightly longer time to success, but this could be accounted for it being the first testing image (and thus the user knew basically what to expect/look for for designs 2 and 3). Knowing this, my Project Manager and I met and collaborated on our proposal to out stakeholders.
Previous
Next
Final Presentation
As the user results were positively neutral,
we took the results, designs, and our proposal to the weekly stakeholder
meeting. Our proposal was to g with the simplified flyout without
hours. There were a few other details to decide on (contact options and
loyalty verbiage), but ultimately it was the ‘simple flyout’ vs the
‘hidden hours flyout’.
Both my PM and myself favored the simple design: it was sleek, had a
smaller footprint, and was a reusable component. There were a few folks
who favored the ‘hidden hours flyout’ as this was a more accurate,
fuller view. I had noticed however that many of our contact methods had
secondary venues wherein we could display the hours (e.g. a SMS modal,
the chat widget, and an upcoming contact us page). This compromise
helped win over the holdouts. Everyone was aligned on the solution and
we had the green light to hand-off the mocks to engineering.
Previous
Next
Reflections and Learnings
This was an interesting project for me with several ups and downs. There were some obvious things from the outset, but also some unexpected moments and learning opportunities.
- I expected a clearer winner after user testing. With no obvious flaws nor strengths, my PM and I made our decision based on other factors (financial, developer workload, tech maintenance, etc).
- A big area of growth was in presenting and explaining my proposal. There wasn’t a big fight over the proposal, but it did take a bit of negotiating, thinking through outcomes, and coming to a compromise with some major BC stakeholders. A very valuable experience as I move forward, proposing, defending, and compromising on ideas.
- I’ve enjoyed working closely with my engineers and learning more of their work. I’m proud that we arrived at a solution that wasn’t a huge burden for them. This also made for a quicker/cheaper rollout, and enabled them to move onto other work.
This was an interesting project for me with several ups and downs. There were some obvious things from the outset, but also some unexpected moments and learning opportunities.
- I expected a clearer winner after user testing. With no obvious flaws nor strengths, my PM and I made our decision based on other factors (financial, developer workload, tech maintenance, etc).
- A big area of growth was in presenting and explaining my proposal. There wasn’t a big fight over the proposal, but it did take a bit of negotiating, thinking through outcomes, and coming to a compromise with some major BC stakeholders. A very valuable experience as I move forward, proposing, defending, and compromising on ideas.
- I’ve enjoyed working closely with my engineers and learning more of their work. I’m proud that we arrived at a solution that wasn’t a huge burden for them. This also made for a quicker/cheaper rollout, and enabled them to move onto other work.
Next Steps
The next step after this was to create a new “Help Center” page where all contact options would live. This would allow for better breathing room for hours and more information, as well as FAQs and other self service resources. This project has been a long time coming, and I’m happy that I could assist with it as well. During my sketching and wireframing, I made a couple new Header layouts that I am really excited about. I’m holding onto them for a bit, but plan to surface them when we have a lull around the holidays. I think they are another step towards a streamlined, contemporary ecommerce aesthetic.
