A startup’s homepage: evolution over time and video intros (maybe?)

OK so> I’ve been thinking recently about how websites change their homepage as they develop. In particular, as a site (e.g. Twitter) becomes more well-known, features change, and they don’t need to use social proof indicators like press received or even user testimonials. Additionally, the initial or primary touch points for the site might not even be the homepage at all. For example, Dropbox’s initial touch point is often an invitation you receive via email.

Here is a history of the Facebook homepage [no press used as social proof, but the list of networks served this purpose], here is two or three iterations ago of the Twitter homepage, an older one, and this was an even older version of Twitter. In tracking the evolution of sites like these two as well as Foursquare and a few others, some of the primary lessons overtime are incremental a) simplification of suggested user focus b) reduction of external social proof. This post is clearly more casual than scientific — it would be interesting to have someone to a more formal study. The best example of a lens into the evolution of a homepage over the lifespan of a startup is (unsurprisingly) 37signals as seen in this time-lapse video of their own. Again, simplification and reduction of external social proof over time.

Two interesting trends collided a few days ago when Facebook made a big change to the [pre-login] homepage (likely unseen and unnoticed by most visitors since their cookies keep them persistently logged in). The post-logout homepage of Facebook (as well as LinkedIn and Twitter) is “use our mobile app.” Facebook replaced it’s old self-description of a social network with a focus on the Timeline. The obvious reason is that Facebook wants to differentiate itself from a standard social network and lock in users by creating switching cost in the form of being the place that everyone keeps a lifetime of info. OK cool, makes sense. What I think is particularly of note in this change [in addition to the change itself] is the inclusion of an explanatory video on the homepage.

When we started to build GoodCrush in late 2009, the idea of an explanatory video came up a few times, but was usually dismissed because - based on the findings of our peers and advisors - users rarely clicked on the intro video. As per above, Twitter used to have a video link on the homepage. One site whose homepage has barely changed and continuously employed the intro video is the aforementioned Dropbox:

Rumor has it that the Dropbox team is obsessed with split testing, so likely came to this decision after lots of experimenting. This begs a few questions: 1) is the intro video the way to go? 2) is its effectiveness contingent on the complexity or subject nature of the product, or target demo? 3) is it because the initial and primary user touch points are not usually the homepage? Other sites of note with a video-centric intro are mobile apps Foursquare and Path.

It is hard to say what exactly you, me, and other entrepreneurs can learn from these two observations. In talking about Facebook, you usually have to preface it by saying “Facebook is the exception and not the rule.” However, here sites at the level of Facebook are useful for serving as an initial data point for more universal UX questions, in this case - how does the homepage change over the lifespan of a startup and, as of a few days ago, what is the effectiveness of a video intro on the valuable real estate that is the homepage?

Below is a snapshot of TheMertonShow.com homepage from our CrazyEgg account from back in November - 5000 visits and roughly the same number of clicks. The primary calls to action were: 1) submit email address or login with facebook 2) watch the demo video. Roughly the same number of people went through each funnel, but the number of clicks on the video thumbnail accounted for 16% of clicks - more than any other individual CTA, whereas “watch the video” accounted for 4%. The questions from this are a) is this high click count because of the size of the link? b) is the engagement built from having a user watch the video worthwhile compared to the inevitable dropoff and ~20% loss of signup that comes from an additional clickthrough? Most of these can be measured, but not all of it. I provide our own insight more as an additional data point than any conclusive suggestion either way. We use video because we are video-centric.

As mentioned, this post is mainly to highlight two interesting aspects of the homepage. Firstly, startup homepages change dramatically over the lifespan of the business for a multitude of reasons: new focus, different features, and - most critically - general user/public (pre-existing) knowledge of the product. Secondly, is offering a demo video an effective use of real estate for both conveying information to and converting users? Likewise, when during the lifespan of a company is video the right solution and is it only meant for certain types of companies?  These are observations and subsequent questions, would love to hear other peoples’ take and insight. 

FriendPtz [Friend Pointz]

People frequently ask me (and I ask them) to upvote something on HN, retweet, like, proofread, share, etc etc etc things. So much like TaskRabbit or Fiverr, I thought it’d be helpful for me to have a way to reward or ask for rewards from friends to demarcate certain tasks or mini-favors.

This past weekend, I went to the TechCrunch disrupt hackathon and hung out with Alex Taub (@ajt) and Michael Schonfeld (@baconseason) [now team DWOLLAxNYC]. FriendPtz is, in effect, social bitcoins. For those of you unfamiliar with bitcoins - it’s a peer-to-peer currency. 

Having already integrated OmniAuth into something already [GetNeighbors], it was much, much easier to incorporate social [facebook+twitter] integration into my app. This is clearly a major, positive byproduct of coding things up previously. Further, I even reused a bit of my code from GetNeighbors and The Elevator Game to get started.  

I took the next steps beyond using basic functionality offered by bootstrap and found additional sites (including lavishbootstrap.com) that enable some easy color palette templating and largely eliminates the default, bland black and white bootstrap scheme.

There’s definitely an exponential, proportional relationship between understanding and being able to implement concepts with what you are actually able to implement with them. For example, because I was more familiar and comfortable with OmniAuth this time around, I was easily able to add Dwolla integration by using their omniauth gem.

The hackathon participants all got 1 minute to demo. Alex warned me that it was short but I didn’t realize how short it was. You can find the video towards the bottom of this link as “Friend Points” (need to ‘show more’ a few times) - I barely made it through a few screens before the 60 seconds were up! Had I prepared I might have been able to do a bit more during the presentation, but the point is clear that there was/is room for simplification.

To this end, Alex had suggested I only allow retweets, instead of allowing people to send/trade Ptz and post an open favor. This could be done with the Twitter API, but by that point my code was bloated, it was 5am, and I didn’t feel up for the challenge. The next day, I would find out that there is a site that does this (except with actual bitcoins) called FeedZeBirds. The difference here would be that you don’t need any actual currency to get started or participate, but it’s otherwise the same exact concept.

I’d like to see FriendPtz serve as a general platform for potential applications like a FeedZeBirds — mainly so I can arbitrarily send FriendPtz and invoice people for them for random daily life encounters and activities. I’m not sure how much time I’m going to devote to FriendPtz - there are definitely things I’ll change and improve on - but I hope you enjoy using it, I definitely will! Now send me 10 Friend Ptz and go build something.

Learn to Code and BUILD SOMETHING

A few weeks ago, I gave a talk at Larry Lenihan and Jason Finger’s “Ready, Fire, Aim” — an entrepreneurship class at NYU. It was my third time speaking there, and it is actually helpful for me in reflecting on my learnings and growth. Each year I’ve said that — like the class’s name suggests — if you want to get involved in the tech startup community, you should just build something and/or go after it. This year, I was able to synthesize my suggestions in 3 bullet points:

1. Learn to code
2. Just do it — build something
3. Network [not covered here]

The first point should be obvious by now — you need to learn about tech, especially the tech that goes into the company or industry you are interested in. Even if you have solid footing, it’s always helpful to become increasingly technical and learn about new tools. A CEO doesn’t need to commit code daily, but everyone should understand the tech the company uses [especially for the CEO].

A lot of non-engineers, myself definitely included, rationalize that they don’t need to learn to code for a multitude of bad reasons: not going to be coding, too hard, don’t have the mind for it, too busy, etc. If your excuse (which is what it is) is not listed, it is probably equally refutable. Anyone can learn to code, it’s not that hard, and the key is to go step by step. Facebook and Google weren’t built in one frenzied coding session. The initial hurdle is the hardest conceptually, but is the easiest practically, so let’s go already.

As a starting point, I strongly recommend you pick up a book on HTML and CSS. Read through it quickly, follow some examples, and by the end of the book [which will probably take you a week to read], you’ll make webpages. You will be surprised at how easy [in terms of time and effort] and fun it is. 

Now that you can make basic webpages in HTML and CSS, there are so many tools that get you to an intermediate level.  Codecademy is a perfect example, so too is the curriculum at General Assembly. I’d suggest learning Ruby on Rails or Node.js, but PHP and Python are solid too. It’s important to reiterate that as you dive deeper you focus on the next step of learning and not learning everything at one time. This part takes maybe a month or two.

You don’t need to know everything and you don’t even need to remember everything. If you run into a bug Google the error and you’ll probably find the solution on Stack Exchange [a LOT of engineers do this]. No one can write perfect code all the time from day one: you run into bugs and questions, fix them, and move past them. One student said he wanted to build a photo gallery but didn’t start because he didn’t know how to do photo uploading. What you are trying to build or figure out has (more than likely) already been built or solved. Coincidentally, a photo uploader is the project in the Node tutorial.

OK, so now that you have a grip on the basics of code, I think the best way to improve, reinforce, and actualize your learning is to build something. If you are reading this, you probably have an idea or five for either your own site or improvements to others that you can realistically build with your newfound tools. Go ahead and build something. The hardest part is getting started.

I have been preaching this for a while, and I realized I haven’t tried to code something from scratch in quite some time. The Elevator Game was one example, but I embarked on a (slightly) more complicated project that integrated Facebook Connect and a few other components that I hadn’t used before to expand my knowledge-base and reinforce my familiarity therewith.

The creation was Get Neighbors. I initially started playing Zynga games to learn about how they are so masterful at user experience design - particularly the on-boarding process. Unfortunately, I, too, became hooked on Zynga games as a result. In most of their games, you either need lots of friends to play the game or pay. Instead of forcing people to spam their friends, I thought there should be a service to link up people who already play the game — that’s what GetNeighbors.com is. Some say it is again fb TOS - dislike — I disagree. It was a lot of fun building it and it’s a useful tool. Even though I’m not going to market it , it’s very cool to see just your first user sign up for something you’ve built entirely from scratch.

If you’re using Rails, go to Heroku, go through their support docs, make sure you have everything installed, launch an instance and you’re ready. Practically, the hardest part really is getting started for me — getting all this stuff together is kind of annoying but, like coding, just power through - Google the errors, fix the bugs, and move past them. Create a product spec with features, map out the UX and UI and imagine the end user experience. Then go ahead and build!

Pizza v. Pizza - Real Life UX: < = >

It was 10pm and I was hungry.

On my way to the subway, I passed by a pizza place (let’s call this place “Alpha”). Location, location, location is the most important thing in restaurants and this proved to be the case for this establishment, as they had first dibs on monetizing my hunger. I peered inside to find about 15 pies. For some reason, none particularly piqued my interest:

I looked around and saw another pizza place across the street (let’s call this place “Bravo”). I walked over to Bravo and found about half as many pies (as you can see below):

After seeing these pies, it hit me. The pies at Bravo were significantly more attractive than at Alpha and I knew why. The most important characteristic was that the pies were clearly fresher, whereas the pies at Alpha looked like they had been sitting out all night. In addition, the presentation of the pies was more alluring — it showcased the freshness and warmth of the pizza.  I ended up getting two slices at Bravo and enjoyed them very much. +$7 for Bravo, -$7 for Alpha. 

A lot of people are inclined to cram their apps with a lot of features (I’m definitely guilty of having done this). Now, though, there is a shift to “Less is More.” By offering your users a more focused experience with fewer features, you are actually able to provide a more valuable and rewarding experience.

There’s two key lessons we can learn why of Less is More, or as I like to write it “< = >” [If you Google this, nothing comes up, so I guess it’s original?]. The first one is quality: given a finite amount of resources and/or quality, we divide that by the number of pies to get enjoyment [q/p = e]. Since the number of pies in Alpha is twice that of Bravo, if we assume the two places are roughly equal, Alphas pizza should be half as good [q/10 = eA vs. q/5 = eB -> 10eA = 5eB -> eA = eB/2].

The second lesson is customer focus: when you have a multitude of offerings, your customer’s attention is divided. In the same way that quality is spread thin, so too were my eyes scanning the variety of Alpha’s offerings whereas I spent twice as much time eyeing Bravo’s pies.

As we learned in the previous posts, user experience in the real world can offer us a lot of lessons to approach design online. From the pizza example, we see a genuine example of < = >.

Turn your idea into an experience - Part 3, happy ending for the trilogy

In this trilogy of blog posts entitled “Turn your idea into an experience,” I hope to offer three insights:

• What components are integral to building out the experience  - Part One
• TheElevatorGame.com, A case study of how easy it is to get started and gain useful insights - Part Two
• The importance of following and pursuing the ideas you are passionate about - Part Three

As I mentioned towards the end of the previous post, TheElevatorGame.com stemmed from an idea and concern that I had to optimize the world around me. Likewise, the project itself may not be of interest to you (or most people for that matter), but the point is to encourage you to be mindful of the world around you, opportunities to improve it, and actually do something about it. Again, the most important takeaway from this trilogy is the importance of following and pursuing - acting on, building something, lobbying for - your ideas and passions.

I recently watched a Bret Victor’s presentation on a similar subject - “Inventing on Principle” - after beginning this trilogy with an excellent elucidation of this point: ”As a technologist, you can recognize a wrong in the world, you can have a vision for what a better world can be, you can dedicate yourself to fighting for a principle….you can fight by inventing.” An addendum that I’d like to point out is, as per TheElevatorGame - even if you think it might not be meaningful to others, you’d be surprised. It seemed that a lot of people had similar sentiments on elevators after I wrote my blog posts. Put the idea on paper and ask around! Better yet, get to work on it!

The best example of this that I’ve encountered directly is actually something that happened very recently - February 25th - 26th at General Assembly for the Aviary Photo Hack Day 2 (#PHD2).

I spent the night at GA Ruby on Railsing and Javascripting for YouAre.TV [and some Settlers of Catan games with organizer and good friend Alex Taub ;)]. At around 1am, Alex brought someone to my desk and suggested that he connect with me - t’was Arcadius Kazimierski (“Arc”). Alex explained that Arc is a very bright technologist but could use some product/branding/etc help for his hack day project.

Arc showed me two projects he was working on. The first project was an app that enabled vision-impaired Windows phone users to take a picture of their money and it would tell you how much the bill was worth ($1, $5, etc.) or that it was on the wrong side. The other project showed you what celebs your friends look like. He explained that he ran into stumbling blocks on the first project and couldn’t get it to work, which led him to focus on the second since they both used pretty much the same code. Both leverage the Face.com API to match the given input (a picture of a face) and output the bill or celeb with the corresponding face.

I offered ideas for how to build out both projects in terms of user experience and in the latter, Facebook integration, branding and virality. With regard to branding - he had questions about what the name for the projects should be. I gave him my thoughts that two word and/or two syllable combinations are usually a good way to go (as influenced by Geoff Lewis + Joe Perla), as exemplified by FaceBook, SoftBank, GroupMe, FirstMark, FedEx and WordPress — tumblr, Google, Artsy are some two-syllable 1-worders — Groupon is like both I guess? Geoff and I also have a preference for literal names - TopGuest, GoodCrush, YouAre.tv. We came up with LookLike for the celeb project.

If my experience has taught me anything, though, it is to focus completely on the one thing you are most passionate about and block out everything else from your full-time concentration. This is obviously particularly resonant during a time-limited hackathon.

As such, towards the end of the conversation, I explained that the most important thing for him to do was to focus on the project he cares about the most. He said that he was definitely much more passionate about the money project, but expressed concern about the tech challenges and whether or not people would care about it since it didn’t apply to them.  It was also clear he wanted to build something to win. He thought that the celeb app would be more widely appreciated because it could be used by a larger audience. As per above, I reiterated what matters is that you care about what your building.

Personally, I have a lot of sympathy for and admiration of the resiliency of blind people. Over the past two months, I’ve been walking around with a broken foot - as in, not walking around. To say it was an inconvenience would be a gross understatement. Along these lines, something that I was always cognizant of was the difficulty living a life without the power of sight. Think about it for a moment. Maybe even try it for a day, live your life with a blindfold. Not so easy, is it?

In the context of inventing on principle, a few weeks prior to #PHD2, I was thinking about how useful it would be for technologists to use their vision to build tools for those without.  As such, I underscored the value created from an app of this nature [there are a few apps out there for iPhone - one of which is sponsored by the government, but none for Windows Phone 7].

At around 4 or 5am, Arc came back and presented FaceValue and a working prototype for all the bills except for one and was visibly excited. Alex and I were impressed by the name, it’s great no?

The next morning I was at my desk listening to demos for projects like Linterest and Linstagram (hilarious) and a photo printer — a lot of them were very cool. When it was Arc’s turn to demo FaceValue, I crutched outside and watched. Arc was a bit nervous, but clearly proud of his creation. As with most demos, it was more Siri like than Siri-commercial like. When it did work - identifying whether the bill was on the right side and, if so, what the value of the bill was - there was a loud round of applause.

After his demo, I crutched back to my desk. It wasn’t the smoothest demo of all time, but he built something really cool and of unique, tangible value to certain people. Additionally, it was something he really cared about and believed to be worthwhile and ultimately that is more important than winning a contest. To quote Josh Groban from a corny but enjoyably catch song: ”Believe in what you feel inside / And give your dreams the wings to fly.”

To be sure, this story has more than one happy ending: he ended up winning several different categories and going home with over $1000 in prizes - but that’s not the point. The moral of the story is clear. If you are passionate about an idea, even if you don’t think anyone else is, go out and build it - (at least try to) create value in the world and you will be rewarded internally, and ultimately that’s more important than external validation.

TheElevatorGame.com Results! (Turn your idea into an experience - Part 2b)

Motivation

Do you know what an elevator is? Have you been in one? If so, you’ve likely encountered one of the things that marginally annoy me (and likely you too): elevator buttons. Elevator buttons are annoying. They are a perfect example of something that (in most cases) was created specifically as a purely functional entity - a set of actions for the user to perform with little care for the actual user experience. 

For starters, I don’t like that the lobby button is at the bottom. I also don’t like that there is inevitably some sort of button completely unrelated functional button very close to the lobby button, usually a door open button, but sometimes a stop or even a siren button. The reason I am so concerned about the lobby button and its surrounding environment is because every other time you go into an elevator, you have the intention to hit the lobby button. 

Another issue is the lack of standardization, every time you walk into the elevator, you are greeted with a surprise array and assortment of numbers. I’m all for creativity, but the endless variety of button layouts is indicative of apathy, not style or optimization. You don’t know if the numbers are going to be the buttons, or if they are next to them. Increasingly they are next to them so as to provide braille. While we’re on the subject, though, I’m sure it would be a lot easier for people who use this to implement voice recognition than feel around — now that I think about it, a lot easier for everyone… maybe it is a better substitute than this entire experiment.

The above issues are clear breakdowns in the IA and UI (as discussed in the previous posts) of the elevator button experience and are the focus of this experiment. However, there are also features that are missing from an ideal elevator experience. To name one: undo. This doesn’t necessarily need to be a button, but could be enabled by touching the button a second time.

Hypothesis

Changing the configuration of elevator buttons affects the TTC (time to click). Adding a big lobby button at the top will make it faster to identify and hit the lobby button, while persisting the existing lobby button on the bottom.

Experiment

The app itself was built on Heroku using Ruby on Rails and PostgreSQL - it is available here on github. Thanks to Stephen Martin for the help making the rides_controller around 60 lines of code instead of 400 by teaching me evals and, gasp, nested evals.

Users were uniformly distributed and randomly assigned one of three different configurations. The first is a standard elevator with a big lobby button at the top and the second is a standard elevator. As per above, there is no standard per se, but the most commonly used is with the lobby button in the lower left followed by increasing numbers in columns to the right, until the row ends and the next number goes above the lobby and so forth. Somewhat intuitive: the higher the floor, the higher the button. There is no floor 13 in most elevators, but it has been included in this experiment for simplicity. The third configuration inverted the standard configuration so as to put the lobby in the top left corner — there was a big lobby button placed at the bottom.

All configurations had floor buttons 1-20 in a 4 row by 5 column layout. The sidebar on the left and vertically centered with the floors contained text including the primary prompt to the user to “Click on floor…[x]” where x changes with each click. Each prompt a user was given was a ‘ride.’

In the spirit of Jeremy Fisher of OnWander.com - the app was gamified to increase engagement. The app showed your statistics: rides, total floors, and time spent on the site…and was called ‘The Elevator Game.’ Those with the most rides got their names on the leaderboard.

Results

General stats

Almost all users were recruited from a Hacker News thread, with some coming in from my Facebook and Twitter feeds. Overall, a total of 32,000 rides from 3,477 riders (sessions) were collected. This discounts ~16,000 rides collected from 17 people with more than 300 rides, most of whom tried to game the system by running a script. Although there may have been gamers with fewer than 300 clicks and there may be a few non-gamers in this pool, it is clear that there is a significant, suspicious decrease in the TTC amongst this group. User clicks that took over 10 seconds were also discounted.

Big button and configuration

It turns out my hypothesis was wrong: Config 1 does NOT improve the overall efficiency. The average TTC for the lobby in Config 1 was greater than in Config 2 (1.727s > 1.655s). Additionally, the big button was not really used (~20% in Config 1, ~10% in Config 3), and it was sort of a wash in terms of time for big button v. not. 

What was most interesting, though, is that Config 3 was even better than the normal configuration (1.615s versus 1.655s). For the non-lobby floor buttons, this was also the case. Config 1 and 2 performed about equally in terms of the average TTC (1.966s over 6500 rides, and 1.950s over 6613 rides), but the winner was Config 3 with an average of 1.90s over 6718 rides. The inverted configuration represents a roughly 2.5% improvement in speeding up the TTC process and, as such, the overall experience.

Although I missed the mark in terms of the actual design, it seems that my instinct was right about putting a lobby button at the top. Anecdotal feedback from suggested that this configuration was more comforting than a standard elevator button arrangement - perhaps because it is analogous to a keypad on a phone. A key lesson to be learned here is to test test test and get actual user feedback.

What else affected TTC?

The experiment was, therefore, complete. However, by suggestion of @SethBannon, I connected with data mastermind and social supercomputer Ryan Witt of Opani fame. Ryan made several very interesting finding through Opani’s tools as seen here and in the graphs below. Opani’s graphs don’t come with a ‘made with opani.com’ note, but I added them here.

Ryan made a random forest to try to uncover what variables really played a role in the TTC:

The floor itself that had the most influence and you can see a heatmap of the TTC by floor number [white = fast, dark blue = slow]:

What intrigued Ryan was that there is a smooth, clear correlation between the position of the button relative to the lobby (#1). As you can see below, on aggregate, as x and y distances (represented by the columns and the rows, respectively) from the origin point increased, so too did the TTC.

A related, interesting observation by Ryan highlights some heuristics employed in the process of the user’s Elevator Game experience. It isn’t only the position of the floor for this ride that is relevant, but - to a lesser extent - that of the previous ride. While the distance between from the previous ride’s floor wasn’t nearly as important as the current ride’s floor to the origin, it appears that the previous floor does serve as a bit of a reference point. Another (somewhat unsurprising) finding to point out is that users clicks got faster after 10 rides - we talkin’ about practice!

Product design

Jack Altman said to add something more to the ‘game’ than just the leaderboard and stats, so I added a gamification layer to access a) the leaderboard b) stats c) easter eggs. People needed 5, 10, and 20 rides to get to each - these functioned like levels. HN users slewis and iandanforth pointed out the relation to “Schedules of reinforcement” and that The Elevator Game was designed to measure how long people stayed around for. This was not the original intention of the experiment, but these two were spot on in their instincts, as usage was tri-modal at these levels.

Conclusion

In the span of one’s lifetime, changing the configurations to get a .05 of a time difference may not sound like a long time. In the context of this, though, of the number of times that we will perform these actions during our lifetime and the number of times this action is performed everyday, the magnitude of such a small optimization is massive. 

It’s my life

With roughly 110,000 elevator trips during my lifetime, I will have lost an hour and a half of my life because of this inferior layout — maybe more because I’m frustrated with the buttons.

Change the buttons!

If we assume that everyone in US cities with >500,000 people makes two elevator round-trips per day, the US is losing out on 270 days of worker days per day or $13 million per year. Each elevator used wastes $160 per year. If your elevator was installed x years ago and your contractor charges you y per hour and takes z hours to invert the buttons, should you inver them? Return ((25-x)*160-y*z >= 0);

Next steps/possible experiments

The necessary next step is to perform this experiment in an actual elevator. The key differences are that the test subject will have to use their arm (not just their hand for using the mouse), plus their eyes and hands will cover a much larger distance than in the online experiment.

In addition to a real world simulation, change variables in this experiment. For starters, the lobby button was always on the left, so too with the floor indicator. Given that these anchor points seem to play a pivotal role in the TTC, it would be interesting to test the four permutations of having these two on the left and/or the right. This might yield insight into how we process numbers, order, and spatial mapping.

Lastly, let’s think outside the box. At 30 Rock, you key in the floor you want to go to before you get on the elevator. They also have a keypad instead of one button per floor. Also, what about the aforementioned voice-based destination selection? There ought to be a lot of solutions to optimizing and improving the elevator button experience in addition to the button inversion. For example, maybe we should test to see if adding the 13th floor makes it faster for us to get to where we need to go?

Most importantly, the point of this entire exercise is with the hope that you use The Elevator Game as a reminder to see and question the world around you - is this experience enjoyable and/or can it be improved? If you think it can be, put it on paper…better yet, build a website or experiment and hack a better solution - add value to the world. Also, it’s easy and fun to code and play with the data (shoutout Opani!).

References

http://theelevatorgame.com

http://opani.com/ryan/elevator-analysis/

https://github.com/JoshRWeinstein/The-Elevator-Game

http://theelevatorgame.com/results

http://theelevatorgame.com/leaders

http://news.ycombinator.com/item?id=3535371

[post publication update]

Good feedback from Judd Rosenblatt, this should definitely be checked: “Couldn’t help but wonder—why don’t you try putting the big 1 at the top and the rest of the numbers below in descending order? To me at least, that seems way more intuitive than anything you tried. When I rode [an elevator] just now, I found it frustratingly unintuitive.”

Turn your idea into an experience - Part 2a

OK so, one of the main reasons I wanted to write about UX is because a lot of what can be learned in user experience design online can be applied to the offline (“real”) world, as well. As I’m sure many of you do as well, I tend to look at a lot of these real world experiences and have a desire to optimize them — particularly when there is something about that experience that makes you unhappy or inconvenienced. Most of my observations are in the realm of IA - I want things to be arranged differently.

One particular example of IA I take issue with is the elevator — namely the buttons. As such, I developed a little game / experiment to test my theories, and would greatly appreciate it if you partake by playing around on:

theelevatorgame.com

Turn your idea into an experience - Part 1

I remember I wrote a piece for The Huffington Post around a year and a half ago, very early on in my entrepreneurial journey. I talked about my personal experience starting off - going through and overcoming some of the bumps in the road that I elaborated on further when interviewed in the BetaBeat article on start-up depression. After more time in the world of consumer web-based entrepreneurship, I’ve realized that I do have some more useful stuff to jot down and share. In particular, I have a series of blogs posts on product design and user experience (in case it wasn’t clear from the title). Hopefully they will all make it from my mind to this blog with this as a starting point: an introduction to how I think about and approach these topics thanks to the creation of my first venture, GoodCrush.com. 

My passion in the world of the wonderful web is product. I accidentally stumbled into entrepreneurship because of a project I coded up in college (the CrushFinder that later led to GoodCrush - more details here) and my desire to create cool, innovative, and useful products. I like to think I have good ideas for products (not all of my ideas are good, but once in a while I get a few :D ). 

As the saying goes, though, ideas aren’t really worth anything - it’s the execution that matters. I pointed this out in the aforementioned HuffPo piece that I wrote (quoting Derek Sivers), but I’ve learned that the idea is just the starting point of product development. To be sure, the idea can and usually should serve the guiding light for further development of both the product and the company, but there’s so much more to the product than just the idea.

Your idea should turn into more than just a series of interactions, the implementation should yield a holistic User Experience (UX). Three core components are Features, IA, and UI. There’s more to it, it’s a good foundation:

1. Features - the tools you build that enable your users to enjoy the digital realization of your idea

2. Information Architecture (IA) - how these features are laid out for your users 

3. User Interface (UI) - the design of how users interact with the features and IA 

Let’s use a GoodCrush as an example. Disclaimer: GoodCrush is not in the same state that it used to be in, but it’s pretty similar. GoodCrush was my first entrepreneurial venture, so I had a lot of learning to do, and I’ve learned a lot from it looking back on that experience.

The idea was to create a social-dating site for college students and started off with just one feature: the CrushFinder - a viral, email-based anonymous matching tool.

1. Features

We brought back the CrushFinder as well as a top 10 for the most crushed on and most active schools. In prototypical social network style, we added accounts with profiles along with a directory that let you use various search filters to browse users. The users were able to set their email notification preferences, connect with Facebook to help manage their multiple profile photos, add crushes (that could be recycled monthly) via the directory, as well as send private messages. The site made each school it’s own silo such that you couldn’t interact with users from other schools. There was an admin panel that allowed for the creation of schools and management of users. 

We also had a large backlog of additional features that were supposed to be added - a mobile app, virtual gifting, photo-rating, events and more. The simplest of these features was a Twitter-like stream of Missed Connections (a la Craigslist). Although there were previous examples of analogous sites, we built that and created an innovative double-blind messaging system that allowed users to exchange messages completely anonymously. Other components of the missed connections were searching, filtering, an RSS feed and various layers of moderation.

With the benefit of hindsight, we can learn lessons about how to approach the process of developing the features. For starters, these features take time to build and are not few in number. We also needed to (and did) build all of these with one part-time developer. Without going into a full discussion on Customer/User Development, we shouldn’t have built all of these features, particularly without a clear sense of the demand for these features.

Even though features such as profiles are commonplace on other sites (or perhaps because of that), that doesn’t mean we needed to build them in a similar fashion. Another lesson - we should have gotten more feedback from users on their existing experience, instead of pushing forward with more features — less can indeed be more. Think about (or discover from user testing) the one thing you want your users to be able to do and execute on that. By having two main features and no real hierarchy as to which takes precedence, the user experience was torn. Not including features will define your user experience as much as including the ones you do.

2. We had the good fortune of working with a great design firm (Hard Candy Shell) so that definitely helped in terms of the IA. The site was clean, organized and easily navigable — if there are words you want to describe your IA, it would be these. The best way of doing this is to keep the number of pages to a minimum. Fewer features enables you to do this, allowing for better focus and execution. As such no mater how good your IA is, its efficacy is ultimately a function of the features that you take on.

In User Experience Design, you want to make sure that you cover all the entry and touch points. I struggled, though, balancing the CrushFinder and Missed Connection features as well as the logged in and logged out experiences. As mentioned, the IA was solid, but the “flow” of the user experience - from entry to (hopefully, use of the features to) exit - was inconsistent and poorly defined because of the two distinct features.

Inconsistency is a serious issue, particularly if they expect to see certain features and are instead given and confused by others. Our IA was easily navigable, but everything should be effortless. If the user isn’t always excited about what you are offering them your IA becomes irrelevant, your UX will suffer and your retention will suffer. This is why it pays to keep it simple, clear, and consistent.

3. The UI is the look and feel of your site - driving users’ emotional response as well as their direct interactions with it. We knew GoodCrush needed to be an inviting atmosphere — primarily to create a warm overall sentiment. We wanted it to be fun and playful, in the vein of the features.

As such, we went with two shades of blue for our primary colors (baby blue is also my favorite color). Our designer also used light and light-hearted typography and graphics (logo, iconography, default avatars, and others) to enhance these feelings. The calls to action were clear and people loved the feel, so much so that one user joined Hard Candy Shell because of it. When we switched the branding from GoodCrush to CollegeOnly, people were livid. Your UI is one of, if not the, most powerful drivers to create and emotional connection with your users and turn your website into an experience.

Congrats, you’ve got a great idea. This is where the process begins. The three core components of developing your product are establishing the feature set, mapping them out for effortless usage, and designing it knowing that these touch points are how your users relate to it. Remember that your these three  - and others - are closely intertwined and need to be consistent in developing a cohesive experience, instead of merely a series of interactions you want your users to perform.      

Instead of SOPA, why didn’t they just…

H’okay, so…people don’t like SOPA, but the MPAA, the RIAA and others don’t want piracy on the internet. Instead of lawmaking, it’s kind of weird that the folks pushing for SOPA and PIPA didn’t contact the major players on the interwebs to try to brainstorm how to resolve this issue.

Today I joined Mr. Seth Bannon and others for the emergency NYTM to protest SOPA/PIPA and, in about 5 minutes, came up with a much better idea for the pro-SOPA/PIPA folks to try to tackle online privacy…as I said, 5 minutes, but think it might be worthwhile/interest — post your thoughts below:

How about…if, instead of spending $100mm lobbying for legislation, those same parties could have spent a max of one tenth the money creating a company that builds technology to index multimedia - namely video, music and image files - or partnering with a company that already does this. After retrieving this data, they could build tools to analyze whether or not any of these files violate DMCA and send a cease and desist to the offending sites and/or sue for damages. [edit: they could/should do this with text too as identifiers for potentially infringing pages or links]

Thoughts?