Understand what the other party wants

This part was the hardest. Whenever you get an assignment you always have to understand it first; at least, that seems logical enough to me. Sometimes, the party knows the problem, but doesn't really know the solution. If the assignment is more of a problem, and less of a solution, you know you need to communicatie. And pronto!

In the situation with my friend the problem was clear. All the incoming resumes were different (in content as well as formatting), there was no good way to save and index the resumes, and there was no manpower to edit all the resumes.

What my friend initially wanted was more manpower. Then it changed to a converter. Or at least some sort of application that could convert Word documents into clean slick PDF's. While this could've been a solution, I decided to try to understand the real need and not his proposed solution. After a few discussions we came up with the plan to write a system for new candidates: JC Candidates.

Build fast, fail faster

We didn't really know what the system was supposed to do, what it would look like, or how to write it. As I have background in front-end design, and understand a little programming, I decided to go with Ruby on Rails and learn and build at the same time.

We used the principle of build fast, fail faster. Basically this allowed me to learn by trial and error, and my friend to understand what is and isn't possible. Not only did my friend obtain invaluable insights into building a system and thinking about the processes within the company, it also gave him more control of the development. I, on the other hand, could take my time learn the craft and learn by trial and error.

The start was a little difficult. Failing a lot, going back and forth. It was both time- and energy-consuming. Still, the process did help me gain insight into the workings of Ruby on Rails, as well as figuring out how the system should look, feel and work.

Evaluate with said party

In the process of building the system we already communicated often about which way to go and what to add and what to drop. Still, talk is fine, but sometimes you just have to work, work, work. After a few weeks of keeping the communication to a minimum and the work to a maximum I finally managed to create a good working version of JC Candidates that was ready to be tested and evaluated.

Let me first illustrate the system that I wrote. JC Candidates is a pretty basic system that asks the user to fill out basic information that every prospective employer needs (name, contact details, etc.), secondly it allows the user to add work experience, projects he or she is proud of, education, training and skills. Yep, nothing fancy or groundbreaking. What makes it special for us is that we very much streamline the process. From experience my friend knows that his candidates often have difficulties clearly stating on paper what their most important achievements are, while at the same time keeping the resume informative and concise for the prospective employer. Limiting and instructing the user constantly allows us to evade that problem. So, now we both have a system that helps users create a perfect resume, as well as a system that creates an indexed database of people, experience, skills, etc.

Having finished this first version was definitely one of the more exciting stages. Where the start of the entire process was very abstract and the communication during the early process still somewhat vague, now we could really start talking specifics.

It's a pretty brutal process and definitely not easy if you spent a lot of time creating the whole thing yourself. At the same time it's also one of the most valuable learning experiences you can get. If someone can't find a button, doesn't understand what information you want from them, or feels lost in the system; obviously something's not right.

In evaluating these errors it's important for both parties to stick to the facts and stick to their roles. Let the users say what's wrong, and let the designer come up with the solution. Often times the tester points out something that doesn't really work well and at same time proposes a 'solution' he or she thinks would solve it. While this is usually a nice thing and a pro-active way of thinking, when it comes to crafts users often don't quite understand what's possible and what not.

Rebuild and succeed

After some revisions the candidate system is now in a place where it works and looks the part. I'm proud of this achievement, seeing as the entire build period was as much about building the system, as it was learning Ruby on Rails. While the succeed-part for this certain project remains kind of a question mark for now, I’m definitely happy with the progress made.

Still, as much as I'm proud and protective of the system, I also see all the little and big things that could make it even better. Becoming more knowledgable over time, seeing lots of people give the system a spin in real life, you start to see how you could rebuild the thing to make it more robust.

And while I'm content with giving the system some time to breath, let users have at it, and giving my friend the chance to really make it part of the workflow; I'm already thinking about the next build. And trying to discover what the inner-workings are of a truly great system are. This post-production phase is where I'm at now. And while everything in me itches to go and rebuild the whole thing from scratch, but now even better, I know I have to take some time off from it.

So for now, I'm enjoying the success of having learned a lot.