Wait, you helped design WHAT?
In late 2017, two dear friends of mine let me know that they were attempting to build an app that would help Australians (and tourists) identify spiders.
I didn’t like spiders much. I didn’t like looking at them, them looking at me (with all 8 of their eyes!), or even being in the same room as one.
Despite that, my UX brain kicked into overdrive. The first question I asked was “How do you know this is a real need?”
Caitlin Henderson (Friend #1) has been working with spiders and insects her whole life. As part of this, she’d spent a lot of time responding to terrified individuals via her father’s Minibeast Wildlife Facebook page telling them that no, this spider was harmless and it wasn’t going to kill them. At that point, she was responding to multiple messages a day.
I said to Caitlin — “Look. I’m a UX Researcher. Let me help you out”. Caitlin and Cameron Hunt (Friend #2) agreed to send me what they’d developed so far for review.
Now, UX folk. I can practically HEAR you thinking— “Wait a minute? They started developing without designing first?! Where are their task flow diagrams? The wireframes? The STYLE GUIDE?” That’s fairly common in start-up land though.
Cam and Caitlin had never developed an app before. The reason Cam had jumped into coding the app straight away was to see if he actually could (spoiler alert — he could).
Caitlin meanwhile was developing the content to describe the 250 or so spiders that would feature in Version 1 of the app.
Right. With that background, let’s take a look at what Cam sent me first.
Development Without Design
Here’s where Cam had got to so far:
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:
And here is Caitlin’s:
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?
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?
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.
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):
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.
Getting Annoyed with Each Other
Fast forward a month or two, and Caitlin and Cam were well on their way to becoming fully fledged designers/content strategists/developers. At this stage, they were consulting with me on some design choices, but for the most part were hurriedly building things and creating the content and designs themselves.
I downloaded a beta version of the app for a design review. Now, given that we were all friends, the conversation got a little…casual. I was using shouty capitals in our Google Doc communications out of frustration, because I felt as though my advice wasn’t being followed. Cam, I found out later, had been working fairly long hours to code the app and wasn’t taking kindly to being Google Doc’d at.
It’s important to note we were all working full time at this point — the app was never going to be pixel-picture perfect, and it likely still isn’t. That’s what iterations are for!
We all learned to be a little kinder to one another, and ourselves.
We’re currently on version 2 of the app (now with added Jovial Jumping Spiders!) and I’m about to sit down and conduct a review of the designs and flows ahead of version 3 — as with anything, there are always improvements to be made, and it’s been a while since I’ve had a proper look.
I said at the start of this article I didn’t like spiders much.
Do I like them now? Definitely.
You can download Spidentify through Google Play, or the App Store. With thanks to Chloe Bloem, Aaron Orellana, and David Powlett for the extra design advice.