Design Inspiration from Svbtle - The trouble with being efficient

Being good developers and designers, we typically define reusable features like a navigation bar or a footer and include them in multiple pages of our design. In PHP we might use “includes”. In a web application framework like Ruby on Rails, we have our “layouts” and our “partials”. But too often, we prematurely reach for those tools.

Having a layout saves me a lot of time. Especially if I have to refactor something. Imagine having a navigation bar on each page but then needing to add another link in it. If the navigation wasn’t in some kind of resuable layout, I’d be opening up dozens of files just to edit the same thing over and over. 

Saving time is great for me, but is that optimization actually solving a problem my customer has?

Maybe a user is in the middle of a task, struggling to write a very important document. Do they really need to be able to logoff from this page right now? At this moment, do they care what’s on your blog? Are they going to need that single click to get to their password change form?

It surprised me a bit how little “consistency” Svbtle, the blog network where I’m writing this essay, has on different pages.

Featured stories page - completely it’s own design.

Unpublished posts page - completely it’s own design.

Editing a post - completely it’s own design.

Applying to write on Svbtle - you get the idea.

Similar color and typography choices being shared, but when you edit your first blog post, it takes a few seconds to reorientate yourself. How do I get back to the blog post list? Oh, there’s where I click.

But it makes a lot of sense.

Dustin, Svbtle’s designer, has figured out his users have a lot of different tasks to do. Some people are just blog readers and need to be able to find something consistently, read it in 5 minutes and bounce. But someone, trying to find all the latest Svbtle posts, has another task. And someone, writing their latest essay, has a completely different job at hand.

I started paying a lot of attention to this approach with my latest project Draft, a software application to help people become better writers.

There’s quite a few tasks writers have: saving drafts, getting feedback, editing, etc. As I tackled making some of these jobs easier, I found myself doing what I often do, having a new page inherit from a layout so I don’t have to reinvent the wheel.

And I got stuck. I struggled to figure out a good way to help a user look over their old drafts, or have room to merge in an editor’s changes.

My mind wandered back to what Dustin is doing here with Svbtle’s design. He seems to almost start from scratch on each job his user has. I tried that.

How would this page look, if I had the entire screen again at my disposal? If you’re a Rails developer you might do something like this:

def index
   @document = current_or_guest_user.documents.find(params[:document_id])

   render action: 'index', layout: false
end

On new pages I create, I set my layouts to false. This forces me to create an entirely new HTML page for that task. I don’t reuse the navigation or the footer or anything else. I don’t automatically bring over those previous decisions and assumptions I’ve made to solve the problem at hand.

What’s happened is that I find myself free to make decisions purely based on solving my user’s problem, not trying to shoehorn my solution into the pixels of space my previous layout had allotted me. By starting a task over from scratch, I’ve been able to do some pretty neat things that didn’t occur to me before. I have an entire canvas again, and really great solutions have presented themselves making my users pretty happy.

draftin has changed my life, fork my docs bro!

— Kevin Li (@liveink) February 25, 2013

Of course, as I complete designing a task a user has, I find patterns that are shared with other tasks and I begin pulling out reusable pieces. But the order in which I now do this is changing and often the opposite of what many of us do with our tools.

Optimize for your efficiency AFTER you’ve solved a problem a user actually has.