Ryan's been getting to the bottom of things at 37signals since 2003.
[On Apple’s integrated organizational structure]
Normally, in well-functioning markets, vertical integration is suboptimal. However, if transaction costs in the vertical chain outweigh the losses due the inefficiencies of being vertically integrated, then vertical integration could be the correct course of action.
Apple thinks the exact same way, but not about monetary cost; instead, the transaction costs they consider are the tax that modularization places on the user experience, and it is a cost they are not willing to bear.
A design has to start with some initial conditions, and then adapt to the boundary conditions – the conditions it encounters as it evolves. This can only happen through recursion, which is how our design achieves adaptive evolution and a much better “fit” with the problem. We might have a very good intuition of what the design has to embody – Steve Jobs, for instance, was famous for his intuition of the final qualities a design needed – but then large teams of people had to refine that initial vision and bring iterations to him to evaluate. He was setting the initial conditions (what he wanted the devices to be able to do for people), as they were adapting to the boundary conditions.
I talked about software design and seeing through the customer’s eyes for 30 minutes on Jobs-To-Be-Done Radio. In my favorite part we thoroughly debunked personas and talked about how situations, not attributes drive behavior. Hosts Bob and Chris are collaborators of Clay Christensen and they strongly influenced my thinking over the past year. It was a blast to chat on the show.
It’s hard to speak meaningfully about your own design process. That’s why I was thankful for William Channer’s questions when he interviewed me on his podcast. We went deep into topics like what makes a design successful, how to define what is valuable for users, mistakes that teams make, and much more.
There are sites, books, feeds, magazines, and movies about “design.” Thousands of people call themselves “designers.”
But have you noticed … “design” never means the same thing?
When I click on some “design” link, I feel like I’m spinning a roulette wheel. Will it be about:
Grids and Helvetica?
How to balance trade-offs?
Applying engineering capability to a non-engineering problem?
Check in on your projects from anywhere. Basecamp for iPhone shows you the latest news on each project.
Jump in on a discussion and post your thoughts.
View progress as team members complete to-dos and upload files.
Look up anything in a project. Refer to a document or make a decision no matter where you are.
We discovered it’s very important on the phone to make sharp priorities early in the design.
Our top priority was fast access to news. You’ll find the app makes it addictive to check in and feel the pulse of your projects throughout the day. You can quickly bounce in and out of projects. Project screens on the phone show the latest news first rather than static project contents.
Our second priority was to offer the full depth of Basecamp. After you dip into a project, you can go deeper and browse its contents. A menu offers all the project sections like Discussions, To-dos, Files, and Documents.
Iterating on iOS is tricky. The medium isn’t as flexible as HTML and CSS. To cut this down we used a hybrid approach. The page stacking behavior and navigation menus are native, while the rest of the screens are web views. Prototyping on Paper came in handy for evaluating native design ideas before committing to code.
We also used some shiny new tech. The app is built in RubyMotion. We barely touched Xcode. Look forward to some posts from Nick for details on that.
We’ve been using the app constantly since we first had a prototype in our hands. I’m thrilled to share it with you today. It’s available now for free in the App Store.
NOTE: Basecamp for iPhone requires an account on the new Basecamp (released March 2012). Basecamp Classic is not supported.
THAT’S THE THING ABOUT ALL OF THIS. IT’S ABOUT CHOICES. YOU CAN DO ANYTHING YOU WANT WITH A CAMERA, BUT WHEN HULK ASKS THAT ALL IMPORTANT QUESTION OF “WHY?” THERE BETTER BE A REASON FOR IT. AND WHEN YOU GET THAT ANSWER, IT BETTER SPEAK TO THE ACTUAL DESIGN OF WHAT PEOPLE ARE GOING TO FEEL FROM IT. OTHERWISE, YOU ARE NOT IN COMMAND OF YOUR MOVIE. YOU ARE NOT IN COMMAND OF YOUR CRAFT.
Interface design is a two-person dance. By definition it connects two things—the customer experience and the hidden machinery. As a designer, you need a programmer to accomplish anything significant.
I’ve been thinking a lot about teaching UI lately. How do you teach interface design if you can’t get anything done without a programmer at your side? Pair beginner programmers with beginner designers? Sounds like a mess.
Then I remembered my own experience. When I started making interfaces in sixth grade, I didn’t need a programmer because I had Hypercard. Shortly after that it was Filemaker and Microsoft Access. These tools let me connect with data and display it in different ways without convincing a programmer to work with me. It was plenty to learn the fundamentals.
I haven’t seen a UI course that starts with a tool like Filemaker. And Hypercard doesn’t even exist anymore.
If I was designing an introductory interface design course, I think I would start with this kind of tool. Something that lets you gain the experience of putting affordances on the screen, accepting input and displaying output, moving around and enabling tasks.
That way students could get a feel for interfaces without getting into the complicated dance of communication, programmer languages and shared requirements. That all can come later.
Remember the web before Movable Type? If you wanted a blog you had to program one. You had to know databases and webhosts and PHP or Perl. If you were “just” a web designer, or a writer with ideas, you had to hire an in-demand web programmer to make it happen. Publishing was expensive and hard.
Apps like Marco Arment’s The Magazine give me flashbacks to that time. Wouldn’t it be awesome to publish my own magazine on the iOS Newsstand? People could read my articles on their iPad Mini, pay without typing in a credit card, and automatically receive new issues as they come.
Sounds great. But here’s the thing. To be on the Newsstand you have to program an iOS app. The tech hurdle is high, and hiring isn’t cheap. iOS programmers are in extremely high demand.
Now is a great time for another Movable Type. Writers would love a way to push serialized content straight to tablets, and the experience would be a boon to readers. Tablets are the best way to read, and Newsstand is the equivalent of RSS for non-geeks. Hopefully apps like The Magazine inspire somebody to make this happen.
Come out to WindyCityRails in Chicago on September 6 to see me talk about “Essentials of Product Development.”
A lot of us here on SvN are product people. We know it’s not just the UI, engineering, or business idea that make a product. It’s how you bring them all together to make the world better than it was before.
I’ll share lessons from years of experience designing and building products at 37signals in the talk. Actually the things I’m most proud of aren’t even our official products. They’re the things I made on the side. It’s incredible what you can do with those few hours on nights and weekends when you have a strong hold of product development.
Many of us have deep questions that go beyond making a better product. We want to know how to make more progress on our product. Getting there requires you to bring the talents you have together at the right time, in the right order, with the right people, on the right things.
That’s the fundamental challenge, and I’ll be sharing techniques I’ve learned over the years to cut through it and make more progress on your product.
WindyCityRails is a great conference. I hope you’ll come out and see the other speakers too.
It takes more than talent to make a great product. You also have to focus on the right things, in the right order, with the right people at hand. Ryan will explain key points for successfully developing product so you can make the most progress on your big idea. The talk will cover common pitfalls, techniques for seeing the bigger picture, and advice on how to bring the different roles together.
See you there! Thanks to Ray for inviting me again this year.