rh-final.jpg

ReelHire. ARCHITECTURE

 

Role

UX/UI Designer & Developer

Summary

A description of the steps our team took to architect and design the ReelHire service minimum viable product (MVP). Our design process was based on human-centered methodologies and we tried to make all of the architectural and development decisions based on our future users' goals, needs and motivations, alongside constraints our users might face while interacting with the service. This approach helped us to better prioritize functionality, identify and focus on the important parts of service's user experience and avoid inflating the project scope.

 
 

Team & Stakeholders

Product Owner, Software Engineer, Back-End Developer, Recruiters & HR consultants


Designing the MVP - Desirable, Viable, Feasible

The results of our research allowed us to finalize the vision of how ReelHire would operate. Once we had a clear idea in place, our next step was to create various user stories to start estimating the required functionality. All team members were taking part in this process, giving their own perspectives and voicing ideas of how different features would work or could be implemented. During these discussions we tried to be efficient, keeping in mind the budget and the affordable scope, trying to eliminate feature creep and focusing only on essential functionality we thought would be valuable for our users. We used simple drawings to prototype how different features might look and work and tried to go through as many ideas as we could. Several times we ran those feature lists by our friends in HR, getting their feedback and adjusting accordingly.


DOCUMENTING KEY definitions

At some point during the planning stage we found that it became increasingly hard to communicate ideas without a proper documented set of terms. So once the key concepts of the service were identified, we settled on their naming and documented their explanation and functionality, so it would be easy to discuss and stay on the same page during the development process.

For example:

  • Questionnaire - an object consisting of position description, company description and 4 questions for a candidate to answer.

  • Questionnaire Folder - an object with a list of applicants who have completed the questionnaire this folder represents and submitted it.

Documenting key definitions allowed to drastically improve communication and ideation

By doing just that we were able to drastically improve the ideation and brainstorming processes, while also making communication inside the team easier and more to the point, saving ourselves an incredible amount of time. It helped us to focus on discussing new ideas rather then argue over the same ones in different words.


HUMAN-CENTERED DESIGN

We tried to validate all of our major interface and system design decisions through fast prototypes and rapid field testings. Since all the team members were situated in different countries, each one of us performed his/her own tests and later shared the results with the rest of the team. We would use rough mockups on mobile or tablet, since they were cheap, quick to iterate on and were decent enough to immerse ourselves in a scenario and take notice of different aspects of the experience we were having at the moment. In addition, we sometimes used role-play during the on-line meetings to try and simulate a recruiter-candidate interaction before and after using our service and how those might change.

Rough mockups were cheap, quick to iterate on and good enough to let us walk in users’ shoes

To create field tests, we first of all brainstormed all the circumstances we could think of under which our future users might be using our service. Some of our scenarios incorporated situations, when both recruiters and job seekers where using the mobile version of the service while being in public transport or in the street, at lunch in the park or cafe. So we went to all those places, putting ourselves in those situations and tried to imagine and figure out how constraints and various perception and physical limitations in those places might influence the goals and needs of our future users.

hcd_1.JPG
hcd_2.JPG
We lived through dozens of scenarios, analyzing users’ possible needs, goals and constraints

Secondly, we explored situations like: a recruiter receiving and checking a questionnaire response at home or a recruiter creating and sending out a questionnaire to a candidate while on their way to work. This raised a lot of synchronization questions we did not think of before. Also, we've tried to understand, if it was comfortable to watch a video answer while on public transit, and if yes, how would a recruiter mark his or her impression about a candidate, or make a note to re-watch the video answer later during the day, or, if it was reasonable, to add a quick feedback button to each video answer.

hcd_3.JPG
hcd_4.JPG
Each feature that proved valuable enough made its way into the service architecture

In addition, for job seekers we explored situations like receiving questionnaire notifications while on the bus, submitting questionnaires with predefined videos, starting a process of filling in a questionnaire while finishing it later. We explored the possibility of recording videos on mobile, uploading video from mobile, synchronization between desktop and mobile and co-existence of the same account across several devices. We took into consideration the possible limitations of mobile internet, and planned to allow the ability to disable features that use a lot of bandwidth. One of our main goals during this process was also to understand the context of each situation and the amount of complexity we were able to afford.


SERVICE ARCHITECTURE

The service architecture diagram was partially merged with the screen map in order to save time and budget

When we came to diagraming the results and designing the final version of the service architecture, our choice was to partially merge it with a screen map in order to save some time and budget. This was possible, since we were a small team, constantly collaborating and discussing things in a single online chat. We did not require extra charts or plans to be distributed across various departments and teams. A unified view like that incorporated both the overall architecture, the screen map and even some rough ideas for UI elements, with everyone working and updating the same document, making our collaboration faster and more efficient. We still had separate visualizations for the database and client logic architectures which were shared between people who needed them, but the general service structure was a single document everyone was contributing to.

Also, such single-document collaboration allowed us to eliminate a lot of potential problems when the time came to start the development. By that time everyone were decently aligned on the way the system would work and we had much less surprises than we anticipated. Obviously, this was not a late-change-of-plans free development process and we still faced a lot of roadblocks that we did not think through during the planning stage, but if it wasn't for that previous collaboration and planning, it could easily take us twice the time to finish the job.

Such single-document collaboration allowed to
anticipate a lot of possible development issues

Another key factor that made the architecture planning and designing stage swift and efficient was an honest acceptance of a wishlist for features that, even though seemed valuable, were not essential and thus were not making it into the first MVP of the service. We often had grand ideas about turning the service into a full scale ultimate job searching tool, incorporating machine learning, video editing and other exciting features. And while these were, in most cases, great ideas, we kept our initial goal, budget and scope in mind, accepting only features that was both essential for implementing the service vision and realistic for the budget we had. At this point the team fully embraced the idea of pragmatic, value-driven development, when no time was wasted and each step taken was meant to get us closer to forming a solid service architecture based on concepts that were already tested and at least on some level had proven valuable.


UI

ReelHire UI evolved naturally, from the first sketches we used during planning stages to high fidelity mockups, it was coming together with our understanding of the service. It was a result of a constant back-and-forth with the team, ensuring that the UI incorporated all the required features. My approach was to separate mockups into batches and create them gradually, based on the priority and development plan. This allowed ideas to 'brew' as we went on with the development and gave us the luxury of implementing new concepts as we went on without stretching the deadlines too much.

UI evolved naturally, as a result of a constant back-and-forth with the team

I consciously tried to keep the UI simple and avoid too much animations or complex components, as this was a minimal viable product of the service and its main goal was to test the idea of video resumes as replacements for screening calls. This was a new concept, so in order to ease the adoption our main priorities for the UI were simplicity, usability and predictability rather than wowing users with the flashy animations or visuals.

Since I also was a front-end developer on this project, while designing the mockups, I tried to anticipate elements that were likely to cause problems during development, drawing the team's attention to those areas at early stages. This approach allowed to solve some major architecture and design issues before they turned into costly problems to deal with. Also, we prioritized which screens needed a mockup and which screen we could afford to build without one. This allowed to save budget and focus on important parts.

We kept the UI of the MVP simple to save more time and budget for testing and polishing the flow

Another 'hack' that allowed us to save time creating visual design while still maintaining consistency and a high level of quality was our decision to go mobile and tablet first and make the desktop version inherit the tablet layout and design. This way we were able to significantly decrease the time spent designing and save more time for testing and refining the user experience.


RESULT

Thanks to an extremely lean, iterative and collaborative design process the final architecture and UI proved itself solid and reliable, consisting of valuable and essential features, and insuring the desired user experience. It served as a solid foundation for the later development stages and helped to successfully complete the project.

In the end, we implemented all the key user stories and were able to get a version of the service in the hands of recruiters and jobseekers for testing, receiving feedback and adjusting as we went on with development and polishing.