Instagram's Wall St. Journal cover story

The article covers the surface level details, which (to oversimplify) are as follows:

• Two Stanford whiz kids made an iPhone app that uploads cameraphone snapshots to the Internet.
• The app generates no revenue, but is growing so fast that big-time VCs invested, valuing it at $500 million.
• The founders sold the app to Facebook for a billion dollars.

Those are the key facts, though the article sheds precious little light on the subject—especially if you’re creating a product and want to replicate their success. The Journal makes only the briefest mention “removing a rival” as a possible motivation for the purchase.

@richziade @iA @dkberman @wblau FB overspent on Instagram to remove a competitor. Focus on the real issue, not false comparisons to old biz.

— Jeffrey Zeldman (@zeldman) April 9, 2012

Let’s stipulate that taking a competitor out of your market might be worth $1 billion and look at how, exactly, Instagram competes with Facebook.

Competing = Doing the same job

If I asked you to picture Facebook in your mind, I’d wager you’d conjure up an image like this:

Facebook

The primary focus of this page is the News Feed (highlighted in yellow below), which is a stream of “status updates” posted by your friends indicating what they’re doing or what’s on their mind.

Facebook's News Feed

Having a textual description of what you’re friend is doing is great, but a picture is worth 1000 words, right? So, something like this might be more engaging:

Popular photos on Instagram

The above is a sampling of the popular photos right now on Instagram. Now, I’ll add annotations to call out some of the more interesting stories:

Popular photos (annotated)

I’d say it’s clear the concept of textual status updates is rather dry and geeky by comparison. If a friend told me she was rooting around in MTV’s archives, I’d think that was pretty cool. If she showed me some photos and gave me a real sense for what it was like, I’d be much more engaged. Also, notice that an image doesn’t have to be a photographic masterpiece to tell a story that your friends might find compelling (see cats wrestling above).

If I want to communicate to you what I’m doing or thinking about, it will almost always be more effective to show you, not just tell you. So by this logic, Instagram is not only doing the same job for me that Facebook is, but it’s doing it better.

Get better by focusing on the Job-to-be-Done

Looking at product based on the “job” it does for the consumer is a useful analysis tool for this type of post-mortem. Clayton Christensen, the Harvard Business School professor most famous for his work on disruptive innovation and The Innovator’s Dilemma, has written about this technique and will publish a book on it soon. If you’ve never heard of the Jobs-to-be-Done theory, start by watching this short YouTube video where he tells a great story about why people hire milkshakes. To dive deeper, check out the work of the The Re-Wired Group.

If you’re working on a product of your own, having a clear understanding of the job-to-de-done is a litmus test that can tell you whether a given feature is core to the user’s experience. If it’s not, consider skipping it. In the case of Instagram, by focusing on the core flow of capturing the moment, adding emotion (via filters), and sharing with friends, they were able to avoid building:

• A full-featured web app
• Sophisticated photography controls (exposure, white balance, histograms, etc.)
• Grouping/sorting your photos into albums or collections

Based on what other photography apps/services do, it would be easy to say that Instagram “needed” those features to be competitive. Instagram’s founders, however, knew all they truly needed to build was a way to shoot, style and share a photo for their users to get the job done and tell the story of that moment in their lives. They could then make the appropriate tradeoffs and divert resources to polishing the smaller, core feature set into a great user experience.

The pace of business is always increasing, and Instagram used focus as a weapon to not only beat their direct competitors (PicYou, Hipstamatic, picplz and many others) but also threaten the 800 lb. gorilla known as Facebook.

What job do your customers hire your product to do?

Source: Insta-Rich: $1 Billion for Instagram (http://on.wsj.com/HuJVMF)
Source: Why do you hire a milkshake? (http://www.youtube.com/watch?v=s9nbTB33hbg)
Related: Integrating Around the Job to be Done, Module Note (http://hbr.org/product/integrating-around-the-job-to-be-done-module-note/an/611004-PDF-ENG) by Clayton M. Christensen
Related: The Innovator's Dilemma (http://www.amazon.com/dp/0060521996/ref=cm_sw_r_tw_dp_A9PQpb0RE31C8)
Related: An Interview with Clayton Christensen (http://5by5.tv/criticalpath/36) by Horace Dediu
Related: Jobs To Be Done (http://www.therewiredgroup.com/jobs-to-be-done/)

Pivot Your Culture to Win with Agile: Eric Burd

Investing in Design: Phin Barnes

Replacing Requirements with Hypotheses: Josh Seiden

Getting Out of the Agile Building: Tomer Sharon

Managing Your Malkovich Bias: Andres Glusman

Quick, Visual, Collaborative & Continuous: Lane Halley

This one’s a little thin—be sure to grab the slides if you want to go deeper.

Learning to Play UX Rugby: Anders Ramsay

The Design Studio Method: Todd Zaki Warfel

Code Literacy: Jonathan Berger

AToMIC Design: Jennifer Gergen

Demystifying Design: Jeff Gothelf

Related: Agile UX NYX (http://agileuxnyc.com)

I did make it through one book last year, though, and it really stuck with me: The Social Animal by David Brooks. As a developer who's transitioned into design, I made my way through a self-guided crash course in interaction design, visual design and the like, but moving "up the stack" into understanding emotion was uncharted territory. Luckily, Brooks' book made the topic very approachable, since it's written as an allegory.

The Social Animal has many insights, but this is the one I keep revisting: every piece of sensory input a human being receives will evoke an intellectual and an emotional response. The takeaway is that you can fold this into your personal interactions and benefit, or ignore this at your peril.

Interesting stuff, right? But how do we use this knowledge to make our designs better?

Here Comes The Knowledge

Three separate pieces of work have crossed my path that address this topic:

• Designing For Emotion by Aaron Walter is the quintessential guide. Simply put, I don't think we'd be talking about this without Aaron's work.
• Affective Computing by Kristina Höök is a more academic take on the topic that reviews the relevant research. It's deep stuff made more approachable with video interviews.
• Grouped by Paul Adams focuses on the social angle with discussions of influence and how ideas spread between people. Some of the same concepts are in this slide deck, so you can start there to get a sense for the thinking that shaped Paul's work with Google+ and Facebook.

So, What Now?

Have I synthesized all this into a Unified Theory of Human Computing? Um, not quite yet. But I think the sheer amount of activity around these concepts tells us we'll need to fold them into our design practices—where there's smoke, there's fire.

For now, I have all this stuff on my reading list, which I promise I'll get to very soon.

Source: Affective Computing (http://www.interaction-design.org/encyclopedia/affective_computing.html) by Kristina Höök
Related: Grouped (http://bit.ly/tUGZNl) by Paul Adams
Related: Designing for Emotion (http://www.abookapart.com/products/designing-for-emotion) by Aaron Walter

While grep is still the gold standard, recently I've been using another tool called ack in its place. The ack web site defines it as "designed for programmers with large trees of heterogeneous source code." I've found it to be significantly faster at searching through files, and also has a clean, simple way to search within only certain types of files.

Example

Let's say I installed the LinkForce app into a developer edition org and wanted to explore the code. After setting up this org's code in a new Eclipse project, I can navigate to the workspace directory on the command line and run the following:

ack Short_URL__c

So, again, the above command outputs a simple list of all files that reference that particular Custom Object.

That's pretty good, but let's imagine what I really want is to find custom code (Apex and Visualforce) that refers to that object. Rather than piping the output of a separate find command as an input, I can simply execute the following:

ack --type=apex Short_URL__c

I've configured a file type called apex that ack interprets as Apex Classes/Triggers and Visualforce Pages/Components. This way, I avoid superfluous search results like the definition of the Custom Object itself. ack natively understands many common file types, and can easily support any number of custom types.

Oddly enough, a blog post can't illustrate one of ack's greatest strengths: speed. If you search through large source trees often, you'll be amazed at how quickly the results are returned. The vast majority of my searches complete in less than one second.

Installation

The main ack web site has information about how to install the tool, and I actually used the AckMate plugin for TextMate since I'm a Mac user. In addition to enabling ack as the search tool within TextMate, it's possible to use that same script on the command line by creating a special symbolic link.

The Force.com-specific configuration I created can be found on GitHub as well.

The first line defines the apex file type as consisting of Apex Classes, Triggers, Visualforce Pages and Components. The second line defines another type simply called force for other metadata like Objects, Apps and Profiles. You can treat this as a starting point and break out more or less file types to include Workflows, Page Layouts, etc. Finally, the third line of the configuration specifies that search results will be presented one page at a time using a command line tool called less (which also supports color coding).

Conclusion

If you develop on the Force.com platform and find the command line more efficient, ack can really speed up your work. I'd encourage you to try it if you've never ventured beyond what Eclipse offers.

Related: ack (http://betterthangrep.com)
Related: ack configuration for Force.com (http://gist.github.com/633007)
Related: AckMate (http://github.com/protocool/AckMate)
Related: How to use AckMate (http://github.com/protocool/AckMate/wiki/Usage)
Related: LinkForce (http://sites.force.com/appexchange/listingDetail?listingId=a0N30000003I9j1EAC)

Citibank Online's mobile login

Compare this to the mobile app for Meebo, a popular multiprotocol IM client:

Meebo's login

Related: Touch Target Sizes (http://www.lukew.com/ff/entry.asp?1085) by Luke Wroblewski
Related: meebo (http://www.meebo.com/)

This article is a summary of the material I presented. Here's a high-level outline:

• Building Your Team and Your Knowledge
• The Build Process: Technical and Licensing Concerns
• Stories From The Field
• OK, Let's Get Started

I represented the perspective of "someone who's been through it." To steer clear of legal issues, I'll omit details of the content presented by the other person. Here's a simplified version of my slide deck, with an explanatory article below.

Think Different(ly)

I began with a show of hands asking how many folks in the audience had an iPhone or an iPad. Luckily, I had a significant number, so I was able to use my analogy comparing Force.com development to iOS development. Both types introduce significant new elements.

New element	Force.com	iOS
New programming language	Apex	Objective-C
New APIs/runtime	Apex Standard Classes and Visualforce hosted in the cloud	Cocoa on iOS
New UI conventions	Salesforce.com CRM and Service apps set the tone	Touch interface, Apple's HIG
New distribution models	App Exchange	App Store
New quality processes	Security Review	App Store Review

These new elements necessitate a shift in thinking from traditional Java or .NET development—one which starts in design, affects coding and extends into sales. Directly "porting" an existing application concept to Force.com would be no more successful than porting the entirety of Microsoft Excel to the iPhone. There's a different definition of what makes an app great.

Concrete Examples

Let's take the example of building a simple blog system that organizes Articles into one or more Categories: Force.com's object database causes the fundamental data model to include notable differences. The Categories are defined as a first-class attribute of the Article, rather than as a separate table (requiring yet a third junction table). Moreover, this structure allows the system to render an appropriate UI to assign an Article to multiple Categories without any custom code.

Force.com also includes a major difference at the user interface level: a native, out-of-box UI that matches Salesforce's CRM and Service apps. The interaction and visual design of most Java or .NET apps will start with a blank slate. The default UI may or may not be a great fit for your app, but in either case it's worth respecting the conventions to which Salesforce users are accustomed. Reducing friction for end users will drive adoption and word-of-mouth referrals.

Look Beyond Development

The Force.com platform is broad and deep; launching an app on Force.com is definitely standing on the shoulders of giants. Hence, it's possible that the engineering effort to build an app is actually less than you imagine. That said, most folks with a development mindset don't plan sufficiently for the work to distribute the app. Working through the Security Review process and listing on the App Exchange are activities that require time and planning.

It's natural to "go with what you know" and focus on simply building the app. Unfortunately, that's not the finish line. ISVs would be well-served to start planning for non-development activities sooner rather than later.

The Role of the PDO (Product Development Outsourcer)

Salesforce refers to my company as a PDO (Product Development Outsourcer)—we can design an application, handle the development and help a client through the work of launching onto the App Exchange. On the majority of our prior engagements, we've done the lion's share of the development.

Over time, however, the client team ramps up and takes over. As a corporate asset, the app is their intellectual property and it's critical to assemble a team with the skills necessary to be a successful software company over the long term. This includes not only development, but also related functions like customer support and product management.

Our model is not to become "embedded" as a vendor for many years. In fact, we're thrilled to hear success stories from former clients who no longer need our "training wheels."

OK, Let's Get Started

If you're an ISV that's ready and willing to head down this path, how do you begin? It's actually quite simple: our usual process is to meet with you and have you explain the long-term vision of your application. We need to understand your definition of success. Then, we'll discuss any tricky requirements in a little more depth, go back to our offices and reflect on everything we've learned. Finally, we develop an overall design concept of what it would look like to host your app within Force.com, and we share the concept with you to get feedback.

It's analogous to meeting with an architect to design a custom home, describing what you need, and seeing an initial sketch. Almost all the elements in the design are still negotiable, but the sketch gives you confidence the architect understands your end goal.

Architectural sketch

Most often, our initial sketch takes the form of a concept model. Once you're comfortable with what you see, we'll begin a formal planning process and design phase to capture and spec out all the specifics. After the design phase is complete, we scope the actual development work.

Conclusion

If I could choose to have the audience remember only one idea from my presentation, it would be this:

Prior experience building software will help you succeed on Force.com, but don't expect to do things the way you've always done them. Embrace the change.

If you're interested in discussing this topic further, please leave a comment or get in touch privately. I'd love to talk to you.

Source: An in-depth look at Force.com (http://www.developerforce.com/media/Forcedotcom_Whitepaper/WP_Forcedotcom-InDepth_040709_WEB.pdf)
Source: Wikiquote article on Isaac Newton (http://en.wikiquote.org/wiki/Isaac_Newton)
Source: iOS Human Interface Guidelines (http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html) by Apple Inc.
Related: Force.com (http://www.force.com/)
Related: Dreamforce 2011 (http://www.salesforce.com/dreamforce/DF11/)
Related: Appiphony (http://www.appiphony.com)
Related: ISV Playbook Modules 2 & 3: Building and Distributing Your App (https://dreamevent.my.salesforce.com/a0930000009YIO8)
Related: iOS (http://developer.apple.com/technologies/ios/)
Related: AppExchange (http://appexchange.salesforce.com/home)
Related: Concept modeling (http://www.peachpit.com/articles/printerfriendly.aspx?p=1637902) by Dan M. Brown

The next weekend, I spotted the informercial for the Ab Rocket Twister on a TV at a restaurant. The volume was all the way down, so I had only the visuals to sell me on this product. The messaging was mostly the typical nonsense used to sell home weight loss machines, though they included one particularly egregious graph:

Double muscle activity!

I'm seeing things through Tufte-colored glasses now, so I decided to see how the Ab Rocket Twister's sales pitch holds up when subjected to his six Fundamental Principles of Analytical Design.

1. Show comparisons. Well, we can see the Ab Rocket Twister generates 107% of the muscle activity of standard floor crunches. The text notes that's just over double, though the red bar looks to be about 3-4x as tall as the yellow bar. (3D helps muddy the waters.) Confusing matters further, "107%" apparently represents a 107% increase, or else it wouldn't be "double." 107% of 100 is only 107, whereas double would be 200.
2. Show causality and explanation. By itself, this image shows essentially zero explanation of why these results are obtained. There are two pictures of a man exercising (one for each method), but that doesn't tell you why you'll get better results.
3. Show more than one or two variables. We could assume that the experiments generating this data have controlled for other factors, but that's not stated. What about the possible effects of changing your diet?
4. Integrate words, numbers and images together. Words, numbers and images all definitely appear here. However, it's hard to argue it's an effective integration. The scale of the bars is definitely suspect, and the concentric circles at the base of the bars strike me as particularly ridiculous. What is that designed to show?
5. Thoroughly describe the evidence. Earlier in the commercial, it's mentioned that "university testing" generated this data. Unfortunately, there is a complete and total lack of information about how and where this testing was performed.
6. Ultimately, the message stands or falls on the quality and integrity of the content. Is this information true? Perhaps, but the word "integrity" doesn't exactly spring to mind, especially given the aforementioned errors and generally cheesy production values displayed in the rest of the commercial.

Overally, this is clearly a weak information graphic. But how could it be improved? When I've made design mistakes similar to these in the past, it's most often rooted in not having enough hard data in the first place. In that case, a heavily "designed," full screen visual simply isn't warranted.

We only see one number in this data set, so one idea worth exploring is what Tufte refers to as a single-number semi-table. That being said, I still don't think I'll be ordering an Ab Rocket Twister anytime soon.

Related: Single-number semi-table (http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0000SI)

Here's a visual explanation of how I did this:

Making the core shape is suprisingly easy in Keynote. You can start out being sloppy, and then align the corner points to make perfect right angles by watching for the yellow guides to appear as you drag the points.

Fortunately, there's a URL you can bookmark which will jump straight to a specific account's Inbox. This one leads to my default account:

https://mail.google.com/mail/u/0/#mbox

In contrast, this one leads to my work account:

https://mail.google.com/mail/u/1/#mbox

You'll notice the only difference is a single, magical number. I had a personal Gmail account before starting my job, hence the lower number.

If you simply navigate to a particular Inbox in your browser, you should be able to bookmark that little sumbitch right there. But if you're a longtime Gmail user with existing bookmarks, you were probably too busy punching the drywall in frustration.

I hope this tip prevents you from goin' all stabby on something.

If we built bridges the way we build software, we'd all be dead. Outlook takes ten minutes to load and crashes every day!

Is it an apt comparison? Eh, maybe.

I'm more interested in the beginning of the process, so I decided to explore what architects do and look for parallels in what we call user experience design. (Spoiler alert: the two line up nicely.)

A trip to St. Barts

My exhaustive inquiry began at Barnes & Noble, with the most recent copy of Architectural Digest. The cover story described the building of a multi-villa compound on St. Barts for an unnamed (wealthy) client, starting with the architects visiting the site. They researched local building styles and materials, and discovered an odd local ordinance regarding roof design.

Did you catch the key word? Research. The UX pros out there know that research is a critical input to the design process. The architects hadn't worked in the Caribbean, and couldn't know about the regulations and what structures would feel natural any other way. Perhaps you've built software that was Section 508 compliant, or made allowances for Sarbanes-Oxley? Imagine the change orders if they would've cut corners in this phase.

In addition to research, there's the obvious input from the client on what they want/need. And indeed, the home is both beautiful and functional. An early sketch (shown in the print edition) depicts guest quarters on a lower level and the "master" separated above, since guest are likely to stick around a while. The master also contains an office space. I can feel you UXers nodding...sketching, appealing visual design and effective interaction design.

The article closes with a touching story about how the lead architect succumbed to cancer during construction, and his protégé saw it through to completion. Here's a quote:

...[T]he master's greatest lesson? "Charlie taught me that you design and refine up until the last minute," the architect answers.

Iteration and usability testing are analogous here in a way that's almost uncanny.

Let's do lunch

A longtime friend has a Master's degree in Architecture and works in construction management, so I met him for lunch to get his take on this.

He echoed these points in a more practical way, pointing out that a project like this effectively has an unlimited budget. Iteration on a construction project is much easier without those pesky concerns. We can be a lot more nimble with software...lucky us!

Tl;dr

Surprisingly enough, architecture and user experience design have the same three steps:

1. Conduct research and get requirements
2. Design something that meets goals and is beautiful
3. Polish it to perfection

It's just that easy.

Source: Charles Gwathmey’s St. Barts Paradise (http://www.architecturaldigest.com/homes/homes/2011/08/charles-gwathmey-st-barts-article)
Related: Bridges, Software Engineering, and God (http://www.codinghorror.com/blog/2005/05/bridges-software-engineering-and-god.html)