Brad Hargreaves | Building Things

Brad Hargreaves on entrepreneurship, community and life

Archive for the ‘design’ tag

The Path

with 4 comments

There are a lot of philosophical divisions among entrepreneurs: bootstrappers versus fundraisers, platforms versus content, lean versus fat, et cetera. But one has struck me as particularly underappreciated: those who build user flows as a series of deterministic paths and those who don’t.

Paths are best understood in the context of user flows. In a path-driven business, each experience that a user — especially a first-time user — encounters is designed with the singular purpose of pushing a user to the next experience and perhaps collecting some information along the way. In the case of web businesses, each “experience” is a page. To generalize, a path is deterministic in nature; a subject’s destination on any particular page has been determined by the page’s design.

Free Awesome is a great example of a purely path-driven business. While there are plenty of links, there are really few options to leave the path, which presents the user with an alternating series of instant-win games and lead gen. This enables simple mathematical modeling and optimization of the business.

Don’t get me wrong — plenty of businesses aren’t driven by paths. General Assembly is about as far as you can get from a path business — we’re building value in a brand rather than a platform or cash flow — but we still think of large pieces of it in a path context.

But some of the best companies create products that feel like robust experiences but are actually just deterministic paths. was a great example of this. While it felt like a comprehensive site, Mint really just guided the user down an inevitable path toward high-value lead gen offers, such as credit cards. That outcome was baked into the site’s raison d’etre at the highest level: users were ostensibly on the site in order to optimize their expenses and save money. So Mint would lead them down a path, collecting sensitive financial information along the way, with the eventual outcome of providing the user with an opportunity to get a low-APR credit card from Discover.

From a psychological perspective, Mint was brilliant. The “saving” component was the carrot hanging in front of the user the whole time. So when the user finally ended up on a page filled with the same credit card offers they get in the mail every week, they viewed those offers as opportunities to save money rather than just more ads.

Some entrepreneurs may look at path-driven thinking as limiting. After all, building your experience as a path discourages users from exploration and tends to focus the business on quantitative — rather than design-driven — decisions. It’s not for everyone. But I do recommend the path approach to many of the first-time entrepreneurs I meet for the following reasons:

Paths kill scope creep If you are designing your site as an experience that contains a bunch of different things that users can do, it’s awfully tempting to build yet another shiny thing for your users. This leads to scope creep, frustrating developers and pushing out timelines. When you are building a path, feature creep makes little sense: something either helps your user get to the next page or it doesn’t. Details can be A/B tested after launch.

Paths simplify evaluation As an early-stage entrepreneur, you want to figure out whether your idea flies as soon as possible. If you have a path, figuring this out is easy and requires little more than Google Analytics: either the conversion data adds up or it doesn’t. If you have a complex multi-dimensional user flow, it’s challenging if not impossible to figure out why the dog food isn’t getting eaten.

Paths end debates Passionate debates about design are one of the most painful parts of the early-stage startup process. As they simplify evaluation, paths make many of these debates far less necessary — if something is in contention, there is a clear quantitative conversion metric on each page to test it against.

I’m not arguing against design. But good design is hard, and design outside of the constraints of a deterministic path is really freaking hard. And if you’re a founder of an early-stage company, your job is already hard enough.

Written by Brad Hargreaves

August 14th, 2011 at 11:39 am

Why General Assembly

with 7 comments

General Assembly is an urban campus for technology, design and entrepreneurship. I founded it last year along with Adam Pritzker, Jake Schwartz and Matthew Brimer.

As you go deeper into the technology community, it gets harder to remind yourself that the global economy is struggling. Every startup in New York and the Valley has open positions that go unfilled for months. Salaries for developers and designers continue to rise, and entrepreneurs are creating real businesses with real revenue.

It’s all too easy to forget that our nation still has the highest unemployment rate many of us have ever seen, especially among young adults. Over 15% of people aged 20-24 are without a job, the highest in more than a generation. Students graduate from college and often times spend their days fruitlessly emailing their resumés to deaf corporations. Clearly, there is a mismatch between what we are teaching our newest citizens and what they need to succeed.

Critical courses are absent from the state curriculum and given only token acknowledgment in higher education. Design and software development, two of the most relevant 21st century skills, are glossed over throughout our educational system. It’s in this context that we’re launching General Assembly, a new kind of campus to educate designers, engineers and entrepreneurs.

That said, an education is only meaningful in the context of an environment that reinforces its message and provides a community to stimulate ideas and growth. This is why we built General Assembly on the model of a campus. We’re crafting a curriculum and have created a physical space in the heart of Manhattan for hackers and designers to work, collaborate and learn. We’re trying to tackle a big problem, and we certainly can’t solve it alone. But we have to try, and I hope you can join us.

Written by Brad Hargreaves

February 5th, 2011 at 1:13 pm

The Game Design of Cities

with 2 comments

There’s an old adage in the game design field that good games are easy to learn, yet difficult to master. That is, a game should be simple enough for even the most uninitiated user to understand yet challenging enough for a master to spend years working to hone their skills. Chess is one oft-cited example. Picture of New York City, Wall Street

Cities operate by similar principles. Great cities are easy for visitors to navigate yet take years if not decades for residents to fully explore and understand. Cities can be too simple, like so many in middle America that bore their smartest residents into submission (or departure). And cities can be too complex for newcomers — New York, for instance.

This is why Adopt a Hacker is a great idea. New York is possibly the most fascinating city on earth to master — but it’s also one of the most difficult places for a newcomer to learn, especially when it comes to meeting new people. Adopt a Hacker NYC lowers the bar to get great hackers engaged in the city by lowering the learning curve. By pairing visiting developers up with veteran NYC residents, it adds a tutorial to an otherwise dense game.

Written by Brad Hargreaves

September 14th, 2010 at 8:42 am