These are all the posts written by Gino.

We have been busily working on a new product here at Seabright, and have two pieces of big news.

First up, the new product is called Avenue, and it'll launch this summer.

If you're a landlord or a renter, we'd love to have you get involved in our upcoming beta program. It's time to turn this industry on its head.

The second thing is that we've attracted the attention of I/O Ventures, and recently accepted an offer into their accelerator program. We are having a blast working with I/O, and couldn't be more excited about things to come.

In light of these things, we wound down our client services business at Seabright a month or so ago, and are focusing our full attention on building Avenue into the best possible product and business it can be. It's hard to put this successful UX consulting company we've built on hold, but we fully believe in what we're building with Avenue, and we want to see it thrive on a huge scale.

If you are interested in working with Seabright, you should still get in touch. Our network of UX service companies is deep and wide, and we're happy to point you to great folks. If you're an investor interested in Avenue, get in touch as well. We're excited to share what we're up to.

Thanks for the the past two incredible years with Seabright. You can keep in touch with Avenue progress in the following places:

• Avenue on Twitter
• Avenue HQ

We're doing a bit of an experiment here at Seabright; we're going to share our space! We're small, and have this sweet open studio with gobs of room in a great location near South Park, so why not? If you're a person or group of folks doing interesting stuff, here are the details of what you'd be in for:

• 2-6 desks at $500/ea monthly.
• brick and timber + great light = a lovely, creative studio
• a rooftop deck with an outdoor shower
• 2 conference rooms, printer, super fast internet connection
• bicycle friendly
• you'll be above Little Skillet and Cento (Blue Bottle) coffee
• 2 blocks to South Park
• kitchen with fridge, coffee maker, toaster oven, etc.

A few photos are available over on the Contact Us page.

If you're interested, email us. Be sure to let us know what you do, how long you're interested in working with us, and any other pertinent information.

Thanks!

I'm happy to announce that John and I are going to be involved with two different activities at the Webvisions conference in Portland, May 16-18. Webvisions is in its twelfth year, and this year is going to be a real humdinger.

First up, we'll be running a half-day workshop entitled The Device is More Than a Display (Responsive Web Design is Just the Beginning). Here's the synopsis:

Responsive Web Design focuses on the display of web content, but the reality is that devices are much more than displays. In this workshop for both developers and designers, novices and pros, you'll come away with a solid understanding of how to create a product that makes full use of all of the capabilities of a device, from its screen to its accelerometer, and everything in between.

During the workshop, you'll actively collaborate with John, Gino, and other attendees to create a real-world product/service that spans the desktop, mobile web, native apps, and maybe even activity-specific devices! Whoa!

You'll learn to:

• think in terms of designing and building with device classes, rather than just screen size and orientation.
• focus on the product where it needs it, whether it's mobile first, desktop first, or something else first.
• consider mechanisms for input, sensory feedback, processing power, data storage and environmental context to create experiences that truly respond to peoples' real world use. And then, learn how these things affect the design decisions you need to make.
• understand how to build technical frameworks, and write streamlined code for device classes. There's no need to maintain many codebases for one product.
• use a few simple tricks to respond to device capabilities and classes smoothly with little code and little worry.
• avoid stumbling over those weird devices that don't play well with others.

Secondly, we'll be speaking on a panel entitled Execution is Everything, with Ryan Freitas (of about.me) and Peter Merholz (founder of Adaptive Path, but now VP of UX at Inflection). We'll discuss how UX has changed, and how to get everyone on your teams focused on the right thing: the people who use your products.

We'd love to see you at either of these events (you can register here), or meet up for a drink if you happen to be in Portland in May.

We're looking to add another energetic, passionate UX designer to our team, at first on a contract basis. You should be near San Francisco, and able to be in the studio a good bit.

Interaction Design is important.
UX designers at Seabright are first and foremost strong interaction designers. We are interaction sticklers.

What you'll work on
You'll work on all sorts of things; it really depends on the day. You may work on wireframes and prototypes for internal or external products. You'll solve issues for different devices. You might design web services, game elements, or mobile apps. You might need to do research. You'll likely fire up Photoshop sometimes to help out with visual design. You know that copywriting == UI Design; you're a good writer.

UX is about solving problems.
You'll always be solving real problems, as we're in business to make people's problems go away. You'll be a leader. You'll be working directly with product teams, engineers, and other designers. It's easy for you to communicate your design rationale for every element on every screen you design, and you thrive in a highly collaborative studio environment. You're totally comfortable dealing with customers.

How to apply
Send your work samples that matter and a paragraph or two about why you'd like to work with Seabright to jobs@seabrightstudios.com.

We'll accept applications for this job until February 3, 2012.

Thanks! We're looking forward to hearing from you.

This morning on my ferry ride to the city, I sat next to a guy I'd not seen in over ten years. His name is Jack Stauffacher.

Jack is a book designer, and was born in San Francisco in 1920. In the late nineties I used to ride my bike to and take the ferry from Marin to the city, and I'd see Jack ride his green Italian road bike to the ferry, and head to his studio (the Greenwood Press) in the city.

I've been away from the ferry for a decade, so imagine my surprise when I saw Jack. I re-introduced myself (he didn't remember me), and we talked a bit about design. I asked about his green bike, and the things he said are still ringing in my head:

"I don't ride my Italian bike anymore because my perception isn't what it was. I'm 91 now, so you know, I'm getting old. But listen Gino, don't wait for old age to come. Just do as much as you can until it gets there."

We parted ways, he to his studio, me to mine. Jack still creates everyday. He wears a flower in his jacket button hole every single day. He rode his bike everyday into his 80's. I hope I can be half as prolific, creative and healthy as Jack.

2011 was a fruitful, fun and prolific year for Seabright. We worked deeply with companies on mobile, tablet, and browser apps in business intelligence, healthcare & wellness, and sport training software, with heavy doses of data visualization across the board. We had an incredible outpouring of support in all our endeavors, and all the amazing people in our community simply reinforce that San Francisco is currently the place we're supposed to be headquartered.

We now are up to three full-timers, and two other amazing folks. That's 250% growth!

I'd like to thank our friends Mike and Erika at Mule Design for invaluable advice as we grow. Our lawyer, Adam Bier, has been an instrumental resource in keeping us from messing things up. We don't like lawyers even a little bit, but we can recommend Bier Legal with the highest regards. Michael Lopp and Gina Bianchini have also provided guidance at key points, and we can't thank you both enough.

OK. Let's run down some of the things we did in 2011:

AAAH
We spent the first quarter of the year working with Patrick Soon-Shiong's startup, the All About Advanced Health project. We designed and built an HTML5 iPad application that helps patients get healthier and stay there. By using any combination of internet-enabled health and wellness devices such as weight scales, blood pressure cuffs, pedometers, Glow Caps, etc., patients are able to always have a snapshot of their health, as well as deep data analysis and correlation on any number of data points. By sharing this stuff with doctors, friends and family, the product comes baked with the necessary community support to make it a success.

ASICS
We've been working with ASICS in Kobe, Osaka, and Amsterdam to create a global MyASICS.com service. We've partnered with Tokyo-based now-good-friends AQ to design and build the new suite of integrated products, including HTML5 apps, native iPhone apps, and the desktop experience for the MyASICS service.

New features are starting to roll out to European markets, and in the next couple of quarters the product will make its way to Japanese and North American shores. As a New Year's resolution, you should consider signing up for a running event, and following a MyASICS training plan to the letter. It'll make you a better runner, we promise.

SPLUNK
We've been working with Splunk since July on redesigning what will be Splunk 5.0. We can't say much more than that, but if you're in the Business Intelligence world, we're excited for you to get ahold of the new products in 2012.

DONESKI
We started out making Doneski as a product you'd have to pay for. Ultimately, we decided it wouldn't be a product we'd make the kind of revenues on to support our goals, so we decided to release all code and assets for Doneski as open source. We feel that Doneski is a great example of what kinds of rich interaction can be achieved in an HTML5 app. You can read the original announcement on our blog. If you want to get into the code and design behind Doneski, all that stuff is available in the Seabright Github repo.

THIS SITE
We're calling this new site launch a beta. We're stoked to launch it, but we're also not quite finished with the code for mobile and tablet experiences - they'll launch soon. We're also still hard at work on the back-end engine and admin software that runs Seabright. This site is a little green still, but we're growing, and the site needs to reflect our evolving passions and direction.

Beyond these projects, we've been busy working on new Seabright products, which will be announced and launched in 2012. We've also been speaking at conferences and universities, and there will be much more of that in the coming year. We moved into our own studios near South Park, and couldn't be happier with the new digs.

2011 has been blazingly fast and inspiring for us, and we're looking forward to continuing this momentum in the new year. Thanks to every single person who made 2011 such a bright learning experience. We're stoked about this what lies ahead!

It's been annoying me forever, and I finally bothered to figure out how to turn off the annoying window resizing in Photoshop. I'm probably late to the party on this, but wow, it's one of the most annoying behaviors I've come across in my daily tools. Here's how to kill it:

1) Select the zoom tool (z)
2) In the options bar at the top, unselect the 'Resize windows to fit' box:

BONUS:
If you hate the new zoom behaviors, uncheck 'Scrubby zoom' as well.

It's little things like this that give me great pleasure; this one in particular was like cutting an albatross from my neck!

As a designer and product guy, I'm always intensely curious about the evolution of ideas that lead up to a product launch. It's always interesting to see (and discuss) how teams decide to cut certain features, tweak others, and generally polish things to the point at which they turn the lights on to the public.

Since we've made the code for Doneski open source, we also want to make public some of the design resources we used while building and iterating on the product. Below are a few images of things we didn't use. In Seabright's Doneski Github repository, you'll find the following resources and artifacts:

• Original pencil sketches
• Early mobile wireframes
• Early desktop wireframes
• Images of various themes we didn't use
• All the photoshop files with visual design assets

Here's probably the first sketch ever for Doneski.

Here's a preview of the early mobile wireframes.

Here's the original Doneski theme, which we called "Trapper." We killed it when Apple released the developer/beta version of Reminders. They totally ripped us off! (Kidding!)

We had an idea that if you didn't use a list for a while, it would age. Over time, it would look dirtier, and more and more crumpled. But when you start using it again, it would eventually get clean and crisp.

This was our 'Space Camp" theme, which you could choose. We didn't implement themes since we decided to open source and not support the product.

As you dig into the old wireframes and sketches, you'll see a lot of ideas around accounts, account management, themes, syncing, payment, and so on. When we finally decided to open source everything, we ditched all that so that we can focus on other products.

We've had a lot of fun with Doneski, and are looking forward to seeing how things develop. Enjoy!

I'm happy to announce our first product, and our first open source contribution, Doneski. Doneski is a dirt simple to-do list that works pretty much anywhere, online or offline. It's designed for desktops, tablets, and mobile devices with good/modern browsers.

Our friends, families, and we have been using it for a few months now with great results. Ultimately, Doneski isn't something we plan to make money with, so we've decided to make the design and code available to anyone, under MIT license. Everything is available on Github, right here.

The story
Last year, we needed a to-do app that worked everywhere, and we weren’t totally happy with any of the available options. So, we rolled our own HTML5 app that supports the interactions and natural gestures we felt best support how a to-do app should work across different devices. We wanted the app to feel comfortable and informal, not unlike our favorite little notebooks (e.g. Field Notes and Moleskine). There's no prioritizing, no dates, no locations to mess with. It's just a little list with familiar metaphors. Here's the core of it:

Install it by adding to your homescreen

Create a new page by swiping left

Add list items, and name your lists. Delete an item by tapping it.

Navigate pages by swiping

See the items you've completed

And of course on the desktop, you can use your arrow keys or mouse to get around.

Experimenting with rich interactions in Doneski allowed us to push the capabilities of mobile device browsers to their limits, and explore the boundaries of offline storage for web apps. The things we learned while making this product have had direct impact on upcoming Seabright products, and products we've built for other companies as well, so it's been a great experience all around.

Is Doneski supported?

Nope. While Doneski works online and offline, we aren’t providing support for it at this point beyond hosting the app. It's important to realize that in this build, your lists are only stored locally on your device, and not backed up anywhere else. We're not syncing or saving anything, since we're not supporting the product.

If there is ever enough interest and use to build Doneski into a full-fledged product, we’ll consider supporting it, and then charging for it.

If you end up using the assets or code for Doneski, let us know!

A few weeks ago I had the honor to be invited to speak at Stanford's Institute of Design (a.k.a. d.school). Given the way we work and think about UX at Seabright, I thought it a good idea to bring John, Seabright's other founder (and engineering director), with me to field UX questions from a technical perspective. I've posted my slides from the talk over on Slideshare, and below. If you'd like to see the slides with notes to make everything more cohesive, I've also posted a PDF with that info right here.

We had a fantastic time, and learned a ton about what the folks at Stanford are teaching. The students kept us on our feet, asked hard questions, and we're looking forward to doing it again. Thanks to Banny Banerjee and Damien Newman for the opportunity!

I don't often drive, but when I do I have a VW Jetta TDI wagon for the job. It's one of the most functional and practical cars available that generally gets over 40 miles per gallon and isn't boring to drive. One of my favorite features of the car, however, might be the most useless. The UI designers at VW made the AM/FM radio interface mimic the old analog dials from the cars I grew up with. It makes me smile every time I see it, and in fact changed my behavior; it's faster to use the buttons, but I prefer using the knob just so I can see the analog band slide up.

When we started Seabright fifteen months ago, we did so because we saw a huge chasm between design/UX company business models, and how products actually get built. Recently there have been some landmarks in the UX/Design world that are too big to ignore. We're seeing clear proof that the business model which worked for UX companies in the first ten or so years is no longer working.

Here are a few of the interesting canaries in the UX coal mine:

• Method was acquired by a development company.
  
• Odopod's Director of Interaction Design, Albert Poon, pissed off legions of designers by stating the obvious.
• Forrester Research just published A New Thesis For A Better Approach To Software Development

When making products and services, strategy and design are vapor without execution.
Design documents as deliverables don't cut it anymore; they're a tiny piece of what makes up a great experience. Things move too fast, software is too easy and cheap to build, and even more importantly, iterate. At least half of our interaction design decisions get made once code is up and running. Code is where to discover problems and new ideas, and iterating in code is far faster and more useful than changing wireframe annotations. Furthermore, design deliverables can't stand up to multi-continent, multi-language contextual use, fast course correction, or A/B testing. Yes, we do a lot of design work in the code.

"Development teams (and developers!) are not coders. They are experience creators."
As Mike Gualtieri so subtly points out in the Forrester article above, Agile software is a cop-out. As a designer, I've seen that Agile™ development yields a bunch of little pieces that may or may not work together. The very nature of Agile forces people to focus only on their piece, and never in multiple contexts. When we hire anyone, it's a requirement that s/he can go between thinking at a systems level and a pixel level regularly. (p.s.: We're hiring a developer.)

You can't design and build an elegant product or service when your success metric is the amount of software created.

Another thing implied in Mike's article is that a rigid process doesn't work well when designing or creating software. Making stuff is too dirty. You discover too many things along the way. You change course. You do things in parallel. All of these reasons are exactly why Seabright doesn't advertise a Design Process™. The reality is, it never looks the same from day to day.

If every single person on your team isn't part of the UX focus, you likely have a problem.
We've been flying this flag for a while now. When we kick off projects with other companies, one of the first things I do is set the expectation that we/Seabright are not the UX team. I clearly state that every single person in the room is part of the UX team, and everything they do - every line of code, every metric tracked, every marketing idea, every pixel pushed, is for one person: the human who will use the product. It sometimes takes a bit of time for this to sink in, and there's certainly a bit of explanation involved. It doesn't mean that everyone is a designer. It means that everyone, both on their own and collaboratively, need to be thinking toward one goal: creating the best experience they can.

Great products can't exist without awesome engineering, design, and customer support. I don't know that we need another acronym or Process™ name to describe what we do, but at a larger level, if it helps the UX industry evolve into actually creating things rather than concepts, and gets people away from the blindfolded Agile development process, then I can live with it.

We'd like to welcome P.J. Onori as the third full-timer at Seabright. He's our first official Lead Product Designer, and comes to us by way of Adaptive Path, where he was a Design Technologist. Before AP, he designed and built products at Current TV, Method and SolutionSet. During his career, he has done work for organizations such as the United Nations, Samsung, Adobe, TED.com and Autodesk.

P.J. is an all-rounder, and splits his energy between design and development. He regularly speaks at conferences, workshops, and industry events. He's been blogging at Some Random Dude for the better part of a decade, and regularly contributes to the open source and Creative Commons communities. He's @somerandomdude on Twitter.

We are excited to have him on the team!

UPDATE: This job is filled. Stay awesome!

As a designer at Seabright, you'll be responsible for setting the visual direction across a variety of projects as well as tackling the pixel level details of any given interface. You'll work on Seabright products as well as products we design and build with other companies. You're well rounded and know as much about designing apps as you do typography, color, and composition. We are interaction design sticklers, and you should be as well.

For this opportunity you don't necessarily need a ton of experience. That said, experience doesn't hurt. We'll fit the gig to the person.

We are willing to relocate you to San Francisco if you:

• prove that you have a great eye for composition, color, typography
• have a portfolio that showcases an exceedingly clear and functional aesthetic
• have a good understanding of web standards
• love interaction design, and understand that form follows function
• know deep down that copywriting is UI design
• can articulate and defend design decisions
• are comfortable speaking with partners and clients
• have experience designing web-based apps
• want to work in a highly collaborative product development environment
• know that Flash is dead
• want to solve real problems for real people.
• have a sense of humor, and a distaste for prima donnas

Super bonus if you are also efficient with front-end code (CSS, HTML, JS, etc.).

What we're looking for, Part II
We don't have a certain design style in mind, though we know what we like. We are, however, looking for a someone who approaches problems the right way, and has a high level of taste. We never stop challenging ourselves on clarity. Clarity is driven by copywriting, code, graphic design, and interaction design. You, and your portfolio, should be clear.

How to apply
Send relevant work samples, and a persuasive letter about why you're the best fit for the job to jobs@seabrightstudios.com. If we think you're a good fit, we'll be in touch with next steps. Thanks for your interest, and we look forward to hearing from you.

There's been a lot of writing and talking about the concept of Responsive Web Design, and while it's great that people are thinking of these things as they design and build their products, there's more to it than just the screen size/layout/aspect considerations being put forth. It's time we change the definition to better reflect what designers and builders need to think about in their development processes.

There are a few beautiful galleries that showcase the concept as it is today, such as Mediaqueri.es, and there's at least one book on the subject. Most recently, Joni Korpi released the very well executed Golden Grid System. As a product designer, it is clear to me that the capacity in which people have defined Responsive Web Design is only looking at it from a layout and typography perspective. If we are to put forth the notion of truly responsive product behavior, we also have to think in terms of device capabilities.

What are device capabilities?
As mobile devices continue to change the content consumption and product usage landscape, it is likely that you, the designer/builder, are having to think about your product in terms of more than just the desktop experience. Sure, a layout that responds to screen size and device orientation is important, but that's the lipstick on the Interaction Pig that lies beneath any product.

We see device capabilities as the set of hardware and software factors that have the capacity to change how a product behaves.

Designing for Device Capabilities
When thinking about how a product should behave across different devices in different contexts and environments, these are the five device capabilities that influence our design and development decisions:

1) Display
What kind of screen is it, and how big is it? Screen size, resolution, orientation, and screen type all fit here. This is also the only piece of the Interaction Pig that Responsive Web Design explicitly addresses.

2) Input Mechanisms
What are the ways in which I can manipulate stuff? Touch patterns, gestures, mouse, keyboard, audio, and camera are all input mechanisms for different devices. There are probably more.

3) Feedback mechanisms
What feedback can the device provide to the user to enhance the product experience? UI discoverability (e.g. can there be hover states? Does the browser on this device support progressive disclosure of forms?), alerts, vibrations, audio feedback, etc.

4) Processing and storage
How fast is the device? Can local storage be used to enhance the product experience? As mobile devices become more powerful, this single capability is changing the way we can build for high performance web-based apps. For example, we've learned (the hard way) with HTML5 apps, tiny details such as drop shadows can have huge negative impact on performance. We've also learned that it is possible to store surprising amounts of data locally on iPhones and Androids, which can have great results for interaction response time.

5) Environmental
Is the device capable of behaving differently in different environments? Does the device change modes if it’s dark vs. daylight? What happens to voice input in noisy areas? Will the GPS still work if the device is sleeping while I'm on my daily run?

-----

And so you have our definition and initial list of device capabilities.

There will be two posts following this one in which we show how these considerations translate into real product design and code. Next, I will lay out the design process for a particular screen in our upcoming product, Doneski, and following that, John will take that same screen and show you how it is possible to write clean, efficient code that works for different device capabilities.

Until next time, we'd love to hear what you think about this evolving concept.

Two years ago I was in Auckland, New Zealand visiting friends, and had the fortune to be introduced to Ben Bell. Ben is the founder of a company called Low Impact, and at the time, the inventor/designer/developer of a yet-to-be launched, fascinating composting system (yes, a fascinating worm farm). In 2009, the product had no name, was still in prototype/refinement, and Ben was working around the clock to obtain funding for the product. Ben’s passion was infectious, and after a thorough tour of his prototypes and castings, I immediately became a believer and fan of his worm composting system.

Low Impact recently launched their flagship product (and beautifully written and designed accompanying site), which is called Hungry Bin.

This week I managed to get a few minutes of Ben’s time, and he agreed to an email interview. Read on as Ben takes us through all sorts of interesting design and development concepts related to worm farms, composting, sustainability, raising capital, and running a small, innovative company.

Ben, what's your company called, and what do you do?

My company is called Low Impact. We have just launched a worm compost system, or worm farm, which I have been developing over the last three years. The product can be used to process a wide variety of organic waste, and convert it into high quality fertiliser.

Who would use a worm compost system?

Worm composts are great for anyone that wants to reduce the amount of food waste they are throwing out, and even better if they have a use for high quality fertiliser. In this country (NZ) the urban waste stream is made up of about 50% food waste, which is a tragedy when you consider how important the nutrients contained in food waste are to the environment.

Why would someone use a worm compost system?

Well for a start worms are pretty amazing little critters. Not only do they eat their weight in food a day, but they turn it into the best fertiliser there is. They need very little room and they work 24 hours a day. Worm compost systems are perfectly suited to incremental feeding, which is exactly how we create our waste, a little bit each day.

You mentioned the urban waste stream. What’s that?

In New Zealand we call it rubbish, in the US I believe you call it trash. This is the stuff that rubbish trucks take to that magic place called ‘away’! In the western world, most of the waste stream is recyclable or reusable. In my city, as I’ve mentioned, nearly 50% of it is food waste, the disposal of which is expensive for both the environment and the economy.

How is this different from other commercially available worm farms? Or say, me putting stuff into a big plastic rubbish bag?

Our farm is a lot more efficient than the other products in the market because of it's unique design. It is very clean, simple and easy to use. The design reduces the labour required to operate a worm compost substantially. It even comes on wheels so you can move it around.

What happens to that bag? Generally it's trucked a long distance where it's thrown into a landfill. Both these things are very bad for the environment. Landfills produce methane which is a powerful greenhouse gas. I see the food waste in your rubbish bag as a resource that should be used, not a problem that should be thrown away.

Can you elaborate on the design characteristics to explain why it works so well?

Firstly the design maximises the surface area, which increases the available area the worms have to work in. As the castings are produced by the worms, they are forced down through the bin by the weight of new material, and compressed by the taper. The compression forces the worms to the surface, and at the same time squeezes water from the castings, making them easier to handle. The taper ends in a chute, which is covered by the floor. When the floor is released a discrete block of casting falls from the bin. This makes harvesting castings a very simple and fast process.

Oh! In geeky detail, what are the worms doing that makes it all work?

Compost worms not only eat their weight in food a day, but they are carnivorous! They are eating the food to get to the bacteria and microorganisms that are rotting it. In the process they grind the rotting food up, and convert it into very high quality natural fertiliser. Plants and worms have evolved symbiotically, so plants respond very well to vermicast and liquid, as the nutrients are in the perfect form for them to uptake.

Where does one get worms to get a Hungry Bin up and running?

Hungry bin uses any kind of compost worms. These are different worms than regular earthworms as they eat organic matter, not soil, and do not burrow like earthworms. We supply them locally in NZ, and most parts of the world have local suppliers of compost worms. You can also find compost worms in the environment all around the world, the best place to harvest them, funnily enough, is from a compost bin...

I’ll bet some people are put off by the idea of messing with worms. What advice do you have for them?

One of the great things about a hungry bin is that you do not have to handle the compost worms. I have specifically designed the product so that the worms do not get disturbed as they go about their business. If you cannot bear the thought of even looking at worms, you might have to find someone else to look after them for you...

Are you chasing a passion for worms, or did you identify a problem, and set out to solve it in a superior way?

I grew up in a family that always had a great garden and appreciated good fresh vegetables. We always had a compost pile at home as a kid. In town as an adult, I started with a commercially available worm farm and found that it did not work as well as I would have liked. I knew that compost worms are really amazing, but I didn’t have room for a big compost pile, and in town, rats are a big problem. Like a lot of kiwis, I have an inventive streak, recognised a solution to a problem, and the rest as they say is history.

What were you doing before Hungry Bin?

I left the film industry to work in Sustainability management. From there I started to work on hungry bin, which has been a full time job for the last 4 years.

What does it actually take to get a product like this from concept to launch? Specifically, let’s hear about your design process as well as your development process.

This product took about six years from conception to launch. The refinement of the idea took about two years once I had the original concept. I began by cutting up rubbish bins and welding them together with a plastic welder. Later I was able to make prototypes and commercial test models as I got the funding. From that point I was able to prove the business model and gain the interest of investors. Once the design itself was locked down, the production process took about 8 months.

It takes a lot of dedication, self belief and dogged perseverance to get a project like this into the world. If I wasn’t so stubborn, I don’t think I could have done it. I’ve also had to do a lot of the work on my own, so a sense of self reliance has been vital. Now that I’ve got other people working alongside me, it’s great to have someone else to take up some of the work load.

Were there any big frustrations or hardships during the protoyping and funding time?

The hardest part of it was keeping my own optimism that I could find some people who believed in the product and the idea as much as I did. It was a very hard time, you have to have complete faith in the idea and the product, but at the same time manage the reality of paying the bills!

I remember you telling me you were trying to get the New Zealand government involved with funding.

Yes. Both Local government and central government funds have been involved. A local government fund (Waitakere City, Waste-Not Fund) contributed 15k early on which allowed me to undertake a commercial test with some low cost prototypes. A central government business development program called Escalator (funded by NZTE and delivered by Deloitte) assisted me with business development and preparation, and completion of the capital raising process. The funding I received has been a vital part of the process, it’s very hard to tell a venture capitalist “I have this great idea, and I need you to give me money so I can work out how to explain how good it is!”

In which countries can one buy the Hungry Bin? Because I know here on the West Coast of the United States, people would go nuts for this product.

We have just launched in NZ. We will be looking to expand our markets as soon as we can. If you know someone that would be a good partner for our expansion into the US or any other markets, we’d love to hear from you.

The problem that hungry bin solves is universal. Because the hungry bin system is modular, it can be easily scaled to meet the needs of any household or business. This means that the knowledge required to run one hungry bin is identical to that needed to run 100!

The product has been designed to be as freight efficient as possible, the size of the product was actually constrained by the freight size. We are very firmly focused on expanding into other markets in the near future, but need to ensure that we have made a success of it here first.

Will you secretly ship me one, so I can be the envy of all my San Francisco friends?

If I secretly ship you a hungry bin, I’ll have to ask that you be not so secret about it once you’ve got it! We need all the champions and advocates we can get!

Here’s a deal. The hungry bin is optimised for a 400 units in a 40’ shipping container. If you find 400 friends that all want one and are prepared to pay for one, we can ship them to you for a very special price! Wouldn’t that be cool? Crowd sourced importations! Why don’t you put out a post to your social networks, find 400 buyers, and we’ll get them on the water before you know it...

How big is Low Impact now? What are your plans for growth?

We have three full time employees right now. We’ve only been trading for 5 weeks! We anticipate that we will grow rapidly as our plans to expand into the market come to fruition. There is a very large opportunity to use the hungry bin on a city wide scale to process waste, so who knows how big the project may become if enough people like it.

What does success look like to you with regards to your company?

I think success for me will be when hungry bin is seen as one of the best ways to reduce the organic waste stream in the urban environment. We hope to also change the way people think about waste, from a problem that needs to be taken away, to a resource that should be utilised. The other day I saw a hungry bin at someone’s house who I didn’t know, which was really amazing. It’s very special when other people like your ideas.

Virgin America continues to be The Golden Child Airline when it comes to service design and interaction design (which, in my mind are the same thing). This morning they proved to me yet again why I go out of my way to fly with them.

Provide the path of least resistance.
I received an email from Virgin this morning for $54 fares from San Francisco. I'd been wanting to go visit friends in Seattle, so I found round trip tickets for $108. Easy decision. I went through the booking and seat selection process (which, honestly, could use some IxD help), and when I got to the payment screen they showed me this as my first payment option:

I'd forgotten that I had this credit, and upon seeing this option I was reminded that Virgin had emailed me a couple months ago reminding me of this credit. No sales pitch, just a, "Hey, don't forget! You have this credit with us." message.

Put the burden on you, not your customer.
This one blew my mind. As I was looking through my booking, I had a question around whether or not I could spend it on someone else. I reluctantly clicked a link to talk to someone, and got this:

This little UI and service concept completely turns the idea of dealing with a customer service rep on its head. Rather than putting me into a hellish automated system, they just ask for my phone number, and when I'd like to talk. Really? Awesome.

I entered my number, and immediately got a call. There's one bad part of the call, but the follow up was incredibly elegant. First, the bad part: the automated system told me, "We're sorry, it's going to be 6-11 minutes before we can help you with your question. Would you like us to call you back when we can chat?"

I said sure (by pressing a number and hanging up).

Seven minutes later, Virgin called me back, answered my question, and now I'm going to Seattle to see my friends and ride bicycles.  It's obsession with this kind of interaction design detail that earns companies like Virgin my loyalty.

In a couple of weeks, Seabright will be moving our world headquarters to 360 Ritch Street, San Francisco, USA. This move is being driven by steady (and purposely slow!) business growth, a need for project spaces, more Seabrighters, and the desire to be closer to our old haunts in South Park. The new digs will have dedicated parking for visitors, a roof deck, and plenty of sunlight.

We'd like to give huge thanks to our friends at Markatos Moore for sharing their space with us over the past nine months. It's been a great time!

We're excited about things to come, and will provide details once we're moved in.

"I’m convinced that for an existing company to innovate, they must first make the decision to get rid of something. Unless you get rid of it, it will always be a more compelling argument to improve the old rather than commit to the new. That small decision over time adds up to a total deflection, and you are never as motivated to innovate as the unencumbered new entrant."

"If you have the skills to do client work, you have the skills to make your own product. You’re selling yourself short by selling that on a work for hire basis."

-Jim Coudal on this SVN post

I agree with the sentiment here, but I don't believe Jim's is a true statement. It takes much more effort, iteration, resilience, risk tolerance, and follow through to make your own (successful) product.

We get a lot of variations from prospective companies on this question: "So what exactly does Seabright deliver?" That core question is usually followed by things like, "...design deliverables? Photoshop files? HTML templates? Strategy documents?"

The answer is simple: we deliver working products.

Sure, research, design and strategy can be key to a successful product, but we see those things as stepping stones to the product/service/app. For example, a strategy document in and of itself isn't valuable unless the execution on that strategy is nailed. We've found that if the team that creates the strategy and design also builds it, chances for success are much higher.

The following excerpt from this Smashing article does a pretty good job of articulating why we choose to deliver products rather than documents:

"Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed."

Taking this a step further, the following concepts are key to how we work. We've found these things to hold true, no matter if we're working on our own products, or with other companies.

1) Design is not a phase in a process
Anyone who has designed and built successful products knows that design never ends. Anyone that says differently is trying to sell you an incomplete service. Sure, things often start out with research, and then on paper or in wireframes, but when you're designing a product, as opposed to designing documentation, design is never done.

2) Great developers are also good designers
In my 15 year (so far) career as a designer, the best collaborative design experiences I've had were with engineers. They approach design problems from a different viewpoint, often uncovering valuable interaction design considerations that couldn't possibly be discovered in documentation.

3) Development is not a separate thing from design
Both design and development are equal and key components to creating an awesome experience. Product performance, error considerations, connectivity, and so on are all directly related to user experience, and lie directly in the realm of development. Once you accept that a great developer can also add huge value to design, your view on product development grows exponentially.

Relationships between UX firms and companies need to change
These days, software is cheap to create. Teams can be tiny. Instapaper, one of my favorite current apps, is one guy. The days of big teams working on process-heavy and infrastructure-heavy projects is screeching to a halt, and eventually corporations will catch up to this reality.

These changes should be recognized by the UX world, and embraced immediately. To do so requires a fundamental shift in the way we think about working with companies, and the way we perform and add value. Beautiful specifications and deliverables no longer apply. Strategy documents are empty without execution. The line between design and development is greyer than it ever has been. With two or three people, we can research, design, build and test apps that serve millions of people. To execute in this way though, the nature of our relationships has to become more team-like, and less "here are your deliverables, we're on to the next thing".

When design and development folks have the same goal (to create the best possible experience when using a product/service/app) they stop differentiating themselves by team type. The focus starts to lie solely on the product experience, and the different skills held by people are just tools through which tasks are completed. This can be the case on in-house teams, and with teams within services firms. We do both everyday.

UX = Design + Development. It can’t exist without both.
We’ve spent the past 15 years on both the design firm and product development sides of the fence, and we started Seabright because we know there’s a better way for user experience companies to operate: build what you design. After all, it’s not actually designed until it works.

We’ve seen the shortcomings (and frustrations) of the traditional design firm model, where a set of beautiful design documents, concepts, or HTML templates are delivered, and you are wished the best in building the actual product. Anyone that has ever built a successful product knows this model is antiquated and broken. It simply doesn’t work for today’s dynamic, ever-changing products where decisions are made based on data and human behavior rather than site maps, or any kind of maps for that matter. No matter how good of a designer you are, you can’t possibly think through all of the scenarios, constraints, tweaks, and errors that happen during development. Design doesn’t end until you have a real, working product. Actually, it doesn't end there either, but that’s for another post.

At this point, we can officially turn on the lights and flip the sign to OPEN.

We'd like to publicly thank a few folks for support on any number of bits of advice, help, feedback, and otherwise: Michael Vizzina for our logo, our friends at Adaptive Path, our friends at Mule Design, P.J. Onori (for the mug shots on the About page), Michael Lopp, Gina Bianchini, Damien Newman, and Erik Swan. You guys rock, and I wouldn't be able to write this post without the help and guidance you've given us so far.

Thanks!