All the Backpacks that weren't - Signal vs. Noise (by 37signals)

All the Backpacks that weren’t Ryan 11 May 2005

37 comments Latest by Pablo Impallari

When we started designing Backpack we only had a rough idea of what the app should be. Each of us felt like we had a ton of information to corral and we wanted to stop forgetting about things to do tomorrow afternoon, or next week, or next year. We also didn’t want to waste time funneling our data into form fields according to some programmer’s idea of what “organized” means. But that’s all we knew.

This fuzzy set of ideas somehow had become a product. Our method, as always, was making real screens. The first two iterations are below (click the images to enlarge).

We based these two screens on a handful of ideas and assumptions:

The primary unit of content would be the page.
Pages would have different chunks of lightly structured content (lists, notes, etc).
There would be pages for People, Places, and Things. We didn’t know what these meant exactly.
Reminders would be single pieces of text attached to little alarms.
New pages can be created quickly from anywhere
Adding reminders should be fast and handy

You can see how these ideas are reflected in the design. Front and center is a page, with different chunks of content. Pages are somehow collected in People/Place/Thing buckets. There is a combination search/create box in the upper right. The reminder section is just kind of floating there all the time.

Now we could see what we were getting ourselves into. While this thing was on the right track, the UI was a mess. In the next step, we tried to clean up and focus.

This iteration was essential. Elements that were previously detached and floating around were now tied into a visual framework. Here we created the “page” metaphor, with a white block on grey - complete with dropshadow. While colors and shadows are often considered to be decorative or inessential, they played a critical role here by differentiating the page content from the global chrome.

After making the visual structure more concrete, we began to see how abstract and complex the whole People/Places/Things idea was. We thought, “are those buckets really necessary?”

This iteration confirmed that killing page types was the right move. The nav is simpler and the sidebar is more direct (with an index of pages instead of recent activity). Note the smaller search box and the “Share this page” link.

Iterative design is a zeroing-in process, and you can start to see this as the changes in each iteration become increasingly subtle. The sidebar continues to take shape with the “Make a new page” link. At the bottom of the page the “toolbox” of content types makes its first appearance. Those buttons are CSS boxes instead of images — it was still too early for graphics. The seach box, which shrunk in the previous iteration, is even smaller now and has jumped to the sidebar.

We knew the nav wasn’t right, but it wasn’t worth worrying about until now. We came up with an idea for using tabs and special sidebar links to handle page navigation. This sketch solidified the idea and brought us to real agreement.

The sketch has been incorporated into the HTML now. The nav links become tabs, and the sidebar reaches maturity with links to the Home page and an index of All Pages. The Account and Logout links jump back up to the nav. We knew they shouldn’t be in the sidebar, though we weren’t happy with their new position either. The shrinking search box has finally disappeared, and the logo is also gone from the sidebar. We keep getting more transparent and more focused. A few iterations later, we launch.

Comparing each of these screens from conception to launch, some things change and some things stay the same. Though the first screen and the last screen are miles apart, there’s a continuity from each step to the next. Here’s a birds-eye view of Backpack’s past.

Remember that Getting Real doesn’t end with launch, so look out as we keep tweaking and improving our favorite new tool, step by step.

37 comments so far (Jump to latest)

ward andrews 11 May 05

i am impressed with how you and your team were so willing to let go of things even when they were coded and in place, that you kept pushing and refining - weeding out the non-essential and enlarging the focus on what was working. this example makes a powerful case for your process of ‘making it real’.

matt Carey 11 May 05

When you design your screens how do you make them? I have always been a firm believer in finalizing the screen design ‘offline’ before coding the pages i.e. I do this in illustrator (but it could be any other page layout app). That way I don’t waste time coding HTML/CSS front ends that at this stage are organic.

But how do you approach it?

Walker Hamilton 11 May 05

hey ward,

I think that’s just it, the features weren’t coded and “in place”.

RS 11 May 05

When you design your screens how do you make them?

We always get to HTML as soon as possible. It’s all too easy to spend an afternoon pushing pixels in Photoshop instead of making something the team can use.

I use Photoshop to visualize ideas that would take too long to code properly. But as soon as I can tell whether or not the idea will work, it’s back to HTML and back to Real.

Anonymous Coward 11 May 05

hey walter, maybe i am confused..were these just photoshop mock ups? ‘real’ sounded like these were quick prototypes (that were coded) and based on actual interaction they were modified as they learned what the user needed/wanted to get out of the product…can someone clarify?

sorry..forgot to put my name in the last post above..from what RS is saying it sounds like html happened pretty early on?

Casey Gollan 11 May 05

Interesting to see what made the cut.
I would actually appreciate the ability to link a page to the home page so that the home page is an aggregation of that (and a few other) pages (think in terms of having a “dashboard” like in basecamp). I had to manually cut and paste from my other pages and such a system of pulling in content from other pages dynamically would be nice.

Show last 5 changes you made would be really useful too, not just the ones others made.

Steve Ametjan 11 May 05

Ward,

From what RS said, and what the post says, it sounds like they work in much the same flow I do. You start with an idea, then do some quick sketches of what the basic UI will look like, and then rather than sitting there and “pushing pixels” until the design is just right, you create an HTML page that has no functionality. That way you get a clear idea of what needs to be changed to create a solid UI in the realm of the browser. I could be completely wrong, but at least that’s what I’m getting from this post and comments.

Brad Sorensen 11 May 05

Thanks for sharing this. It’s really a huge insight into your process in particular and the sculpting process in general.

Backpack, Basecamp and Ta-da really do kick sweet ass.

Chad Alderson 11 May 05

I count 7 iterations in the designs above. Did you guys ever bring in any users for some ad-hoc usability testing during any of these cycles? If you did, what methods did you use to collect feedback? Was the usability testing more front loaded, back loaded, or spread evenly throughout the process? If you didn�t do any usability testing, can you discuss your reasons behind the decision? You didn�t mention any usability testing above, and I�m just curious.

JF 11 May 05

Did you guys ever bring in any users for some ad-hoc usability testing during any of these cycles?

No. We don’t conduct usability tests. We build what we think works best and then release the product. The usability testing happens in the real world with the real product. We listen to the customer base and make adjustments if we feel they are necessary.

Chris Campbell 11 May 05

It’s fascinating to see the process that was behind something that is still so new. It shows in how I’m using Backpack. There is a tangible difference between something that follows the process of Getting Real and something that doesn’t. Simple and usable shouldn’t be complicated and you guys make it look and work so well. You make me want to do stuff. Backpack is a great name as well… it’s a place where I can see throwing a lot of my stuff. But it’s a magic backpack as it has compartments that fit just right.

Thanks for sharing the process and making stuff that lets me do more.

Jonathan Fenocchi 11 May 05

I was talking to my mother about Backpack today — telling her how its mobile usefulness can help keep her on track. I haven’t checked, but Backpack can call you to remind you of things, correct?

I was also thinking of a new feature idea for Backpack. What if you could call Backpack (at some toll-free non-long distance number) and record a message as a reminder instead of having to text to Backpack? I know that’s far-fetched, but it seemed like a neat idea, since my mother doesn’t get much of a chance to use the computer (but she uses her phone a lot).

Anyway, I just want to say good job — this is the best Backpack I’ve ever gotten!

Derek Haynes 11 May 05

Really appreciate the insight into the creative process - I was wondering: in what iteration do you begin creating the backend functionality? Or do you completely hold off until the UI is finished?

I know starting the backend while the UI isn’t finished often complicates the process - but many times we’ll come up with ideas for the UI after digging in a little bit with the code.

Chris Holland 11 May 05

And here I was thinking that eventually I’ll have so much stuff in Backpack that a search box would be really handy … .

Nick Reynolds 12 May 05

Fascinating. What intrigues me is what happened to the ‘Tags’ option from the second screen shot?

--Josh 12 May 05

TiddlyWiki is a cool technical demonstration of what’s possible, but I don’t find it to be very usable, do you?

Anders Markstr�m 12 May 05

Backpack is much better from a productivity point of view. It was some of the other things I was pointing out.

Anders 12 May 05

It’s suprised me a lot that Backpack didn’t use “edit in place” (single-click or double-click to edit), this is something GTDTiddlyWiki does really well, and flickr is using it.

8500 12 May 05

JF wrote:
“No. We don�t conduct usability tests. We build what we think works best and then release the product. The usability testing happens in the real world with the real product. We listen to the customer base and make adjustments if we feel they are necessary.”

You may not conduct end user observations but I’m pretty sure you conduct expert reviews of your products before launch, which fall in the realm of usablity testing. I also consider letting a selected user base work with a Beta product a way to test usability.

You (JF) may not like the extremely formal, documentation heavy, version of user testing (like in lab with cam) but I don’t see how you can say you don’t test the usablity before you launch.

/boggle

RS 12 May 05

I don�t see how you can say you don�t test the usablity before you launch

Getting feedback from people early on is important to us, but this is not the same as testing. Feedback is freeform (eg. “What are your thoughts?”), while testing is structured (eg. “How much time did it take Subject A to figure out how to delete a page?”).

JF 12 May 05

A key part of the Getting Real process is using the product as early on as possible. This keeps us in front of it, using it, experiencing it for close to 90% of the development time. In this way we can spot problems, correct problems, iterate, and smooth out the rough edges while we’re building. This forces “testing” to happen naturally all the time, but it’s just us mostly.

DaleV 12 May 05

This was nice insight, but it makes some of the idiosyncracies harder to accept.

For instance: to me, the link “My Pages” in the sidebar is seemingly irrelevant since all the pages are listed right below it. It also falls between the ‘home’ page and the other pages, creating a lack of continuity in the user site structure. Maybe this makes sense in more complex sites …

I also agree with others that the editing process is a bit difficult to locate at first and even now that I work in it every day, I find myself looking for the ‘edit’ link before mousing over … otherwise a very helpful tool.

The ability to create a page on the fly and share/collaborate with others on it is fantastic.

For instance: to me, the link �My Pages� in the sidebar is seemingly irrelevant since all the pages are listed right below it. It also falls between the �home� page and the other pages, creating a lack of continuity in the user site structure. Maybe this makes sense in more complex sites �

You can remove pages from the sidebar so you need a way to get to those pages.

John Zeratsky 12 May 05

DaleV: I think the “My Pages” link will become important as you add pages to your Backpack. Once you have more than, say 10 or 15 pages, you’ll want to remove the minor ones from the sidebar to save space. Then, the only way to access them is through the “My Pages” listing.

I love the way you guys share your dev process. It really helps many others, who don’t have a strong team, define a solid work flow. Its one of the main reasons I hang around here.

Dan Boland 12 May 05

Doing your own user testing is a great idea. Not only do you spare others the trouble of dealing with your kinks and bugs, but it’s also a great way to come up with new features, not to mention build up your own excitement in what you’re doing. If I can’t sell what I’m building to myself, who will take it seriously? Who will like it?

Scott 12 May 05

Why did you drop multiple columns? That would be much better for my uses, since my to-do list is longer than a page and I have to scroll to see the notes.

Now I understand the usage of the ‘My Pages’, but I still think it shouldn’t be stuck between the home page and the sidebar pages … would make more sense to be up top with the add a new page button … I am a bit averse to the whole “My ” style of navigation. It’s one of Windows most demeaning concepts … I KNOW it’s my stuff! Grrr.

(Yes, I work mostly on Apple . . )

Banks 12 May 05

I agree with Scott about a desire for Multiple columns. Any plans for a customable/”adjustable” layout?

Shalev NessAiver 13 May 05

In a design so focused and contained (all of life’s loose ends on one page), why is the reminders features so alienated from the rest of the page?

If I’m creating an itinerary for a trip to Paris, I would probably want to set a bunch of reminders regarding the trip to paris. It would be nice if you could associated reminders with a specific page, instead of having them as a completely separate piece of the app not connected to anything else.

Of course, if this is already the case and I just missed it, I apologize.

Anyway, thanks for sharing your design process, it really helps to see how people go about creating masterpieces like this.

Tiara 13 May 05

Am I the only one who liked the second layout better? Everything horizontally in one spot, with options to toggle. No need to scroll up and down.

The tags and the people/places/links/etc sections were also really nifty. If there was a way to set up our own link categories, that would be great.

I agree with the earlier comments about the “My Page” thing. Home Page and My Page seem to be rather redundant and can be combined. Also, they take up a lot more attention compared to the lists of pages - many times I’ve had to hunt a bit for my pages just because it’s in smaller, less prominent font.

That TiddlyWiki looks great. Functions like that would be useful.

Matt 14 May 05

If you look today, it appears that the tags are there! Boy, they are just adding features every day.

kmilden 18 May 05

You should work in CSS/HTML as much as possible. Don’t click that photoshop icon until you really need to use a photo, logo, button, or widget for your design. It’s really the only way to design a great site. Keep it in the real. If you can’t write HTML or CSS then you probably shouldn’t be designing a website in the first place.

Pablo Impallari 20 Sep 06

Great post. I love it. I want to see more of these.