Domain Expertise

Product Design framework – The Jobspire way

When we were smaller, most of our design practices were chaotic and had no set guidelines, simply because we were a small team. With our last few hires, our product team is now a good mixture of both experienced developers/designers as well as interns who need to work well in tandem.
With this in mind, we set out to build a framework that would help take us from the idea for a new feature to a complete, presentable, testable feature. Here’s what our process looks like:


Begin with a set of Hypotheses

Usually, our sales and marketing team send over a great deal of data, trends and user feedback to our data analyst. Our data analyst(who’s a real pro at what he does) gives us insights . We have to be very careful not to read into data and find patterns that don’t really exist. Mixpanel puts this very well in their pitch-

Most of the world will make decisions by either guessing or using their gut. They will either be lucky or wrong

Once insights reach the product team, they plot down a set of hypotheses for new feature changes or additions. An example would be “Bounce rate on the applicant signup form is 63%”. The product team immediately comes up with a list of hypotheses:

1. The form is too long (we actually test this with Crazyegg and see exactly where the user leaves)
2. There’s a particular element on the form that’s not easy to figure out
3. The form is returning with validation errors and the user is getting fed up and leaving

If we’re building a new feature, the hypothesis is something like:
“A user might like to save on commute time when he goes to look for a job”

Note how the hypothesis is not “Users want a location filter”. A hypothesis is an intended benefit(reason to use/not use a feature), not a feature.

Pinpoint the hypothesis with strongest probability

To do this, we move beyond the data. Sometimes we call or mail our users, sometimes look at our automated tests and sometimes we resort to what our product manager’s gut says. From observation, we took a gamble and said “Hey, our form is too long!”

Lay out the mockups

We use to prototype our wireframes. In this case, it would be laying down the ground structure for the new form. After much work, our UI designer brings us a freshly baked mockup. Once our product head says “Yes” to the mockup (our UI designer is new), a high-fidelity photoshop version is created.


Now here’s where we differ from other startups. We write the front-end layout first. While we use pre-parsers to both HTML and CSS(SLIM and SASS in our case – ignore these if you don’t understand them) For all the data that’s going to be generated in the backend code, we enter in fake data. Names, numbers, etc have fake data in place. I first started with this approach years ago after I saw 37 Signals(the guys who created Basecamp) do it.

We tend to play around with the front-end a lot before data is plugged in. Sometimes we discard entire layouts and re-build them if we don’t like how they look or if it seems complicated to use. This is also where our Automated testing expert starts writing test code(we follow a variant of test driven development).
A strong focus on responsive design is maintained.

Finishing up

To finish, we end up writing the backend code to populate our front end code. We then roll this out to our staging server(a clone of our actual production server). We test this out manually as well as run our automated tests against the new code.
If it doesn’t break anything, we push to production. Then we wait for users to actually use the new product and collect data. This data is used to regenerate new hypotheses and confirm new ones.

Do you use similar processes? Let us know and I hope this helped!

Tags : designframeworkproduct
Varun Mayya

The author Varun Mayya

I'm Varun Mayya, CEO at Jobspire. I believe in magic.