Anatomy of a redesign
This is a design case study on HireHive, an online recruiting platform. I go through the design process and design thinking behind the project.
This is a design case study on HireHive, an online recruiting platform. I explain my design process and thinking behind the project.
Zartis, the precursor to HireHive, had been running dependably for approximately three years and seven months. It was a reliable system that rarely complained.
If it was left for a few hundred years, it would possibly become sentient. But something was troubling us.
When we had originally developed Zartis, we were at the forefront of the new wave of niche recruiting software. Recruiting software is essentially a database for storing candidates’ CVs and job histories. A candidate applies through a company’s online career page and their details are stored in the system. Then hiring managers can view and pass the candidate along hiring stages like screening and interviewing.
The system was being used successfully by large companies around the globe. Zartis had been built to be simple and efficient, yet as the years progressed, it had turned into a Micheal Bay movie – all guns blazing, something for everyone, and had far too many things going on in the frame. It was also a mixture of different technologies. It had become a complex beast. It felt like it was bursting at the rivets, ready to give out.
We had crowbarred too many features in at the behest of customers. We always said ‘yes’. What we needed was to get back to our indie roots.
My role in all this
My role in all this was leading design and user experience, customer insights and ideation, early user testing, branding and content strategy. On top of this, I had to take care of the HTML and CSS frameworks. A tall order in such a short space of time for a small development team. Five months in fact. Three months for research, planning and prototyping, then two months to develop. It sounded crazy. The team really had to pull something out of the bag.
A redesign would get the product back to where it should be and force us to look again at the market. Give users just what we hope they needed. The brand also needed to be looked at in a serious way.
As a team, we were extremely busy concentrating on other products. It was hard to find time to even contemplate an overhaul of an existing product. We did the figures and if done in a small timeframe with our limited resources, it was worth the investment. It was an uneasy time. We were essentially throwing the system out and starting again.
Since the development time needed to be quick and cost effective, there were some definite requirements.
Keep in lean
We needed to be lean and nimble. And I know everyone says they work ‘lean’ these days, but this wasn’t a fashion statement. This was the only way it could work. Also, meetings needed to be short and working in the same room was essential.
Make it easy to build
Using stripped down SASS, HTML and Angular Framework was essential. Reiterating every week was another goal.
Customers are assets
We wanted to interview current customers about their needs to find out was was essential to keep and more importantly what to leave out.
We had a head start over the normal discovery process and knew our target market well. We still did more research.
We interviewed our current customers and potential users. We sent out questionnaires to all customers asking them what was most important when it came to the hiring process.
Meeting potential users in face to face interviews was great for feedback. Questions were focused on behaviours and motivations. Once results were in from our questionnaires and interviews, we had a good starting point. This refocused the team and led us to prioritise features.
We constructed personas from our interview data, creating non-technical users to the more advanced user types.
Everything we do in the field of user experience is ultimately about the match or mismatch of users’ mental models and the product’s conceptual model. In a nutshell, this means that when a user is using a product and it doesn’t behave the way they expect from experience, then they’ll become frustrated and go and use something else. Our assumptions built over many years needed to be kicked to touch. If the product’s conceptual model doesn’t match the user’s mental model, then the user will find the product difficult to use.
What we learnt from talking to users
Based on our experience of the current design, we knew what was not working and just as importantly what was. We were lucky to have some great users to work with and a database of invaluable feedback over the years.
User research had dug up usability issues with the current system. It needed to be stripped back. Like the art of film editing, we needed to cut and splice features together we knew were important to customers and cut out all extraneous material.
There were a few elements that we wanted to keep, like search filter, layout of rows and profile page.
All these discussions gave us the idea that the system should be focused on one thing – setting up a job. Our previous assumption was that hiring managers wanted to trawl through profile after profile of candidates. Now we knew that the hiring person wanted to see their jobs and the candidates who applied directly to these jobs.
There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
~ C. A. R. Hoare
Our goal was to make the product easier and faster to use for the user, and simpler for us to maintain.
It would be genuinely easy to use, by creating something lean and friendly.
Gives control over the whole hiring process.
Info at a glance
Being a list based system, we wanted everything relevant to be easily viewable at glance for maximum efficiency.
We want something that is fast, so users do not get fed up of waiting.
Being Irish, we wanted to inject some personality into the experience!
Starting the design process
Messaging and branding
We knew we wanted to rebrand. We needed a fresh approach and to be reinvigorated. This would also drive the look and feel of the system.
Zartis as a brand name felt far too clinical for a product like this. We brainstormed for a week and came up with possible names and concepts. We then spent a day pairing the selection down to a final few. We came up with some initial taglines. It was a branding sprint.
What came out of the sessions was that the symbol of a Hive. It represented everything we wanted to build.
Yes, we tried to stay away from bull marketing speak. It was hard. Every term seems to have been appropriated. So we settled on terms that rooted in everyday life. Our brand had to be organic, informal, friendly and engaging. It represented sharing and team collaboration. It needed a lightness of spirit.
From there is was a case of coming up with the final identity and visual ideas to support the end product. This was definitely the quickest deadline I was given to come up with a new identity.
Having recently heard a talk by Samantha Warren, I was really taken by her way of working. Instead of creating a perfectly crafted comp that everyone can just say ‘no’ to, she created an advanced mood board called a Style Tile. It brings together all the possible visual elements, colours, and typography that might be on the page. The UI of the system is tied in with the brand. As she says ‘it starts a conversation and generates ideas.’ Since our site is modular, it is a logical way of working, as any element can be placed on any other page. I created a few Style Tiles and these became the talking points going into our design stage.
As part of these Style Tiles, I started to think about animation at this early stage. Animation is an integral part of the brand. How things move and interact on page convey so much meaning as well as aiding the user in their interactions. I took keywords we had used and applied them to how things would act. Even though I had no idea of the structure, thinking about simple bouncing, fading, flying opened up more creative possibilities. There was no timing functions or technical stuff at this stage.
Sketching the app on paper
My initial design thoughts started on paper. As the system needed to be built from scratch, it was liberating sketching simple lines without the pressure to conform. I began sketching basic shapes, blocks of layout to get a feel of what I wanted. I took inspiration from other themes I had been using on similar design projects.
How far do you go with a design to break conventions? To be original? I was worried that the design might look thoroughly conformist. Yet our target market weren’t super-users or geeks. They used software purely as a tool. So I gave them reliable and familiar design patterns. When it comes to designing for an average user, creating a usable simple experience that feels familiar is important. The users of our product don’t want any surprises. It needs to be effective. Of course, the artist in me had to be suppressed, but I could get creative later on.
It was important to get everyone looking at layout ideas. I started white-boarding what I had in mind.
The team were involved and had some say in where the features would fit. From research, we had discovered that users wanted to see more info on the jobs page. Some never wanted to go to each candidate profile page. So more info needed to be shown on the listing page. My white-boarding method is simple.
Green pen: UI elements
Blue pen: Arrows and text
Orange pen: Highlights
Yellow Post-its: Behaviour and interaction
Pink Post-its: Animation
I personally prefer to wireframe in HTML and CSS, as I find it gets me thinking about how the layout will be structured. I use HTML over other tools like Azure and Balsamiq, as I can code quickly and it’s far easier creating interactions and links. It is nearer to the final experience and makes sense like this. At first, I create a nude prototype. I whiteout all elements so that I am focused on the layout and nothing else. It also makes me see how visual groups and chunks of information relate to one another. Without the distraction of colour, it makes grouping information more efficient. I created three distinct rounds of prototypes, each getting more refined from group feedback.
The cheapest, fastest, and most reliable components are those that aren’t there.
~ Gordon Bell
The layout is the hardest design element to get right. The success of the experience depends on having everything in the right place and trying to eke out every efficient piece of space. I used those all important ‘Gestalt Principles’ that I had been using unconsciously for years. I decided to make them literal and see how many of the principles I could apply to the design.
Poetry it ain’t
When I’m prototyping, I code badly on purpose. It isn’t poetry, but it is perversely enjoyable to do. It has its benefits of freeing me up from housekeeping and forces me not to become precious about what I am coding. I can pivot on a design idea if I need to change something without getting emotional.
We did some internal testing with low fidelity prototypes to get a feel for it. Everyone gave their opinions and we changed things accordingly very quickly. We also tested it out on a few users outside the company.
Finally, I built high fidelity mockups and did some user testing. I incorporated some of the brand events; colour, type and feel that we had agreed on. To finesse the mockup more we started to do user testing out in the field. We went to user’s offices and watched them using our high-fidelity prototype. This gave us amazing insight into how we needed to improve the product before it shipped.
A short word about coding
I am a designer first and a coder second.
I fell into coding out of necessity back in the dark ages of print (2005) when it was on its deathbed or so they thought. Print never died, and my coding got better.
I code many of my projects, especially when there are no developers on hand. The question people will ask is, does it get in the way of the design work? Hard to say. Very possibly, if I’m being honest. I would prefer to have more time designing instead of fretting over how to name a CSS class, but that’s life on a startup.
The technology I used on the frontend was SASS (an advanced form of CSS) and HTML5 (should be a default now). I took large inspiration from Jonathan Snook’s SMACSS and Brad Frost’s Atomic Design for building the underlying system. It would have been doubtful whether I would have finished the project on time without these tools. The old days of coding straight up CSS is well behind me. But the whole thing would be useless without the work of Noel O’Connell our Super Dev. He used AngularJS to make the whole system work beautifully.
Finally, a minimum viable product
It took two months to build a minimum viable product from the high fidelity mockup. It was launched in August 2015 and everything seems to be progressing well. Watching real users interact with our product is amazing and feedback has been really positive. We have been iterating as quickly as possible, revising elements and dropping some functions. It is improving all the time and proving to be a successful redesign. View the final UI design on Behance.