Ugly Mockups: How We Started

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

This is part of our "Post-Natal" series on the development of ForceRank.it see Building ForceRank.it for the rest of the series.
Why Create ForceRank talked about the problem we were trying to solve with this product. So how did we think we'd actually do that? How do you turn an idea into a reality? Here were our big goals.

KISS

The site should be simple. Simple. Simple. One focus. No bells and whistles. We are big admirers of Doodle.com and we wanted it to feel just that easy. This lead to our second goal.

Get to Dog Food

Only build features that you must have in order to get as quickly as possible to the dogfooding stage. 

Mobile First

This is an interesting one, because honestly we get much less mobile usage than desktop and you could say that making everything work in mobile was a waste of time. But I would absolutely do this again. The fact is: if your design is simple enough to work well with one thumb your design is simple enough to work. Embrace the constraint.

No No's

Starting in our spare time we wanted to make sure that we didn't put anything in the way of forward progress. That's why we instituted our policy of "No No's", which means that the answer to "can I ..." is always yes. "Can I rip out the pricing page you did and totally redo it?" "Can I change the company logo?"  "Can I publish this blog post?" The answer is always yes.

Ship Early

Pretty much the current dogma, but it's dogma because it's right. Scratching one's own itch certainly helps in this regard because it means you can overlook lots of potholes as you try to solve your problem.

Charge Money

This is no doubt controvertial for some and we've already got great feedback from some people which basically amounts to "omg this is great! why are you hobbling yourself my charging money for this? this could be huge!!" But the fact is we aren't aiming for huge. We're aiming for really frigging useful. I don't want to solve anything remotely related to scale unless it's clear we've solved the fundamental problem first.

So how do you actually start? 

Well, you Sketch some things. And let these sketches be ample proof to all that you don't need a designer on day 1. Look at that horrid gradient! Look at those misaligned edges! No big deal. 

Screen_Shot_2014-07-06_at_5.20.58_PM

Mobile First: The trick with responsive design

You can see some horrible mobile-ish design in that first screenshot. It's horrible, because honestly I stopped using Sketch pretty early on. One thing I found was that responsive design was really much much harder in Sketch than just doing it live in HTML with Foundation. Responsive is just it's own thing. Maybe real designers have better tricks about how to think about the same design in 3 different widths at the same time, but it made my head hurt and doing static mockups in HTML and then dragging the window around to see how it responded felt so much easier. 

That said, Sketch was great about helping me understand how the voting and reports pages would work. 

Screen_Shot_2014-07-06_at_5.21.10_PM

The voting page

Pretty straight forward. A couple learnings here:

  • I really preferred a "drag from left to right" to a "re-order this list". It was more of a PITA, but if the list has any default order, everything is suspect of bias.
  • Ordering of choices was going to need to be randomized so we wouldn't insert the same bias for all respondants.
  • Left to right dragging was going to be hard on mobile. Honestly I wasn't sure what the solution would be it seemed like something we'd just have to try on the phone.
  • This design meant people wouldn't need to vote on all options. Was that ok?

 

Screen_Shot_2014-07-06_at_5.21.15_PM

The report page

This was probably the most important page to get right. If you ask three coworkers to vote on their priorities, you'd better deliver something useful. As you can read about in Why Build a Saas? I'd used color to help pull out the discrepancies between responses in my spreadheet. What wasn't clear to me, without mocking things up, was whether this was going to work at all for larger groups.

Should we show each choice in the order of the overall results, then what ranking each voter gave the choice?

I decided that was confusing, because there was no way to see the rankings of each individual. Instead I hit upon the solution you see above. Show each user's rankings in the order they ranked them. But use the color coding from the overall results.

I think this works pretty well. The "You" vote for "Level 0 - Level7" above clearly jumps out as being an outlier. Also the grey boxes work to show that Maureen didn't vote on everything.

Continue reading the rest of this "Post Natal" wrap-up here: Building ForceRank.it 

Try ForceRank Free

Topics: Tech, Product Design

   

What is ForceRank?

ForceRank is a prioritization tool for product managers. It helps people identify priorities, make tradeoffs, compare results and finalize a plan.

Try ForceRank

Follow Us