 1 Introductions
|
 1.1 Jason Fried - product manager
|
1.2 Ryan Singer - interface design
|
1.3 David Heinemeier Hansson - program, ruby on rails
|
1.4 Matt Linderman
|
1.5 Sam Stephenson - programming, javascrip framework, ajax
|
1.6 Marcel Molina - programmer - rails developer
|
1.7 Jamis Buck
|
2 What is Getting Real?
|
2.1 principles rather than rules
|
2.1.1 less procedures and writing stuff down, more thinking and using common sense
|
2.2 intuition has space to work -- room for flexibility and changes
|
2.3 What Getting Real Is Not
|
2.3.1 NOT - staffing up for six months from now
|
2.3.2 NOT - long term plans and fortune telling
|
2.3.3 NOT - scaling ahead of time - you may never have a million customers. Don't worry about planning for them until you build a customer base.
|
2.3.4 NOT - making money later -- make money now. Don't rely on the "Lottery Ball" - bad odds of being bought by google or yahoo, make the business to stand alone. Ads are not a real business.
|
2.3.5 NOT - Mistakeaphobia. Make lots of small mistakes to fix them. Change should be easy. Don't be paralyzed by the possibility of mistakes. Fail early, fail often.
|
2.3.6 NOT - documents that die - capture everything in real wireframes that morph into the html
|
2.4 What Getting Real Is
|
2.4.1 YES - interface drives the product (user - centered design). Let the wireframes explain what the product does.
|
2.4.2 YES - Using the product while you build it (in HTML & code -- not walkthroughs!)
|
2.4.3 YES - making sure the business scales - Flickr is expensive processing to be a "for free" product. Should start with smaller apps.
|
2.4.4 YES - ignore imaginary problems - don't worry about what ifs?
|
2.4.5 YES - the future drives the future. Writing specs is letting the past drive the future. Push tough decisions out into the future. Putting off making the decisions will let you find more information to solve the problem, or more resources.
|
2.4.6 YES - mistakes are good things. Lower the tolerance for mistakes. There is never a finished piece of software.
|
2.4.7 YES - lowering the cost of change - change is expensive when you have too many people on your team, when you write documents that are too complex, when you try to include too many features, when you iterate too slowly, when you apps are too complicated.
|
2.4.8 YES - just wing it and figure out what works.
|
2.5 SKUNKWORKS PROJECTS - ways for large companies to create "small team" workability inside the company.
|
2.6 Large companies - this can work with small teams inside them working on small projects
|
3 Where do you start?
|
3.1 Build Your Team
|
3.1.1 hire generalists - people who can do more than one thing, or at least have a good understanding and appreciation of other's specialties. Design is not separate from code or scripting. i.e. -- CSS decisions affect ajax.
|
3.1.2 hire happy people - morale is everything!!! Don't hire negative people.
|
3.1.3 hire great writers - people who can communicate well with other people.
|
3.1.4 Hire less, and hire later. - three people for version one projects. programmer, designer, sweeper (between both worlds). Not trying to give birth to a twenty-year old - reduce the scope to a smaller feature set. Smaller teams give you a fighting chance of getting a culture built. "Any time you decrease the scope, you necessarily increase the sensitivity to what's important"
|
3.1.5 Build it, and see if it's what people think is important.
|
3.1.6 People in different timezones - too much talking, not enough time to focus on the work. Meetings are not the way to do problem solving.
|
3.1.7 Hire from open source for the right programmers - can see what people do and how they do it, what their culture and philosophy is, finishing work. People who love programming do open source work. Designers were given the task of redesigning the Verizon home page -- without guidelines.
|
3.2 Define your Mantras (develop your philosophy; things you say several times a day)
|
3.2.1 less software - don't accept requirements at face value - chop off the features that are too expensive to create, especially in initial phases.
|
3.2.2 Say no by default to features - because there are always more ideas than you can handle at first. If they come up repeatedly, say maybe. If they're requested over and over, then say yes. Steve Jobs - most proud of the things he said no to.
|
3.2.3 "It doesn't matter" - don't spend time on small features that don't matter to the big picture. It's an ego-buster to embrace this. You are not a unique snowflake; you're not creating something that no one has ever thought of.
|
3.2.4 Done -- a decision has been made and we can move on. Make the change later if the decision wasn't right. The done-o-meter -- similar to getting up from a restaurant meal; you all get up at the same time.
|
3.2.5 Decisions - should be like choosing where to go to eat. Only make the decision when you'r really hungry for it, otherwise put it off. If you're not happy with the restaurant you chose, that's okay, just go somewhere different tomorrow.
|
3.2.6 Make your project half, not half-ass (less features, done better.)
|
3.3 Define Your Vision - what's the big idea behind the project. What is the project about, (and what is it not about)
|
3.3.1 Basecamp : "project management is communication (not about control)"
|
3.3.2 Backpack: "bring life's loose ends together"
|
3.3.3 Campfire: "chat is a destination"
|
3.3.4 Ta-Da List: "competing with a post-it note"
|
3.3.5 Writeboard: "word is overkill for most things you write" (that aren't novels). Wikis are not for humans -- they're for techies.
|
3.4 Start Building
|
3.4.1 No functional specs -- Spec documents have no effective function in the real world
|
3.4.1.1 They're political documents - they're just blame deflector shields
|
3.4.1.2 specs are all about yes -- no cost to adding bullet points to a word doc, but the real cost of that bullet point is HUGE!!!
|
3.4.1.3 Illusion of agreement -- about people thinking they agree on decisions when they really don't agree at all.
|
3.4.1.4 Locked into decisions that you made three months ago, when those are no longer the right decisions.
|
3.4.1.5 No push-back from the builders on the real costs of building, or best methodologies of building.
|
3.4.1.6 Abstracted, not real. - detail level of the documents doesn't really mean anything, and is too weighty and difficult to read.
|
3.4.1.7 Bullet points are small on word docs, but huge on actual real estate
|
3.4.2 Instead, Get Real (each of the following, but rinse and repeat) Not a process of "throwing things over the wall" to the other part of the team.
|
3.4.2.1 ideas - regular communication
|
3.4.2.2 paper sketches
|
3.4.2.3 html screens - photoshop screens are too much invested in a dead document
|
3.4.2.4 prototypes - codes underneath html (later refined color)
|
3.4.2.4.1 Christopher Alexander (architect) Quote - ??
|
3.4.2.4.1.1 cardboard mock-ups of architectural features presented on the real site, so you understand how how things work in the real setting.
|
3.4.3 Capture ideas of the project. Examples of how they did it with their own projects.
|
3.4.3.1 basecamp ideas
|
3.4.3.1.1 post project updates
|
3.4.3.1.2 client participations
|
3.4.3.1.3 project milestones
|
3.4.3.1.4 centralized archives
|
3.4.3.1.5 dashboard view
|
3.4.3.2 Backpack
|
3.4.3.2.1 life's loose ends
|
3.4.3.2.2 basecame is overkill
|
3.4.3.2.3 pages with simple tools
|
3.4.3.2.4 "keepshare"
|
3.4.3.2.5 remind me away from the computer.
|
3.4.3.3 Writeboard
|
3.4.3.3.1 simple text editing and sharing
|
3.4.3.3.2 I don't need and acount
|
3.4.3.3.3 remember everything I wrote (versioning)
|
3.4.3.3.4 Compare versions (which is better?)
|
3.4.3.4 Campfire Features
|
3.4.3.4.1 chat should be a destination
|
3.4.3.4.2 file sharing over IM sucks
|
3.4.3.4.3 what did I say last week?
|
3.4.3.4.4 Persistence.
|
3.4.4 Make paper sketches
|
3.4.4.1 Fast, easy cheap, but meaning conversations
|
3.4.4.2 Sketch radically different ideas
|
3.4.4.3 Experiment with priority
|
3.4.5 Design screens in HTML (logos from tada on backpack -- leaving space)
|
3.4.5.1 Screens are common ground
|
3.4.5.2 customer experience
|
3.4.5.3 ready for programming
|
3.4.5.3.1 launched without search, because no one had content in the system
|
3.4.5.3.2 launched without billing because they couldn't bill for 30 days anyway.
|
3.4.6 Get the prototype working
|
3.4.6.1 Use it while you build it
|
3.4.6.2 you'll find mistakes later
|
3.4.6.3 you'll discovered what's missing
|
4 Fleshing out features
|
4.1 don't confused enthusiasm with priorities
|
4.2 Beware Feature Loops
|
4.2.1 features lead to more features
|
4.2.1.1 adding a meetings tab to basecamp
|
4.2.1.1.1 invitation management
|
4.2.1.1.2 calendar management
|
4.2.1.1.3 conference room booking
|
4.2.1.1.4 people without a basecamp account
|
4.2.1.1.5 links to other basecampe components
|
4.2.1.1.6 time issues
|
4.2.2 Hidden Costs of Features
|
4.2.2.1 support
|
4.2.2.2 documentation
|
4.2.2.3 tour - having to update this
|
4.2.2.4 terms of service requirements
|
4.2.2.5 clutter
|
4.2.2.6 more software
|
4.2.2.7 localization
|
4.3 Making opinionated software
|
4.3.1 software that isn't right for everybody
|
4.3.2 Avoid preferences
|
4.3.2.1 Examples of "Non preferences" in basecamp
|
4.3.2.1.1 # messages per page/fixed at 25
|
4.3.2.1.2 overview page items (fixed at 25)
|
4.3.2.1.3 Due in the next 14 days
|
4.3.2.1.4 Message list sort order fixed
|
4.3.2.2 Backpack non-prefs
|
4.3.2.2.1 alpha sort sidebar
|
4.3.2.2.2 fixed object group order
|
4.3.2.2.3 fixed relative reminder times
|
4.3.2.2.4 fixed home page
|
4.3.2.3 Campfire
|
4.3.2.3.1 5 minute time-stamps
|
4.3.2.3.2 enter/leave messages
|
4.3.2.3.3 permissions
|
4.3.2.3.4 chat text formatting
|
5 From features to screens -- the basic interface design process
|
5.1 decide what to design
|
5.1.1 mental list of "Must haves" - shouldn't have to write them down, because they should be a short list
|
5.1.2 do a small sketch
|
5.1.3 code the html
|
5.1.3.1 Do the message, not the frame. Build the middle rather than the wrapper of any given page. - The EPICENTER - start with this on any prototype. No photoshop prototypes. Build in HTML.
|
5.1.3.2 Design centers of activitiy, not wireframes
|
5.1.4 pages have many states -- so dump wireframes and build the pieces, rather than full pages.
|
5.1.4.1 sample "black slate" state (when you enter your user data, your page will look like this)
|
5.1.4.2 working state - what we usually see
|
5.1.4.3 error state
|
5.1.5 Visual weight
|
5.1.5.1 you decide what's important
|
5.1.5.1.1 Show differences in both directions (standing out, standing back)
|
5.1.5.1.2 focus on the data, rather than the grid -- make the numbers pop and the table recede
|
5.1.5.1.3 yellow fade technique -- shows you the thing that you just changed. demonstrate in backpack.
|
5.1.5.1.4 Same interface for admins and clients (and beta testers) - turn off stuff for people with less permissions.
|
5.1.6 When a problem is too hard, change the problem
|
6 From Screens to programming
|
6.1 Be happy - set yourself up for happiness
|
6.1.1 motivation is best grown from happiness
|
6.1.2 optimizing for happiness before anything
|
6.1.2.1 beautiful code (simple, readable, clean, sturdy, maintainable, fast)
|
6.1.2.2 Convention over configuration
|
6.1.2.2.1 conventions have a learning curve -- but should be made on common sense
|
6.1.3 Things to beware of:
|
6.1.3.1 Beware dangerous statements -- "that should be easy" - the notion that you can foresee all the implications of a change
|
6.1.3.1.1 Quick fixes are the most dangerous -- that's always the line of code that breaks
|
6.1.3.1.2 "Just" and "only" -- sedates you. Take these words out and repeat the question. - think
|
6.1.3.1.3 Contagious
|
6.1.4 Beware of science projects
|
6.1.4.1 avoid algorithms and other cleverness - fake being clever. Why calculate the percentages how long a bar should be when you can fake an increase in the bar.
|
6.1.5 Beware the question "But will it scale?"
|
6.1.5.1 Nothing ever scales on the first try
|
6.1.5.2 Can't anticipate where the scale will be needed -- might be on wrong areas.
|
6.1.5.3 look forward to the day people care
|
6.1.6 Find an environment that works with values you care about
|
6.1.6.1 Working with your good angel
|
6.1.6.1.1 work in iterations
|
6.1.6.1.1.1 group changes together
|
6.1.6.1.1.2 use short (preferably weekly) iterations
|
6.1.6.1.2 Stop treating bugs as special
|
6.1.6.1.2.1 prioritize bugs alongside features
|
6.1.6.1.2.2 bugs don't always deserve immediacy
|
6.1.6.1.3 Personify the software
|
6.1.6.1.3.1 listening to suggestions
|
6.1.6.1.3.2 mind the hygiene, clean up bad code smells
|
6.1.6.1.3.3 pay attention to long-term health (avoid quick fixes)
|
6.1.6.1.4 Trade concessions
|
6.1.6.1.4.1 clarify the price of itnerface elements - get the cost out into the open
|
6.1.6.1.4.2 strive for best value
|
6.1.6.1.5 Start testing today
|
6.1.6.1.5.1 reduce stress
|
6.1.6.1.5.2 build confidence
|
6.1.6.1.5.3 enable courage
|
7 From Programming to User Testing
|
7.1 37 signals doesn't "user test"
|
7.1.1 "making your own dogfood" -- if you're making an app for a customer, (instead of yourself) you should be involving your user in the testing process at every step of the process, as new features are added.
|
8 On to promo and launch
|
8.1 Don't get hung up on domain names
|
8.1.1 basecamphq.com
|
8.1.2 backpackit.com
|
8.1.3 memorable names are better than descriptive
|
8.2 Don't issue press release
|
8.2.1 blah blah
|
8.2.2 tell a story instead
|
8.2.3 write something that people wnat to read
|
8.2.4 sink marketing money back into the product
|
8.3 Best promotion is a good product
|
8.3.1 let people use it, try it, use it - they'll tell other people about it
|
8.3.2 if you have to sell your product, you aren't building a good enough product. build something good, and people will talk about it.
|
8.3.3 Emulate drug dealers
|
8.3.3.1 give people a taste, get them hooked, get them to upgrade.
|
8.3.3.2 Only charge people after they sign up for a free account and use the product
|
8.3.3.3 less noise for people who are using the product
|
8.3.3.4 no one will fill out a five page personal form to begin using a product - or our website
|
8.3.4 Don't forget common sense
|
8.3.4.1 don't hide the sign-up button
|
8.3.4.2 state costs prominently
|
8.3.4.3 explain refund policy up front
|
8.3.4.4 offer mailing list sign-up
|
8.3.4.5 blog the product
|
8.3.5 Build Buzz
|
8.3.5.1 tell mavens and insiders
|
8.3.5.2 buddy up to like-minded journalists
|
8.3.5.3 offer a mailing list sign up
|
8.3.6 Teaser, preview, movie
|
8.3.6.1 screen shots with information
|
8.3.7 Monitor the buzz (and the bust) (ego-surfing to build better products)
|
8.3.7.1 technorati
|
8.3.7.2 blogdex
|
8.3.7.3 feester
|
8.3.7.4 delicious
|
8.3.7.5 daypop
|
8.3.8 cultivate Feature Food - reaching people who like specific features
|
8.3.8.1 Audiences will Chew it up and spit it out - example: basecamp working in with iCal calendars
|
8.3.9 Promote through education
|
8.3.9.1 if you can't outspend, out-teach (yellow fade technique) by showing how you did it.
|
8.3.10 Promote products from the inside the application - getting people to upgrade to the next level inside the app
|
8.3.10.1 call out upgrade opportunities - get more of what you like
|
8.3.10.2 benefits of upgrade not features things you can do, not what the new features are
|
8.3.10.3 show and seek
|
8.3.11 Never have done an e-mail blast -- email is completely user-driven notifications
|
8.4 37 Signals Measures of success
|
8.4.1 Does the product make us happy?
|
8.4.2 Do people use it
|
8.4.3 is it less expensive to run than we can bring in
|
8.4.4 are we making enough that we don't have to borrow money
|
8.5 Pricing - How much would we pay for something?
|
8.5.1 Consumer oriented - lower pricing to have people feel comfortable with upgrading
|
9 Launch is Just the beginning
|
9.1 Public betas are bullshit
|
9.1.1 shifts responsibility from you to your customers
|
9.1.2 suggests that the product will be
|
9.1.3 shows a lack of confidence
|
9.1.4 says you aren't ready for prime time
|
9.1.5 says you aren't dependable
|
9.1.6 only made sense when software was on Cd rom
|
9.1.7 Just launch it -- if the cost of change is low, improving the product is easy
|
9.2 Release and iterate in the wild
|
9.2.1 don't have special betas for some people
|
9.2.2 nothing is ever perfect
|
9.2.3 perpetual improvement
|
9.3 major update 30 days post launch
|
9.3.1 demonstrate momentum
|
9.3.2 show you're listening and adjusting
|
9.3.3 fight fatigue
|
9.3.4 hold back some features
|
9.3.5 spread out good news
|
10 Providing Customer "Moral" Support
|
10.1 Their pain should be your pain - be as close to the users as possible
|
10.1.1 forward customer support messages to designers or programmers
|
10.1.2 chefs become waiters
|
10.1.2.1 Builders support the project
|
10.1.3 shared experiences (and annoyances)
|
10.2 Preempt support with good design
|
10.2.1 inline help and FAQs - tell me more links
|
10.3 Us. Vs. Them
|
10.3.1 Users have low opinions of you
|
10.3.2 But they have high expectations of what you can do
|
10.3.3 Disarming Techniques
|
10.3.3.1 quick response
|
10.3.3.2 I don't know
|
10.3.3.3 be carefully direct and honest
|
10.3.3.4 anticipate follow-ups
|
10.3.3.5 cut your losses with wackos
|
10.3.4 Have Canned responses at the ready
|
10.3.4.1 how do I cancel?
|
10.3.4.2 how do I export?
|
10.3.4.3 Where do I log in?
|
10.3.4.4 I forgot my password
|
10.3.4.5 feature requests
|
10.3.5 trash feature requests after reading
|
10.3.5.1 if the feature is important, people will remind you every day
|
10.3.6 Calculate the cost of interrupting people's flow - if it costs $100 to bother someone, people won't do it.
|
11 Mistakes and Uncertainties within 37 Signals (
|
11.1 Appless app - writeboards.
|
11.2 Overthinking affiliates program
|
11.3 iteration fatigue
|
11.4 acclimating hires
|
11.5 single sign-on
|
11.6 rotate chores
|
11.7 backpack debt
|