The difference between developers and product designers

Our company is bidding on the re-development of an existing product that has outgrown the technical framework on which it was originally built. The customer has received a handful of offers, and the range of costs and technologies found in those proposals is causing him considerable uncertainty in his choice.

In response to that uncertainty, we’re nudging him to look beyond whether to use Ruby on Rails (our choice), Meteor or Laravel since, at the end of the day, the success or failure of his business will not hinge on technology. Instead, we’re encouraging him to consider the difference between a developer and a product designer, and focus on the critical question of who is capable of creating a product that will ultimately prove successful to his business.

To illustrate, let’s consider what happens when you signup for an account in their existing platform. Upon first login, you see something like this:

The original specifications for this product probably contained something along the lines of, “The system will have an accounts screen that lists all colleagues associated with the organization.” The developer then went about the task of satisfying the requirements, thinking:

When the account screen is accessed, I’ll query the database for all colleagues. And to account for the case there are no colleagues, I’ll show the message, ‘No colleagues found’.

Most developers focus on requirements and technology—i.e. the database query, the message to show if the query returns nothing, etc.—and fail to reflect deeply on the actual use of the product they’re building. In this case, the developer didn’t consider the one instance—and a critical one in terms of product success—of an empty database query that every single user will experience—Their very first engagement with this screen as a new user.

As a new user in this system, I’m left disoriented and confused:

  • Where am I, and what am I supposed to do?
  • The “No colleagues found” text seems like an error message. One minute in, and I’ve already done something wrong?
  • “Show blocked colleagues?” What is a blocked colleague? If I click that, the only thing that happens is that the text changes to “Hide blocked colleague”.

Had I created this account as a potential new customer wanting to “kick-the-tires,” there’s a good chance that I’d leave and not return, since experiencing friction in my very first interaction with the product is probably a good indication of what’s to come should I stay.

A good product designer is continually putting himself or herself in the shoes of the user, taking into account their context, their mindset, their knowledge and expectations, and looking to resolve any aspects of interaction with the product which potentially introduces friction.

In this example, a good product designer would identify the need for a “blank slate” version of the account screen, that’s welcoming and orientating for first-time users. Perhaps something like:

And therein lies the enormous difference in value between the average developer, and the very few who are good product designers. The former creates collections of features that “satisfy requirements”, while the latter creates coherent, effective and ultimately successful products.

Authenticating support requests

I experienced something today that’s frustratingly becoming quite common. I emailed the support address of a financial institution I use, and they replied that they can only provide support if I contact them from the email address registered to my account.

The problem here is that as the owner of my own domain, I can receive email sent to [email protected], and I take advantage of that by using unique email addresses for most services I sign up for. (If for nothing else, this makes it easy to determine who’s passing on my email address to spammers.) But I can not easily send emails from all those different addresses, since that would require adding each one manually to Mail.app.

What I find irritating, is the company’s assumption that the “from” address serves as any kind of authentication, since it’s dead easy to spoof the from address on an email!

Any company that wants to provide authenticated support must provide a mechanism to initiate the conversation only from within a logged-in authenticated session at their website (or app). After that, it’s fine to continue the conversation outside the authenticated session—e.g. using ZenDesk, HelpScout or whatever support tool they use—because regardless of the email address I use from that point forward in the conversation, I wouldn’t be in a position to even respond if I hadn’t been the one who securely initiated the conversation in the first place.

The design of one-click feedback

Today I received helpful support from Kimberly Castleberry, who works at Yoast. At the bottom of her email was a mechanism to provide feedback:

I’m busy, but at the same time do want to “give back” in appreciation to Kimberly, because lord knows how shitty customer support has gotten these days.

So what’s my expectation—or rather hope—when clicking on this button? That it’s a one-click operation, just like unsubscribing from most email newsletters. But even then, those one-click email unsubscribes aren’t truly one click, because you still have to close the “You’ve successfully unsubscribed!” window.

That might seem insignificant, but that one little extra step actually registers a small amount of irritation in my mind. I’m not sure why, but perhaps it’s because I hate wasting time, and closing the window triggers an awareness of the cumulative amount of time I lose in a valueless component of the process of unsubscribing from the countless newsletters I somehow get signed up for.

But back to this feedback workflow: Yoast use HelpScout — and I love HelpScout! We use them too, so no knock on them—and after clicking the smiley face, I again registered that slight feeling of irritation having landed on a page where I have to take at minimum two further actions: (1) clicking the “Send” button and (2) closing the window.

The unfortunate consequence is that I’m unlikely to participate in those types of feedback opportunities again, so this is an area I feel could use some workflow design improvement, targeted towards making it a truly one-click, friction-free interaction.

Deteriorating user experience design at Apple

In a recent Philip Greenspan post questioning Apple’s competitive edge going forward, I found myself sympathizing with this anecdote:

What about Apple’s supposed leadership in user experience? Plainly the Apple Health programmers didn’t get the memo, but surely the core iOS has a better/cleaner user interface than any Android or (gasp!) Windows phone? I might have thought so until I visited a neighbor. She is intelligent and well-educated, but not passionate about technology. She said that she had hardly gotten any phone calls for weeks. I discovered that her phone was in “Do Not Disturb” mode. She had entered this inadvertently by mistakenly swiping up from the bottom of the screen then touching the moon symbol (a nice icon but there is no explanation of what it means). No programmer at Apple had thought to have the phone display a confirmation dialog box after a few days in DnD mode.

The pace of user interface innovation at Spanish airports

Back in 2003, I posted this paragon of user interface design that I discovered at the Malaga airport, when trying to pay for my parking ticket:

While visiting the Malaga airport this weekend, I thought I’d check to see how things have things have progressed over the past 13 years—yes, thirteen years!! As you can see, the size of smartphone images has increased over that period, but unfortunately the user interface design of Spanish airport parking machines hasn’t seen much progress:

As far as I can tell, the only change to the machine is the addition of some stuck-on signs helping to explain how the crazy contraption works!

UI/UX — MONEY Magazine takes a big step backwards in user-experience on the iPad, and so I’ve unsubscribed.

Previously, MONEY Magazine attempted to deliver a version of their magazine for the iPad that reflected an understanding of how text is best read on such devices, and attempted to take advantage of user interactivity.

For example, It was possible to navigate an edition’s content via pull-up menus on the leader screen of each of the magazine’s four main departments:

And article text was presented in a single, scrollable column:

This all made for an effective and efficient reading experience, in the context of the iPad.

Unfortunately, in the latest issue, MONEY has gone back five years in time, and moved to the unusable approach of presenting the magazine on the iPad as a direct replication of the physical magazine. Articles are presented in magazine-style tiny columns that can hardly be read without pinch-zooming, and—incredibly—there’s not even a way to directly navigate the content.

I can only imagine that this was done in the interest of saving on production costs, but at least in my case, MONEY has shot themselves in the foot — as I just canceled my subscription.

Inconsistencies and irritations in Mac OS X Photos

Just wanted to document a number of additional annoyances I’ve run across in using Photos.app on Mac OS X.

No feedback when violating sharing constraints

I’ve selected all the photos in an album, and would like to upload them to Facebook. Clicking the Share icon, here’s what I see — no Facebook!

I probably spent 20 minutes trying to track down how I’d somehow messed up my Mac’s Facebook account configuration. After finally confirming that Facebook is properly configured on the machine, I then turned my attention back to Photos, and ultimately figured out the problem — Photos limits you to sharing a maximum of 50 photos at a time to Facebook.

Selecting less than 50 photos and clicking the Share icon, Facebook reappears:

Heavy sigh. Whether this limitation comes from Facebook, or somewhere else, it would be useful if the Photos UI would somehow communicate that I’ve violated a Facebook sharing constraint, rather than simply hiding the option.

Inconsistencies in share processing

Here’s what happens when I share photos to Flickr — After configuring and confirming the sharing modal, Photos.app spawns a progress window, and let’s me get back to working in the app.

Now, here’s what happens when I share photos to Facebook — After configuring and confirming the sharing modal, the modal remains active while uploading — blocking continued usage of the app and providing no information at all about the state of progress.

In fact, the first time I experienced this, I just assumed that the app had gotten stuck, force-quit it, only to later discover 20 or so photos had been uploaded to Facebook!

I can’t think of any reason for the difference in share handling between Flickr and Facebook, but the inconsistency is certainly confusing.

End botched training data with auto-stop on loop

This morning, when my wife and I took off on our trail run, I started my exercise timer app. A few hours later, we returned to the starting point, got in the car and drove home. Pulling into the garage, as often happens, I realized that once again I’d forgotten to stop the timer at the end of our run.

Yet another set of recorded training data messed up.

Whether it’s Strava or RunKeeper on my iPhone, or my Garmin Forerunner device, this problem happens so often that it got me wondering about possible solutions. Since the great majority of my routes—whether running, hiking or biking—start and stop at the same location, this particular problem could be solved if GPS device and app makers added a simple “looping auto-stop” setting that automatically stopped the timer whenever I returned to my starting point.

So simple, yet effective! I’m going to forward this article to the folks at Garmin and Strava, in hopes they’ll add this feature to their products. And if you like the idea, maybe you can do the same.

(Of course, it’d need to be an optional setting, to allow these devices and apps to be used in multi-lap events.)

Those unintended consequences of usability improvements

Both my Jeep Wrangler and Toyota iQ introduced usability improvements that have some unfortunate consequences.

When I switch my Jeep off, its headlights remain on for about 30 seconds. Presumably this was done under the assumption that you’d appreciate the lights in a dark garage, as you make your way to the door.

While that may be nice for people in North America living in big homes with garages, it has had the following consequences for me:

  • Hardly an instance of public parking goes by without some bystander shouting to me, “Hey buddy, you left your lights on!”, after which I feel obligated to explain that, “it’s a feature”.
  • I’m never quite sure myself whether I actually turned the lights off or not. And so, inevitably, I end up delaying my departure from the vehicle for the 30 seconds or so it takes to confirm that the lights are actually off. (And you can imagine that bystanders find that—a guy staring at his car, with its lights on—equally odd.)

The Toyota has a key-less entry system such that if I’m simply in proximity of the car, and in possession of the key, the doors will automatically unlock if I attempt to open them. While nice, it makes confirming that the doors are actually locked a bit difficult.

Here’s how that usually works:

I get out of the car and lock the driver-side door. Then I try to open the door, to confirm that it’s locked. But because I’m physically near the car and in possession of the key, the door automatically opens. With a sigh, I lock it again, walk away from the car, and then ask somebody else to try to open the door.

(My friend’s Volkswagen solves this problem by additionally retracting the side mirrors, allowing you to visually confirm that the car is locked.)

The Toyota has some other irritations, like sounding the seatbelt alarm when I place my computer bag in the passenger seat. But I think that’s more related to regulations, than attempts at improving automobile usability.

Thoughtful design — Comparing the user experiences at Basecamp and Atlassian

At Makalu, we’re longtime users of Basecamp, the online project management system created by the folks at Basecamp (formerly 37signals). 37signals care deeply about design, and this is evident pretty much everywhere in the user experience of their products. Continue reading Thoughtful design — Comparing the user experiences at Basecamp and Atlassian

Design Details

A passion for design is a passion for the interests of one’s customers, because respect for their time and a desire to make them happy is at the core of the design process.

Naturally, the flip side of that coin is that poor design often reflects, either directly or indirectly, the absence of real interest in the customer on the part of a product creator. And I suppose it’s for that reason I feel so sour, and nearly offended, whenever I stumble or lose time over poor design.

Between Makalu, RaceSplitter and Rego we have a lot of customers to keep track of. And for that, we use the software Daylite from Marketcircle. As powerful as Daylite is, I frequently stumble upon design shortcomings in the product—and today I hit a particularly annoying one.

One of the important new features in Daylite 4 is Find Duplicate Contacts…, allowing us to identify and combine those duplicate contacts which, over time, inevitably find their way into our data. After identifying potential duplicate sets, here’s what the feature’s UI looks like:

The Daylite designers implemented a two-step resolution process:

  1. First, you select which of the possible duplicate records should be the “master” record, whose data is used for any conflicting fields.
  2. Second, you click the “Combine” button, which combines the duplicate records into one.

Once you’ve combined a candidate set, you move on to the next and repeat this process.

So what’s the problem here?

The problem is that the user ends up spending about 12 seconds per duplicate candidate set—i.e. 1 to 2 seconds selecting the “master” record, and then 10 seconds after clicking “Combine”, waiting for the database merge to complete.

In my case, I had 300 potential candidate sets, the resolution of which required about an hour of my time.

Had the designers been more thoughtful—had they deeply had my interests in mind—they would have implemented an option for the following alternative workflow:

  1. Walk through each candidate set, selecting the master record.
  2. Press a “Combine All” button, and then go back to work on something else while all the database transactions happen.

This workflow would require adding a select box on each candidate set, and possibly a slight change to the feature layout, in order to exclude sets that aren’t in fact duplicates. But in my case such a workflow would have required only about seven minutes of my time.

Postscript: In fairness, there could be a counter-argument. If it turned out that having to process lots of potential duplicates is relatively rare, then an argument could be made against complicating the UI for the majority of use cases. But Daylite is a power-user’s application, meant for a multi-user, complex business environment. And, as with my own case, it’s only after running into a lot of duplicates that I was even prompted to look for such a feature! So I’m not sure that argument would apply here.

A frustrating experience with the WIRED Magazine app for iPad

This article is about a frustrating experience with the WIRED Magazine iPad app, by Conde Nast.

Background

I have an active subscription to WIRED Magazine on the iPad, valid through July 2014. After a recent iOS update, I found that most of my subscribed magazines, including WIRED, were missing from the Newsstand app.

After re-downloading the WIRED app, I launched it and found myself looking at a “Store” screen full of issues available for purchase at $4.99. Same thing on the “Library” screen. What I should have seen were a bunch of “Download” buttons, not “Purchase” buttons. In other words, the app didn’t recognize that I’m an active subscriber. (When I re-installed The Economist, for example, it did recognize that I’m a subscriber.)

So I began looking for a way to tell the app that I am a current subscriber.

The My Account Screen

The app has five sections: Library, Store, My Account, FAQ and Video.

I started by visiting the “My Account” area.

The “All Access” and “Complete Account Setup” would seem like candidates, but after poking around in those sections I discovered they are only relevant to print subscribers.

The FAQ Screen

Next it was off to the FAQ section. There, I discovered content that apparently hasn’t been looked at in ages:

“What is iOS 5?”, “How do I update to iOS 5?” Seriously, this from a magazine positioned to be on the cutting edge of technology? We’re long past iOS 5, guys.

The Store Screen

So it’s back to the Store screen. The current issue displayed two options — “Purchase for $4.99” or “Subscribe”. I decided to tap the “Subscribe” button, and was asked to choose between a monthly subscription for $1.99 or a yearly subscription for $19.99. I tapped the yearly subscription option, expecting that when the app submitted the purchase request to Apple, it would be told that I’m already a subscriber.

Which is exactly what happened! Shortly after entering my App Store password, a message came back saying:

You are already subscribed to WIRED Magazine, through July 2014.

Great!

Except for one problem—all the magazine issues were still listed as purchasable, not downloadable. So even after confirming that I’m an active subscriber, the app still didn’t update its state to reflect that.

The Library Screen

Noticing that I was still on the Store screen, I thought, “Oh, I’ll bet the app updated its state on the Library screen.” So I switched and … nothing; all the issues there were also listed as purchasable, not downloadable. Good grief. But then I noticed a “Sign In” link in the upper left corner, and thought, “Oh, maybe that’s where it’s done!”

But that wasn’t it either. After some fumbling around, I discovered that’s related to your WIRED website account, and unrelated to your app subscription.

Let’s just try purchasing an issue…

Given that trying to subscribe to the magazine resulted in a confirmation of my active subscription, and running out of options at this point, I decided to just try purchasing an issue, hoping that that will also return a message like, “You’re already subscribed; this download will be free.”

So I tapped the “Purchase” button on the November issue and…got a confirmation that I’ve just spent $4.99. Heavy sigh.

For a moment I almost didn’t believe it, but then got the Growl notification as Mail.app announced the incoming iTunes purchase receipt email.

Restore purchases

Unwilling to believe there’s no way to tell this app that I’m subscribed, I finally noticed the gear icon in the upper right corner of the Library screen.

For whatever reason, I had previously discounted this as an option. I guess my subconscious just assumed that given the presence of a “Sign-in” service opposite this gear, that the gear section wouldn’t contain account-related services.

But lo and behold, under the gear menu I found an option called, “Restore Purchases”, which when tapped finally changed the state of the app to reflect my active subscription, allowing me to download issues without purchase.

Conclusion

Setting up a new device or restoring from a backup would seem to me common enough use cases, that apps like WIRED would, on the Store or Library screens, offer a message like, “Already subscribed? Click here to restore your subscription.”

They do that for print subscribers—i.e. they have very prevalent messages under the “My Account” area communicating, “Already a print subscriber? Click here for iPad access.”—so why not an equally-prevalent service for iPad-only subscribers?

I ended up making an unfortunate $4.99 purchase, and wasting a lot of time unnecessarily, due to what, in my opinion, is unthoughtful interaction design.

Epilogue: Support from iTunes

I emailed iTunes, explaining what happened and requesting a refund of the $4.99 purchase. Although they did grant a refund, their reply was almost as disappointing as the experience with WIRED.

First, they communicate appreciation for me having contacted them, and confirming an understanding that I’ve asked for assistance with an “accidental” in-app purchase. Then, they communicate how much pleasure it gives them to have the opportunity to help me and proceed to reference some knowledge-base articles explaining what in-app purchases are, and how to disable them in my apps—all of which suggests they didn’t even bother trying to understand what actually happened.

Hi Matt, This is Glenn your iTunes Store Advisor and I appreciate your inquiry regarding our services today. I understand that you need assistance about an accidental in-app purchase on your iTunes Store account. I’ll take care of your concern and it would be my pleasure assisting you to straighten this matter and I’m happy to help you with this issue I checked your account and it looks like the purchase was made within an iOS app. This is called an “In-App Purchase”. For information on this type of purchase, read: iTunes Store: About In-App Purchases http://support.apple.com/kb/HT4009 I checked your account and it looks like the purchase was an auto-renewing subscription, made within an iOS app. To learn more about auto-renewing subscriptions, read: iTunes Store: Purchasing and managing auto-renewing subscriptions http://support.apple.com/kb/HT4098 I understand that this purchase was made accidentally. Within 10 business days, you’ll see a credit posted to the payment method listed on the receipt. Please note that this refund is a one-time exception, as the iTunes Store Terms and Conditions state that all sales are final. To prevent more In-App Purchases, you can block them on any of your iOS devices. Follow these steps for each device: 1) Tap Settings on your device’s home screen. 2) Tap General. 3) Tap Restrictions. 4) Tap Enable Restrictions and enter a passcode. This passcode will prevent restrictions from being disabled without your permission. 5) Scroll down to the Allowed Content section. Switch the In-App Purchases option to OFF. You may need to enter your passcode again. I hope I was able to assist you with this matter. Have a good day!. Sincerely, Glenn iTunes Store/Mac App Store Customer Support

Windows Usability

As a Mac user for the past 27 years, I’ve had little exposure to Microsoft Windows. My assumption, though, is that the usability of the Windows operating system has been improving over the years. Look like I may have been wrong.

This weekend, immediately following the installation process of a Windows 7 app under VMWare on my Mac, this screen opened:

“This program might not have installed correctly.”

Did the designer of this screen not realize that that sentence could be truthfully said about any installation—including those that did not install correctly, but also those that did! Please, if you’re going to show the user a message like this, at least give them some indication why they’re seeing it—for example, did the installer experience some errors during the install process?

OK, so what are the options I’m provided for responding?

  1. “Reinstall using recommended setting”. Hmmm, does this suggest that my previous installation was not made with the recommended settings? (And I’m left wondering, recommended by whom?)

  2. “This program installed correctly.” How the heck am I supposed to know whether the programmed installed correctly, if the installation process has just finished, and I haven’t had a chance to open the program yet?

  3. I can close the window with the little “X” at the top. Is that OK? How would that affect my installation process? (Is there any chance that one of the two primary response options is required to complete the process?)

  4. I can “Cancel”. What does that mean, that my installation process will be reverted? How does this differ from pressing the “X”?

<

p>Under the circumstances, I figured I’d better go with the “Reinstall…” option, which, as I nearly expected, resulted in getting to see this exact same window a second time—after which I just pressed, “This program installed correctly” and hoped for the best.

How to take good photos

As an amateur photographer, there are three simple things you can do to dramatically improve your photos.

The first two relate to the most important aspect of photography—composition. No matter how good your camera is, poor composition will result in poor photographs. The third step relates to post-processing, usually done in whichever app your photos end up (in my case, Aperture.)

  1. The rule of thirds. It’s usually not a good idea to center your subject. Instead, imagine the camera viewport divided into thirds—horizontally and vertically—and place your subject on one of those lines, so that they are off-center. If you’re taking a shot of nature, you can perhaps align the horizon on a one-third line.
  2. Get closer. The second common mistake is standing too far away from the subject. A close-up of a face is usually much more interesting than a photo of someone’s full body. Think in terms of “signal-to-noise” ratio. The camera viewport has a certain number of pixels. Mentally estimate the number of pixels representing the subject and divide that by the number of pixels not representing the subject. Generally, it’s better if that ratio is high. Start by getting to what you feel is too close. You might be surprised by how much you’ll like the resulting photos! (A corollary to this rule: You can always crop your photos later, to simulate having gotten closer in the first place. I crop almost all the photos I take!)
  3. Auto-enhance. If you have access to a tool that can “auto-enhance” your photos, that’s usually a good idea. Before auto-enhance was commonly available in tools like Aperture, I would apply two simple post-processing steps that worked wonders on photos—auto-level and unsharp-mask.

And that’s it. The first two are by far the most important, and the third is great if you have time.

Inherent vs explicit affordances

Ryan Singer wrote on Twitter:

Affordances are tricky to pin down because they’re nested. A hammer affords driving nails; its handle, swinging; it’s grip, grasping; etc.

I’ve always thought of affordances as elements, characteristics or properties that a designer introduces to explicitly communicate the possibility of an intended action.

For example, the lock-screen swipe control in iOS 6 doesn’t just provide for unlocking, it explicitly communicates through words and a particular visual control the right-swipe-to-unlock action. In iOS 7, though, we lose the visual control and are left only with the words, “Swipe to unlock”. (We are suggested a direction, though, by the right-moving light behind the words.)

According to Wikipedia, though, an affordance is any quality of an object which allows an individual to perform an action—such as the hammer qualities mentioned by Ryan.

But in the hammer example, the grip wasn’t added to communicate the action of gripping; rather it was added to provide for gripping. The handle wasn’t designed to communicate swinging; rather, it was designed to take advantage of the principle of leverage through swinging.

In my own thinking about affordances in the design of products, I think I’ll start differentiating between inherent affordances and explicit affordances; the latter intended to communicate, in addition to providing for, actions.

Truth in design

From Matt Gemmell’s recent article, Tail wagging:

There’s a question I try to ask myself when I’m creating something: “Is this true?”

An eternal struggle I have is to articulate the answers to, “Why do we participate in the activity of design?” Although the context of this article by Matt Gemmell is contemporary—Jony Ive’s rumored changes coming in iOS 7—the article is (in my opinion) timeless in how it touches on so many fundamental aspects around that basic question.

Credit card statement design

When it comes to layout design, the very essentials can be learned in an afternoon by reading a book like Robin Williams, [[[The Non-Designers Design Book]]]. Of those essentials, one thing we learn is that you don’t need to put boxes around and lines under everything on the page. As an example, the book suggests printing an Excel spreadsheet with and without the grid-lines enabled. The difference in readability is striking!

American Express is a 62 billion dollar company. You’d hope a company that size could hire some designers who’ve at least learned the basics. But judging from the look of their statements, that wouldn’t seem to be the case.

Just look how illegible this statement is:

Now consider the same statement, with nothing more changed than simply removing the unnecessary boxes and lines. (Of course, the layout could still be dramatically improved; but just look at the difference made by applying the basic design rules learned in an $8 Kindle book!)

Ok, I’m being a little overly critical of AMEX here. To be honest, they are one of my favorite companies. Great customer service, and their web app is pretty darn nicely designed!

Just wish they designed their statements a little better!

Awful design at Skype

As Skype has evolved over the years, I’ve gotten the impression they’ve hired a bunch of visual designers and told them:

Hey, go make the site look like the other sites out there. You know, BIG and spacey, like Apple! Web 2.0, right? And throw in some icons and progress bars. And gradients. Oh, and tabs!

Here’s the awful mess of a result of visual design sans usability design.

This is the “dashboard” of the Skype Manager. I have absolutely no idea what information it’s trying to communicate to me. But hey, the manager at Skype can check off, “Have a Dashboard, like everybody else!” off his list.

People just want to want to know what to do

My new book, Money for Something teaches the fundamentals of investing, and hopefully motivates the reader that they should be investing.

The actual act of investing, though, requires making a personal and very important decision — the choice of the particular “asset allocation” in which to invest. The book, and its companion website, provides a handful of popular allocations that should work well for most people.

When wrapping up that particular chapter, though, it occurred to me that when I’ve read such books in the past, I’ve always ended up thinking, “I sure wish that in addition to giving me the information necessary to make a decision, the author had also described the decision they took!”. And so I decided to go one step further, and conclude the chapter with a short note about “what I do”, in which I describe my own asset allocation, known as the Permanent Portfolio.

As it turns out, the great majority of emails I’ve received from readers getting started with their own investment program have chosen to invest in the Permanent Portfolio, and I think that’s worth of a bit of reflection.

Whether we are product designers, lawyers, tax advisors, or writers, it’s easy to assume that the job-to-be-done is providing the information or tools necessary for our users to make decisions. In reality, though, the job-to-be-done in the mind of our users is to make the right decision, and we can support that objective by taking our services one step further, with a suggestion, recommendation, perhaps thoughtful defaults settings, or in the case of my book, a section called, “What I do.”

Cooperative booking for travel, hotels and car rentals

Whenever we travel, it’s almost always my wife who does the online research, and settles on a particular flight, hotel and/or rental car. She then emails me URLs, with a request to make the bookings.

In my experience, those URLs — which usually span at least four lines in the email — almost never lead to what my wife had configured and thought she was sending to me. Just today, a rental car she found in Holland, showed up as a car in Albania for me! In the end, we always end up sitting down and doing both the research and booking together.

I imagine this scenario is not uncommon, where one person does the research, and another does the booking. It would be great if companies operating these websites foresaw this workflow, and ensured that researched configurations can accurately be passed to another person for booking.

Random thoughts having spent a day with 37signals's new Basecamp Next

Random thoughts having spent a day with 37signals’s new Basecamp Next — not so much about the product itself, but rather the context around the product.

  • It’s an achievement. I know from experience how hard it is to ship something new. At Makalu we’re working on two new products which, compared to the new Basecamp, are dead simple — yet they’re taking far longer to ship than I would have imagined. What 37signals have achieved in 10 months — not only the product itself, but also all the prep work for migration, the marketing materials, etc. — represents an impressive accomplishment. I imagine there must have been some laser-like focus, on a small handful of guiding principles or ideas.

  • It’s a little rough around some edges. Using the product, I’ve hit some bugs (or at least what looks like bugs), and seen UI imperfections (inconsistent margins, etc.). You get the feeling 37signals shares the Facebook philosophy, “Done is better than perfect.” (And I can agree with that!)

  • Features or reasons? Rather than a features list, the marketing site provides a list of “great reasons” to use Basecamp, each linking to a focus page about that feature (or “reason”). It’s an interesting idea, but my first impression is that the list is too much of a cognitive load. I feel overwhelmed looking at those 20-something reasons. I didn’t read any, and the whole list just seems to blur together.

  • It was a big risk. It was a risk on many levels, but an interesting one that occurs to me is the following: The cost of migrating to a new system probably kept a lot of existing Basecamp customers from even considering alternatives. So choosing to develop a completely new product, rather than improving on the existing one, would seem to creates an opportunity for any customer feeling lock-in to reconsider their options (since either way, they are going to face some migration costs.)

  • It came at the right time. In Makalu, we’d recently been reflecting that although we’ve been with Basecamp for over six years, we actually don’t use it anymore. We make heavy use of Campfire, but had gotten to the point that we were only using Basecamp for time tracking. That, I believe, is because we realized it’s simply not time efficient to work heavily with Classic. It seems 37signals may have felt that way too, as the focus of Basecamp Next was speed and efficiency. Having used Next for a day, I’m optimistic that I will end up really using the product, and for that reason, it really seems to have come along at the right time.

  • It represents a missed opportunity for a lot of competitors. We’ve had several contacts from start-ups of competing products (asking us to try their product). Most have taken the approach of trying to incrementally improve on the basic model implemented in Basecamp Classic. Basecamp Next represents a complete rethink of web-based project management. It’s interesting to think that any of those start-ups could have also recognized that perhaps now is the moment to rethink the whole model. But most didn’t. Most just followed, and tried to copy who they perceived to be the leader. An important lesson to be learned there!

Compromise in Design

My friend Andy Rutledge asked yesterday whether there is place for compromise in the design profession. There are probably multiple interpretations of what’s meant by “compromise”, but in terms of design itself, I would argue that no design solution can exist without compromise.

The design process attempts to address objectives, within a multi-dimensional space of constraints. Within the particular dimension of any given constraint, there may exist an optimal solution. But within a multi-dimensional space, the design solution will sit at some (hopefully optimal) intersection.

It’s highly improbable that that intersection will coincide with the optimal solution in every constraint dimension, and so the design solution in the multi-dimensional space implies compromise in each individual constraint dimension.

So in the sense of “trade-offs”, compromise is already inherent in any non-trivial design activity.

To complicate matters, the relative arrangement of these constraint dimensions are not assured to be static, as they can be influenced by priorities, and priorities can shift throughout the lifecycle of a design activity. In response to these shifts, we must be prepared to accept compromise, in the sense of “negotiation and agreement”, as part of the process as well.