15 days of heuristics
I’ve been working as a Product Designer at FarmLogs and it has been one hell of a journey this summer. And while my official title is “Product Designer”, I’ve been fortunate enough to assume some responsibilities of a User Researcher as well (Hint: this is why I’m writing this article).
What is heuristics?
/hyo͞oˈristik/ — using experience to learn and improve
The idea of using experience to learn and improve comes from a set of rules established by the Nielsen Norman Group (NNG). Why these guys? Great question…because they’ve amassed a tremendous amount of experience and they’ve, arguably, perfected the rules after aggregating results from over 200 projects.
They also have a guide on “How to conduct Heuristics Evaluation?” and it’s a great way to perform tests if you have a research team. BUT as a YOLO product designer in a Startup you need to find the most common usability issues over very specific, hard-to find problems. You don’t have have the luxury of time (or (wo)manpower) to make an all encompassing, exhaustive list. Additionally, your Engineering Team is always busy pushing new features, so usability must be melded into the ongoing features.
Why I did it?
As a product team hellbent on perpetual improvement, we knew that there were more than several ways for us to better provide an “optimal experience”. The difficulty, however, lies in documenting problems and subsequently providing thoughtful and actionable recommendations to remedy the problems.
How I did it?
Simple life, google “Nielsen heuristics”, get those 10 rules, and start dancing. On second thought, don’t, don’t do that. It doesn’t work, I tried and failed (hence this article).
If you are going to be the only one doing heuristics, you must understand how each one of the NNG rules work. In addition to reading the actual rules, here’s a good pdf I found, which has a list of questions that will help you find the answers, also get feedback from your team on these questions and ask them to add some if they want.
Next, make a list of all the unique pages your product has on each platform ( because the rules for iOS will be different than Android), this list should be exhaustive and shouldn’t take you more than 2 hours.
Next, get this verified with engineers and company employees who’ve been here forever because you will never know about that settings page which is buried 3 levels deep.
Lastly, welcome yourself to the world of Google Sheets or any tool that you want to use for listing these features down, which looked like the image below.
Remember, I must document everything for I’m merely an Intern, here only for so long before my school beckons. (Please note, this applies to everyone because you leave work or die, whatever comes first :) )
How are we going to work on it?
You have 100 sheets, one for each page and you have this huge pile of shitty issues to be fixed, what next?
Well, I welcome you now to the land of reports and recommendations. A lot of the issues you found might be repetitive, for instance forms don’t have correct “tab-index” order (Don’t you shush me, poor accessibility is an issue!). Begin by grouping these issues, either inline with the 10 standards we made, or by 1.) simple minor, 2.) moderate and 3.) major issues.
Minor: Stuff that you can sit with an engineer and fix it out over a Friday. (and then call it Fixes Friday, ’cause Startup terminology).
Moderate: This is stuff that you want to sneak in the new features you are starting to make, because no engineer wants to just refactor all his code (trust me you’ll piss them off).
Major: These are issues which call for your personal attention and need a new feature request. These will change the overall experience of the app. For instance, if you group all the form issues as one (tab-indexes, labels, validation rules, etc.) you can make it a new feature of the spec and push it for release. Your product manager will not be willing to do it, but you can’t give up, it is for the USERS!
Is it still design?
A lot of folks ask me if this is still a design job, and my answer is Whatever. This is a job that must be done and should be assigned (IMHO) to designers over developers or product managers. Then as a designer works on new features, he’s already developed an eye for all the heuristics, and will consequently become a nit-picky bastard who will find issues, break things, and celebrate when he’s tasked with the redesign.
But if you feel this is below your role as a designer…
P.S. This was the most fun part of my internship cause I got to break the whole system down xD
Thanks to Mr. Devin Wilder for editing this mess.
