Designing a Good Spider Experience — Or, How I Learned to Stop Worrying and Love the Orb Weavers
By: Caylie Panuccio
Tags: Ux Design Process, UX Design, User Experience, Apps, UX

Putting Design Back In

I had Caitlin and Cam pop over, and we got down to business.

First, I quizzed them both on their user base. We knew a lot of people on Facebook asked Caitlin about spiders. I asked Caitlin who exactly these people were.

“Worried mums and dads, sometimes kids, people who are just curious, and occasionally arachnologists” was the answer.

OK. Our user base was pretty broad — and the majority of them weren’t spider experts. This meant the app needed to:

Use simple language

Have biggish buttons for those little kiddy fingers

Pander to the spider aficionados out there. (Arachna-nados?)

However, the main focus of the app was to help the average Australian-slash-tourist identify whichever arachnid happened to be making itself comfortable in their bed. (Eep.)

I mapped out a simple user flow, and then asked Caitlin to have a go.

The benefit of mapping out these flows before you start designing is that you can figure out all of the things that need to go in the website or application, and all of the choices that the user needs to make. Then, you can carve off one bit at a time to design.

Here’s my flow:

Delicious boxes

And here is Caitlin’s:

We figured people might ask questions about the terminology — hence the box “What is habitat?” (Note: this is not what we actually put in the app)

We then spent some time on design-y stuff.

Visual hierarchy of information

When you look at any kind of content, it’s important to know which bits are the most important — or, which bits you want your users to look at first.

Let’s take a look at a spider description page. Remember, the aim for the majority of the population is to understand “What is this, and will it kill me?”

Check out the below image. Can you tell at a glance what this spider is — and if it’ll hurt?

There’s a cool Latin phrase there, and some science-y things, but will I die? I’m not sure

The largest text on the page above is the scientific name of the spider — so that’s where most people’s eyes are going to go first. Then, we’re greeted with a large image of the spider, and we don’t come across the spider’s common name — or what most people would call it — until halfway down the page. (A wolf spider — they have lovely reflective eyes!) The scientific name is also repeated, taking up valuable real estate on the screen.

In re-jigging this, I got very used to looking at images of spiders. Almost to the point of feeling…they’re kind of cute?

Anyway, here’s a screenshot of the page as how it looks today. What differences do you notice?

What a cutie!

The common name is now at the top of the page, followed by a key so you can understand how dangerous the spider’s bite is. Then if you’re a keen bean, you can swipe over to read more about the spider and it’s behaviours. So, we’ve catered to the multiple user groups here, while addressing the most important pieces of info first.

Accessibility

We then talked about making the app more accessible, in terms of colours used, language used, and the types of selectors and buttons.

Firstly, identifying and describing spiders sometimes uses language that’s not so common. We needed to think carefully about what words we were using to describe certain items in the flow to identify spiders.

For example, “habitat” might not be a super clear word depending on the age and educational background of the user. We ended up employing light-boxes to explain words like these:

Secondly, I wanted to ensure that the colours we used had enough contrast so that they were legible, and that the buttons and selectors we were using were large enough to be used by all kinds of fingers, and clearly differentiated in their purpose. So — that meant it was time for a style guide!

Creating a visual language

I wanted to ensure the designs had some level of consistency. The designs DO look different now, but here’s what I started off with as a way to explain consistent visual design. (Not the full shebang, but you get the idea):

The menu here has icons + words, as do the buttons. All prompts are explained.

These guidelines incorporated a few tips and tricks I’d picked up:

Putting words and icons together in the menu (not one or the other — the current version of the app does this when you click on the menu item)

Differentiating between checkboxes (to select multiple items) and radio buttons (to select single items)

Changing up the error messaging from red (which can be anxiety-inducing) to orange (less so). Turns out that’s not so easy to read on a white background.So, the error messaging is now white text on a black background. A nice little prompt instead of shouty red, which jumps out of the page.

Increasing the font sizes, and using colour, font weights, and underlines as a means to differentiate items.

A couple of the pages use sliders. The sliders are both tappable and slidable.

It’s important to note that these were very early stage designs — the designs have evolved since, as is normal with most projects.

The tools of the trade

After all that, I took these VERY simple designs that I’d whacked together in Sketch (praise be unto it), and showed Caitlin and Cam how to string them together using InVision. This meant they could then test simple flows without having to go to the effort of building the app.