Bite-Sized UX Research
By Steve Baty
Published: May 7, 2008
It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:
- Sometimes we’re brought onto a project late.
- Perhaps we’re new to an organization that doesn’t really get UX.
- Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.
- Perhaps your client or organization is following an Agile development methodology.
“As UX professionals, we can always add value, at any stage in a project.”At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect. But the simple fact is that, as UX professionals, we can always add value, at any stage in a project—even if a project team can’t act on our advice straight away.
Focus on Winning Small Victories Often
Regardless of the cause for your company’s resource crunch, focus on getting small wins as often as possible throughout your involvement in a project. This is a fairly common piece of advice that crops up time and time again, but it’s very much worth repeating. And it applies just as readily to both situations where time is short and those when there’s just not enough of you to go around.
This advice is equally valid for UX professionals who find themselves in new positions as the sole user experience person. It’s common for new hires to ask: “How do I sell the benefits of UX?” The answer is generally something along the lines of: “Focus on small wins.” In other words, don’t waste your energy putting together a series of case studies on how other people have created value at other organizations. Instead, do something positive and tangible—however small—and it’ll carry a lot more weight.
Go for Impact
Concentrate on getting bang for your buck. Depending on your circumstances, you may not get many opportunities to demonstrate the value of UX, and when time is short, there can be a tendency to just do something—anything. It’s an urge you should try to resist. If you want to have a greater impact, ask your project team—the project manager, the development team, and the business stakeholders—a few pointed questions before you get started:
- What are the critical features of the Web site or application?
- What features would be hardest for the developers to change once they’ve developed them?
- What are the areas of greatest ambiguity in terms of user requirements, audience groups, or competitive offerings?
And then ask a few more questions:
- How can I best document my user research findings, so the project team can use them?
- Do we have time for iterations? And if so, how many?
With this information, you can start planning some activities that focus on the most important elements of the project—the critical features for success; the features that are hardest to change; or the gray areas of the project—and deliver some real value.
It’s all very well to say “do something small,” but what, exactly, can you do?
Early Days
You can demonstrate the value of UX during the early stages of a project—such as scoping, initial designs, general requirements, and so on—when there’s the potential for more leeway in the feature set of an online service and more ambiguity around users’ needs. Some activities that can demonstrate value early in the process—and may even alleviate some of your resource constraints further down the track—include the following:
- user interviews or contextual enquiries—Get out of the office and meet some of your prospective users. This is a really low-cost way of rapidly building up an understanding of your users’ needs and their context of use. You’ll also learn in what ways users differ from each other and may uncover some surprises. The best part is that—aside from the cost of your time—it’s largely a free activity.
- competitor reviews—Help map out the current state of the domain, allowing your team to set better targets. Look at the existing offerings of your competitors to identify the things they do really well and the things they’re failing to do well. Competitor reviews also provide you with a baseline set of features that represent the barrier to entry and can also help to identify opportunities the obvious gaps represent.
- internal stakeholder interviews—If you don’t have direct access to your audience, go and talk to the business stakeholders and ask them about the decision-making process by which they selected and prioritized features. This can help you uncover assumptions that you can test as a project progresses. It can also provide insights into the mental models in operation for the project.
- mud map personas—There’s a good chance you won’t have the time or resources to conduct the in-depth user research you’d need to turn out well-defined audience personas. However, low-fidelity personas that capture all of the information you do know about your audience segments can be valuable as time progresses. While you can flesh out these mud maps as you learn more about your audience, they also serve to demonstrate how little your team currently knows first-hand about your target users.
About Mud Maps
A mud map is a drawing scratched into the dirt. You can use mud maps when there are no other materials at hand and draw them with a stick or boot. Mud maps are low fidelity, but contain the main characteristics of the terrain.
What About Card Sorts?
Conducting a card-sorting exercise early in a project is desirable when the concept space is not well understood. Early on, you’d typically perform an open card sort, which may require more time and resources—for recruitment, implementation, and analysis—than you have.
Although it is possible to design, recruit, conduct, and analyze a card sort in a matter of days, the question remains whether you might spend that time on another task, offering higher impact to the project. However, there are times when nailing the information architecture is the most critical element for the success of a project, and a card sort would be the best use of your time.
What to Deliver?
“The critical features of your project will drive your choice of what elements to detail.”Although your time may be short, don’t abdicate responsibility for an information architecture to others. Do wireframes, even if you show only some elements in detail. The critical features of your project will drive your choice of what elements to detail. You might spend your time designing the elements that are most important to the success of a project, leave less important elements to the development team, and iterate the design of those less important elements later on, when you have more time. Alternatively, design and test complex elements that it would be costly to redesign and reimplement at later stages in a project.
As Time Goes By
As a project moves out of its early stages and into the implementation cycle, you can start shifting your attention from requirements to refinement. At this stage of a project, useful activities include
- user walkthroughs
- closed card sorts
- usability testing
- definition of metrics
User Walkthroughs
You can do small-scale user walkthroughs of wireframes, a paper prototype, or a stack of screen shots for very little cost. The aim is to generate feedback from real users—or, at least, realistic users—on the design of features at a relatively early stage in a project—that is, before too much development work has taken place.
This activity doesn’t necessarily have to be a big deal. Take a stack of paper printouts to a local cafe and ask people if they’ll walk through a task or two with you, in exchange for a coffee or snack. Don’t take up too much of any one person’s time. It’s better to get several different people to try out a feature or two rather than possibly annoying people by demanding too much of them. They’re trying to relax after all!
Iterate this process if you can.
Closed Card Sorts
“Focus on task failures and look for common mistakes participants make.”A closed card sort is a little easier to conduct than an open card sort— and, in my opinion, a lot easier to analyze. Using decks of cards representing a site’s structure as you’ve designed it, ask people to find their way to particular low-level pages. You can plan your card sort based on the major user tasks, critical features, or areas of known ambiguity.
You can easily conduct a closed cart sort just about anywhere, and it should take only a few minutes per task. For each task you test, note the path each user takes—that is, the card a user selects at each step—and whether a user successfully located the low-level page.
You can carry out a test like this in a single day, including its setup. Since time is short, focus on task failures and look for common mistakes participants make. Report only such issues, but make the full test results available to your project team. You don’t want to be the bearer of only bad news. Instead say: “A lot of stuff worked well, but here are some things we need to look at changing.”
Usability Testing
Using whatever version of a Web site or application you have available—whether wireframe printouts or a low-fidelity prototype—conduct a more formal usability test, during which you ask each participant to complete all tasks. Although this can be time consuming, a usability test with six participants takes just a few days and can provide valuable insights for your project team.
You can take this opportunity to test your whole design solution. Alternatively, you can concentrate on high-impact features, according to your time, people, and budget constraints.
As a finished Web site or application becomes more tangible, continue doing iterative, small-scale usability testing. There will come a time when you can’t incorporate the findings from your testing into the upcoming release, but your recommendations can form the basis for a subsequent version.
Define Metrics
If you’ve joined a project very late, there may be very little you can do to influence the finished product. However, you can still add value to the project by defining a set of analytics that can help the project team make design decisions during the product lifecycle. So, get the team to record page-completion times for a multi-step transaction process, make sure you get good search logs and reports, and give yourself an opportunity to learn something about how customers are interacting with your site.
Don’t be disheartened if your project team can’t incorporate your changes straight away. Start laying the groundwork for the next iteration of the product or service and stay ahead of the curve if you can.
Summary
“Undertake small, tactical, iterative user research activities throughout the course of the project.”If you don’t have the resources of a large UX team, with the budgets and timelines to undertake the ideal user-centered design (UCD) or activity-centered design process, you can still make a valuable contribution to a project. Undertake small, tactical, iterative user research activities throughout the course of the project. Focus your efforts on the areas of greatest impact, and produce documentation that your project team can understand and use efficiently.
If you demonstrate value through a series of small, high-impact UX activities, the extra budget, people, and timeline flexibility you need will eventually come your way. Then, you can come closer to implementing your ideal UX process.
I’d like to thank Ruth Ellison, of Stamford Interactive, Daniel Szuc, of Apogee, and Russ Unger, of User Glue, for motivating me to write this column and for their input into the ideas it presents.
Topic: Columns | User Research
2011年12月31日 星期六
Bite-Sized UX Research
2011年12月30日 星期五
10 Heuristics for User Interface Design
Ten Usability Heuristics
by Jakob NielsenThese are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.
- Visibility of system status
- The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
- Match between system and the real world
- The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
- User control and freedom
- Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
- Consistency and standards
- Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
- Error prevention
- Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
- Recognition rather than recall
- Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
- Flexibility and efficiency of use
- Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
- Aesthetic and minimalist design
- Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
- Help users recognize, diagnose, and recover from errors
- Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
- Help and documentation
- Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
2011年12月26日 星期一
2011年12月25日 星期日
Check out this website I found at 2011年12月21日 星期三
2011年12月19日 星期一
2011年12月12日 星期一
Why you Should Bury your Sign Up Button
Why you Should Bury your Sign Up Button
A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.
The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.
I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.
So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.
What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.
Why then, were people not clicking the sexy button?
It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.
But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.
Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.
Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?
So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.
No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…
No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.
The hard fact is that they just don’t care.
Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.
So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.
I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…
Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.
Why you Should Bury your Sign Up Button « Bokardo
Why you Should Bury your Sign Up Button
A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.
The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.
I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.
So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.
What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.
Why then, were people not clicking the sexy button?
It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.
But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.
Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.
Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?
So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.
No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…
No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.
The hard fact is that they just don’t care.
Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.
So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.
I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…
Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.
2011年12月7日 星期三
2011年11月23日 星期三
Technology Footprint: Starting Up in New York
The New York Times mapped out the offices of the Big Apple’s hottest startups, color-coding the companies by industry.
2011年11月22日 星期二
2011年11月7日 星期一
2011年11月6日 星期日
Don’t Call Yourself A Programmer, And Other Career Advice
If there was one course I could add to every engineering education, it wouldn’t involve compilers or gates or time complexity. It would be Realities Of Your Industry 101, because we don’t teach them and this results in lots of unnecessary pain and suffering. This post aspires to be README.txt for your career as a young engineer. The goal is to make you happy, by filling in the gaps in your education regarding how the “real world” actually works. It took me about ten years and a lot of suffering to figure out some of this, starting from “fairly bright engineer with low self-confidence and zero practical knowledge of business.” I wouldn’t trust this as the definitive guide, but hopefully it will provide value over what your college Career Center isn’t telling you.
90% of programming jobs are in creating Line of Business software: Economics 101: the price for anything (including you) is a function of the supply of it and demand for it. Let’s talk about the demand side first. Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity. For example, consider an internal travel expense reporting form. Across a company with 2,000 employees, that might save 5,000 man-hours a year (at an average fully-loaded cost of $50 an hour) versus handling expenses on paper, for a savings of $250,000 a year. It does not matter to the company that the reporting form is the world’s simplest CRUD app, it only matters that it either saves the company costs or generates additional revenue.
There are companies which create software which actually gets used by customers, which describes almost everything that you probably think of when you think of software. It is unlikely that you will work at one unless you work towards making this happen. Even if you actually work at one, many of the programmers there do not work on customer-facing software, either.
Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.) The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.
Peter Drucker — you haven’t heard of him, but he is a prophet among people who sign checks — came up with the terms Profit Center and Cost Center. Profit Centers are the part of an organization that bring in the bacon: partners at law firms, sales at enterprise software companies, “masters of the universe” on Wall Street, etc etc. Cost Centers are, well, everybody else. You really want to be attached to Profit Centers because it will bring you higher wages, more respect, and greater opportunities for everything of value to you. It isn’t hard: a bright high schooler, given a paragraph-long description of a business, can usually identify where the Profit Center is. If you want to work there, work for that. If you can’t, either a) work elsewhere or b) engineer your transfer after joining the company.
Engineers in particular are usually very highly paid Cost Centers, which sets MBA’s optimization antennae to twitching. This is what brings us wonderful ideas like outsourcing, which is “Let’s replace really expensive Cost Centers who do some magic which we kinda need but don’t really care about with less expensive Cost Centers in a lower wage country”. (Quick sidenote: You can absolutely ignore outsourcing as a career threat if you read the rest of this guide.) Nobody ever outsources Profit Centers. Attempting to do so would be the setup for MBA humor. It’s like suggesting replacing your source control system with a bunch of copies maintained on floppy disks.
Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)
Instead, describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs. If you have not had the opportunity to do this yet, describe things which suggest you have the ability to increase revenue or reduce costs, or ideas to do so.
There are many varieties of well-paid professionals who sling code but do not describe themselves as slinging code for a living. Quants on Wall Street are the first and best-known example: they use computers and math as a lever to make high-consequence decisions better and faster than an unaided human could, and the punchline to those decisions is “our firm make billions of dollars.” Successful quants make more in bonuses in a good year than many equivalently talented engineers will earn in a decade or lifetime.
Similarly, even though you might think Google sounds like a programmer-friendly company, there are programmers and then there’s the people who are closely tied to 1% improvements in AdWords click-through rates. (Hint: provably worth billions of dollars.) I recently stumbled across a web-page from the guy whose professional bio is “wrote the backend billing code that 97% of Google’s revenue passes through.” He’s now an angel investor (a polite synonym for “rich”).
You are not defined by your chosen software stack: I recently asked via Twitter what young engineers wanted to know about careers. Many asked how to know what programming language or stack to study. It doesn’t matter. There you go.
Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. I did back-end Big Freaking Java Web Application development as recently as March 2010. Trust me, nobody cares about that. If a Python shop was looking for somebody technical to make them a pile of money, the fact that I’ve never written a line of Python would not get held against me.
Talented engineers are rare — vastly rarer than opportunities to use them — and it is a seller’s market for talent right now in almost every facet of the field. Everybody at Matasano uses Ruby. If you don’t, but are a good engineer, they’ll hire you anyway. (A good engineer has a track record of — repeat after me — increasing revenue or decreasing costs.) Much of Fog Creek uses the Microsoft Stack. I can’t even spell ASP.NET and they’d still hire me.
There are companies with broken HR policies where lack of a buzzword means you won’t be selected. You don’t want to work for them, but if you really do, you can add the relevant buzzword to your resume for the costs of a few nights and weekends, or by controlling technology choices at your current job in such a manner that in advances your career interests. Want to get trained on Ruby at a .NET shop? Implement a one-off project in Ruby. Bam, you are now a professional Ruby programmer — you coded Ruby and you took money for it. (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)
Co-workers and bosses are not usually your friends: You will spend a lot of time with co-workers. You may eventually become close friends with some of them, but in general, you will move on in three years and aside from maintaining cordial relations you will not go out of your way to invite them over to dinner. They will treat you in exactly the same way. You should be a good person to everyone you meet — it is the moral thing to do, and as a sidenote will really help your networking — but do not be under the delusion that everyone is your friend.
For example, at a job interview, even if you are talking to an affable 28 year old who feels like a slightly older version of you he is in a transaction. You are not his friend, you are an input for an industrial process which he is trying to buy for the company at the lowest price. That banter about World of Warcraft is just establishing a professional rapport, but he will (perfectly ethically) attempt to do things that none of your actual friends would ever do, like try to talk you down several thousand dollars in salary or guilt-trip you into spending more time with the company when you could be spending time with your actual friends. You will have other coworkers who — affably and ethically — will suggest things which go against your interests, from “I should get credit for that project you just did” (probably not phrased in so many words) to “We should do this thing which advances my professional growth goals rather than yours.” Don’t be surprised when this happens.
You radically overestimate the average skill of the competition because of the crowd you hang around with: Many people already successfully employed as senior engineers cannot actually implement FizzBuzz. Just read it and weep. Key takeaway: you probably are good enough to work at that company you think you’re not good enough for. They hire better mortals, but they still hire mortals.
“Read ad. Send in resume. Go to job interview. Receive offer.” is the exception, not the typical case, for getting employment: Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here). Information about the position travels at approximately the speed of beer, sometimes lubricated by email. The decisionmaker at a company knows he needs someone. He tells his friends and business contacts. One of them knows someone — family, a roommate from college, someone they met at a conference, an ex-colleague, whatever. Introductions are made, a meeting happens, and they achieve agreement in principle on the job offer. Then the resume/HR department/formal offer dance comes about.
This is disproportionately true of jobs you actually want to get. ”First employee at a successful startup” has a certain cachet for a lot of geeks, and virtually none of those got placed by sending in a cover letter to an HR department, in part because two-man startups don’t have enough scar tissue to form HR departments yet. (P.S. You probably don’t want to be first employee for a startup. Be the last co-founder instead.) Want to get a job at Googler? They have a formal process for giving you a leg up because a Googler likes you. (They also have multiple informal ways for a Googler who likes you an awful lot to short-circuit that process. One example: buy the company you work for. When you have a couple of billion lying around you have many interesting options for solving problems.)
There are many reasons why most hiring happens privately. One is that publicly visible job offers get spammed by hundreds of resumes (particularly in this economy) from people who are stunningly inappropriate for the position. The other is that other companies are so bad at hiring that, if you don’t have close personal knowledge about the candidate, you might accidentally hire a non-FizzBuzzer.
Networking: it isn’t just for TCP packets: Networking just means a) meeting people who at some point can do things for you (or vice versa) and b) making a favorable impression on them.
There are many places to meet people. Events in your industry, such as conferences or academic symposia which get seen by non-academics, are one. User groups are another. Keep in mind that user groups draw a very different crowd than industry conferences and optimize accordingly.
Strive to help people. It is the right thing to do, and people are keenly aware of who have in the past given them or theirs favors. If you ever can’t help someone but know someone who can, pass them to the appropriate person with a recommendation. If you do this right, two people will be happy with you and favorably disposed to helping you out in the future.
You can meet people over the Internet (oh God, can you), but something in our monkey brains makes in-the-flesh meeting a bigger thing. I’ve Internet-met a great many people who I’ve then gone on to meet in real life. The physical handshake is a major step up in the relationship, even when Internet-meeting lead to very consequential things like “Made them a lot of money through good advice.” Definitely blog and participate on your industry-appropriate watering holes like HN, but make it out to the meetups for it.
Academia is not like the real world: Your GPA largely doesn’t matter (modulo one high profile exception: a multinational advertising firm). To the extent that it does matter, it only determines whether your resume gets selected for job interviews. If you’re reading the rest of this, you know that your resume isn’t the primary way to get job interviews, so don’t spend huge amount of efforts optimizing something that you either have sufficiently optimized already (since you’ll get the same amount of interviews at 3.96 as you will at 3.8) or that you don’t need at all (since you’ll get job interviews because you’re competent at asking the right people to have coffee with you).
Your major and minor don’t matter. Most decisionmakers in industry couldn’t tell the difference between a major in Computer Science and a major in Mathematics if they tried. I was once reduced to tears because a minor academic snafu threatened my ability to get a Bachelor of Science with a major in Computer Science, which my advisor told me was more prestigious than a Bachelor of Science in Computer Science. Academia cares about distinctions like that. The real world does not.
Your professors might understand how the academic job market works (short story: it is ridiculously inefficient in engineering and fubared beyond mortal comprehension in English) but they often have quixotic understandings of how the real world works. For example, they may push you to get extra degrees because a) it sounds like a good idea to them and b) they enjoy having research-producing peons who work for ramen. Remember, market wages for people capable of producing research are $80~100k+++ in your field. That buys an awful lot of ramen.
The prof in charge of my research project offered me a spot in his lab, a tuition waiver, and a whole $12,000 dollars as a stipend if I would commit 4~6 years to him. That’s a great deal if, and only if, you have recently immigrated from a low-wage country and need someone to intervene with the government to get you a visa.
If you really like the atmosphere at universities, that is cool. Put a backpack on and you can walk into any building at any university in the United States any time you want. Backpacks are a lot cheaper than working in academia. You can lead the life of the mind in industry, too — and enjoy less politics and better pay. You can even get published in journals, if that floats your boat. (After you’ve escaped the mind-warping miasma of academia, you might rightfully question whether Published In A Journal is really personally or societally significant as opposed to close approximations like Wrote A Blog Post And Showed It To Smart People.)
How much money do engineers make?
Wrong question. The right question is “What kind of offers do engineers routinely work for?”, because salary is one of many levers that people can use to motivate you. The answer to this is, less than helpfully, “Offers are all over the map.”
In general, big companies pay more (money, benefits, etc) than startups. Engineers with high perceived value make more than those with low perceived value. Senior engineers make more than junior engineers. People working in high-cost areas make more than people in low-cost areas. People who are skilled in negotiation make more than those who are not.
We have strong cultural training to not ask about salary, ever. This is not universal. In many cultures, professional contexts are a perfectly appropriate time to discuss money. (If you were a middle class Japanese man, you could reasonably be expected to reveal your exact salary to a 2nd date, anyone from your soccer club, or the guy who makes your sushi. If you owned a company, you’d probably be cagey about your net worth but you’d talk about employee salaries the way programmers talk about compilers — quite frequently, without being embarrassed.) If I were a Marxist academic or a conspiracy theorist, I might think that this bit of middle class American culture was specifically engineered to be in the interests of employers and against the interests of employees. Prior to a discussion of salary at any particular target employer, you should speak to someone who works there in a similar situation and ask about the salary range for the position. It is <%= Date.today.year %>; you can find these people online. (LinkedIn, Facebook, Twitter, and your (non-graph-database) social networks are all good to lean on.)
Anyhow. Engineers are routinely offered a suite of benefits. It is worth worrying, in the United States, about health insurance (traditionally, you get it and your employer foots most or all of the costs) and your retirement program, which is some variant of “we will match contributions to your 401k up to X% of salary.” The value of that is easy to calculate: X% of salary. (It is free money, so always max out your IRA up to the employer match. Put it in index funds and forget about it for 40 years.)
There are other benefits like “free soda”, “catered lunches”, “free programming books”, etc. These are social signals more than anything else. When I say that I’m going to buy you soda, that says a specific thing about how I run my workplace, who I expect to work for me, and how I expect to treat them. (It says “I like to move the behavior of unsophisticated young engineers by making this job seem fun by buying 20 cent cans of soda, saving myself tens of thousands in compensation while simultaneously encouraging them to ruin their health.” And I like soda.) Read social signals and react appropriately — someone who signals that, e.g., employee education is worth paying money for might very well be a great company to work for — but don’t give up huge amounts of compensation in return for perks that you could trivially buy.
How do I become better at negotiation? This could be a post in itself. Short version:
a) Remember you’re selling the solution to a business need (raise revenue or decrease costs) rather than programming skill or your beautiful face.
b) Negotiate aggressively with appropriate confidence, like the ethical professional you are. It is what your counterparty is probably doing. You’re aiming for a mutual beneficial offer, not for saying Yes every time they say something.
c) ”What is your previous salary?” is employer-speak for “Please give me reasons to pay you less money.” Answer appropriately.
d) Always have a counteroffer. Be comfortable counteroffering around axes you care about other than money. If they can’t go higher on salary then talk about vacation instead.
e) The only time to ever discuss salary is after you have reached agreement in principle that they will hire you if you can strike a mutually beneficial deal. This is late in the process after they have invested a lot of time and money in you, specifically, not at the interview. Remember that there are large costs associated with them saying “No, we can’t make that work” and, appropriately, they will probably not scuttle the deal over comparatively small issues which matter quite a bit to you, like e.g. taking their offer and countering for that plus a few thousand bucks then sticking to it.
f) Read a book. Many have been written about negotiation. I like Getting To Yes. It is a little disconcerting that negotiation skills are worth thousands of dollars per year for your entire career but engineers think that directed effort to study them is crazy when that could be applied to trivialities about a technology that briefly caught their fancy.
How to value an equity grant:
Roll d100. (Not the right kind of geek? Sorry. rand(100) then.)
0~70: Your equity grant is worth nothing.
71~94: Your equity grant is worth a lump sum of money which makes you about as much money as you gave up working for the startup, instead of working for a megacorp at a higher salary with better benefits.
95~99: Your equity grant is a lifechanging amount of money. You won’t feel rich — you’re not the richest person you know, because many of the people you spent the last several years with are now richer than you by definition — but your family will never again give you grief for not having gone into $FAVORED_FIELD like a proper $YOUR_INGROUP.
100: You worked at the next Google, and are rich beyond the dreams of avarice. Congratulations.
Perceptive readers will note that 100 does not actually show up on a d100 or rand(100).
Why are you so negative about equity grants?
Because you radically overestimate the likelihood that your startup will succeed and radically overestimate the portion of the pie that will be allocated to you if the startup succeeds. Read about dilution and liquidation preferences on Hacker News or Venture Hacks, then remember that there are people who know more about negotiating deals than you know about programming and imagine what you could do to a program if there were several hundred million on the line.
Are startups great for your career as a fresh graduate?
The high-percentage outcome is you work really hard for the next couple of years, fail ingloriously, and then be jobless and looking to get into another startup. If you really wanted to get into a startup two years out of school, you could also just go work at a megacorp for the next two years, earn a bit of money, then take your warchest, domain knowledge, and contacts and found one.
Working at a startup, you tend to meet people doing startups. Most of them will not be able to hire you in two years. Working at a large corporation, you tend to meet other people in large corporations in your area. Many of them either will be able to hire you or will have the ear of someone able to hire you in two years.
So would you recommend working at a startup? Working in a startup is a career path but, more than that, it is a lifestyle choice. This is similar to working in investment banking or academia. Those are three very different lifestyles. Many people will attempt to sell you those lifestyles as being in your interests, for their own reasons. If you genuinely would enjoy that lifestyle, go nuts. If you only enjoy certain bits of it, remember that many things are available a la carte if you really want them. For example, if you want to work on cutting-edge technology but also want to see your kids at 5:30 PM, you can work on cutting-edge technology at many, many, many megacorps.
(Yeah, really. If it creates value for them, heck yes, they’ll invest in it. They’ll also invest in a lot of CRUD apps, but then again, so do startups — they just market making CRUD apps better than most megacorps do. The first hour of the Social Network is about making a CRUD app seem like sexy, the second is a Lifetime drama about a divorce improbably involving two heterosexual men.)
Your most important professional skill is communication: Remember engineers are not hired to create programs and how they are hired to create business value? The dominant quality which gets you jobs is the ability to give people the perception that you will create value. This is not necessarily coextensive with ability to create value.
Some of the best programmers I know are pathologically incapable of carrying on a conversation. People disproportionately a) wouldn’t want to work with them or b) will underestimate their value-creation ability because they gain insight into that ability through conversation and the person just doesn’t implement that protocol. Conversely, people routinely assume that I am among the best programmers they know entirely because a) there exists observable evidence that I can program and b) I write and speak really, really well.
(Once upon a time I would have described myself as “Slightly below average” in programming skill. I have since learned that I had a radically skewed impression of the skill distribution, that programming skill is not what people actually optimize for, and that modesty is against my interests. These days if you ask me how good of a programmer I am I will start telling you stories about how I have programmed systems which helped millions of kids learn to read or which provably made companies millions. The question of where I am on the bell curve matters to no one, so why bother worrying about it?)
Communication is a skill. Practice it: you will get better. One key sub-skill is being able to quickly, concisely, and confidently explain how you create value to someone who is not an expert in your field and who does not have a priori reasons to love you. If when you attempt to do this technical buzzwords keep coming up (“Reduced 99th percentile query times by 200 ms by optimizing indexes on…”), take them out and try again. You should be able to explain what you do to a bright 8 year old, the CFO of your company, or a programmer in a different specialty, at whatever the appropriate level of abstraction is.
You will often be called to do Enterprise Sales and other stuff you got into engineering to avoid: Enterprise Sales is going into a corporation and trying to convince them to spend six or seven figures on buying a system which will either improve their revenue or reduce costs. Every job interview you will ever have is Enterprise Sales. Politics, relationships, and communication skills matter a heck of a lot, technical reality not quite so much.
When you have meetings with coworkers and are attempting to convince them to implement your suggestions, you will also be doing Enterprise Sales. If getting stuff done is your job description, then convincing people to get stuff done is a core job skill for you. Spend appropriate effort on getting good at it. This means being able to communicate effectively in memos, emails, conversations, meetings, and PowerPoint (when appropriate). It means understanding how to make a business case for a technological initiative. It means knowing that sometimes you will make technological sacrifices in pursuit of business objectives and that this is the right call.
Modesty is not a career-enhancing character trait: Many engineers have self-confidence issues (hello, self). Many also come from upbringings where modesty with regards to one’s accomplishments is culturally celebrated. American businesses largely do not value modesty about one’s accomplishments. The right tone to aim for in interviews, interactions with other people, and life is closer to “restrained, confident professionalism.”
If you are part of a team effort and the team effort succeeds, the right note to hit is not “I owe it all to my team” unless your position is such that everyone will understand you are lying to be modest. Try for “It was a privilege to assist my team by leading their efforts with regards to $YOUR_SPECIALTY.” Say it in a mirror a thousand times until you can say it with a straight face. You might feel like you’re overstating your accomplishments. Screw that. Someone who claims to Lead Efforts To Optimize Production while having the title Sandwich Artist is overstating their accomplishments. You are an engineer. You work magic which makes people’s lives better. If you were in charge of the database specifically on an important project involving people then heck yes you lead the database effort which was crucial for the success of the project. This is how the game is played. If you feel poorly about it, you’re like a batter who feels poorly about stealing bases in baseball: you’re not morally superior, you’re just playing poorly
All business decisions are ultimately made by one or a handful of multi-cellular organisms closely related to chimpanzees, not by rules or by algorithms: People are people. Social grooming is a really important skill. People will often back suggestions by friends because they are friends, even when other suggestions might actually be better. People will often be favoritably disposed to people they have broken bread with. (There is a business book called Never Eat Alone. It might be worth reading, but that title is whatever the antonym of deceptive advertising is.) People routinely favor people who they think are like them over people they think are not like them. (This can be good, neutral, or invidious. Accepting that it happens is the first step to profitably exploiting it.)
Actual grooming is at least moderately important, too, because people are hilariously easy to hack by expedients such as dressing appropriately for the situation, maintaining a professional appearance, speaking in a confident tone of voice, etc. Your business suit will probably cost about as much as a computer monitor. You only need it once in a blue moon, but when you need it you’ll be really, really, really glad that you have it. Take my word for it, if I wear everyday casual when I visit e.g. City Hall I get treated like a hapless awkward twenty-something, if I wear the suit I get treated like the CEO of a multinational company. I’m actually the awkward twenty-something CEO of a multinational company, but I get to pick which side to emphasize when I want favorable treatment from a bureaucrat.
(People familiar with my business might object to me describing it as a multinational company because it is not what most people think of when “multinational company” gets used in conversation. Sorry — it is a simple conversational hack. If you think people are pissed off at being manipulated when they find that out, well, some people passionately hate business suits, too. That doesn’t mean business suits are valueless. Be appropriate to the circumstances. Technically true answers are the best kind of answers when the alternative is Immigration deporting you, by the way.)
At the end of the day, your life happiness will not be dominated by your career. Either talk to older people or trust the social scientists who have: family, faith, hobbies, etc etc generally swamp career achievements and money in terms of things which actually produce happiness. Optimize appropriately. Your career is important, and right now it might seem like the most important thing in your life, but odds are that is not what you’ll believe forever. Work to live, don’t live to work.
A good perspective and entertaining.
2011年10月25日 星期二
2011年10月24日 星期一
2011年10月22日 星期六
Continuous Partial Attention | Linda Stone
What is continuous partial attention?
Continuous partial attention describes how many of us use our attention today. It is different from multi-tasking. The two are differentiated by the impulse that motivates them. When we multi-task, we are motivated by a desire to be more productive and more efficient. We’re often doing things that are automatic, that require very little cognitive processing. We give the same priority to much of what we do when we multi-task — we file and copy papers, talk on the phone, eat lunch — we get as many things done at one time as we possibly can in order to make more time for ourselves and in order to be more efficient and more productive.
To pay continuous partial attention is to pay partial attention — CONTINUOUSLY. It is motivated by a desire to be a LIVE node on the network. Another way of saying this is that we want to connect and be connected. We want to effectively scan for opportunity and optimize for the best opportunities, activities, and contacts, in any given moment. To be busy, to be connected, is to be alive, to be recognized, and to matter.
We pay continuous partial attention in an effort NOT TO MISS ANYTHING. It is an always-on, anywhere, anytime, any place behavior that involves an artificial sense of constant crisis. We are always in high alert when we pay continuous partial attention. This artificial sense of constant crisis is more typical of continuous partial attention than it is of multi-tasking.
Is continuous partial attention a good thing or a bad thing?
Like so many things, in small doses, continuous partial attention can be a very functional behavior. However, in large doses, it contributes to a stressful lifestyle, to operating in crisis management mode, and to a compromised ability to reflect, to make decisions, and to think creatively. In a 24/7, always-on world, continuous partial attention used as our dominant attention mode contributes to a feeling of overwhelm, over-stimulation and to a sense of being unfulfilled. We are so accessible, we’re inaccessible. The latest, greatest powerful technologies have contributed to our feeling increasingly powerless.
Is this theory U.S. centric?
In my research to date, most of the examples and time frames are U.S. centric. However, in looking at other cultures, there appears to be a similar flow from one dominant attention paradigm into the next. We may not all find ourselves in the same attention era at the same time. We are likely to find ourselves experiencing a flow: attraction to an ideal, taking the expression of the ideal to an extreme and experiencing unintended and less than pleasant consequences, giving birth to and launching a new ideal while integrating the best of what came before.
How does this play out with different generations?
The younger generations are on the leading edge of thought for the coming dominant attention paradigm. This is one of the many reasons why the most successful companies are likely to effectively recruit, employ, incent, and manage representatives from every generation and keep an active listening channel toward the ideas and ideals, and the habits and passions of the younger generation.
When I’ve interviewed 18-22 year olds, I notice that they are often using communications technology in a mode that I call “semi-sync.” It’s not quite synchronous and it’s not really asynchronous communication either. Text messaging is often used in a semi-sync way. When Jyri Engestrom, Jaiku co-founder, demonstrates Jaiku, he describes semi-sync usage patterns. Meanwhile, Matt Webb, in collaboration with Nokia, is experimenting with interfaces that ease the stress of continuous partial attention. Jyri is actively looking at ways to manage activity streams as well as interoperability issues.
Many in the generation now entering the workforce view phone calls as intrusive and prefer text messaging. In interviews, orbits of communication are described: My Space to keep up with a wide set of friends and acquaintances, text messaging for both one to one and one to many communications and, for one’s closest friends, phone calls.
What do we do about it?
We have focused on managing our time. Our opportunity is to focus on how we manage our attention. We are evolving beyond an always-on lifestyle. As we make choices to turn the technology OFF, to give full attention to others in interactions, to block out interruption-free time, and to use the full range of communication tools more appropriately, we will re-orient our trek toward a path of more engaged attention, more fulfulling relationships, and opportunities for the type of reflection that fuels innovation.
BREATHE. Notice what happens to your breath as you pull down and check your email or vmail. Most of us hold our breath. Some of us tighten our upper body. If we’re aware of what we’re doing and we are able to manage our breath — that is, keep breathing — the stress response is minimized.
How do we react to friends and loved ones who just can’t put the phone or Blackberry away — there are a range of approaches. When you sit down to a meal, you can let them know that you’re putting your phone/Blackberry away so you can focus your attention on them. You can let them know you’re expecting one call you need to take for 2 minutes, and after that, you’ll be putting your device away. You can choose activities that require full attention or activities that you would be able to enjoy whether they were on their Blackberry or not.
Why care?
There is a wonderful evolution taking place. Understanding how it’s unfolding offers insights into what drives us and what inspires us.
2011年10月19日 星期三
The Architecture of Participation - O'Reilly Media
The Architecture of Participation
by Tim O'Reilly
June 2004I've come to use the term "the architecture of participation" to describe the nature of systems that are designed for user contribution. Larry Lessig's book, Code and Other Laws of Cyberspace, which he characterizes as an extended meditation on Mitch Kapor's maxim, "architecture is politics", made the case that we need to pay attention to the architecture of systems if we want to understand their effects.
I immediately thought of Kernighan and Pike's description of the Unix software tools philosophy referred to above. I also recalled an unpublished portion of the interview we did with Linus Torvalds to create his essay for the 1998 book, Open Sources. Linus too expressed a sense that architecture may be more important than source code. "I couldn't do what I did with Linux for Windows, even if I had the source code. The architecture just wouldn't support it." Too much of the windows source code consists of interdependent, tightly coupled layers for a single developer to drop in a replacement module.
And of course, the Internet and the World Wide Web have this participatory architecture in spades. As outlined above in the section on software commoditization, any system designed around communications protocols is intrinsically designed for participation. Anyone can create a participating, first-class component.
In addition, the IETF, the Internet standards process, has a great many similarities with an open source software project. The only substantial difference is that the IETF's output is a standards document rather than a code module. Especially in the early years, anyone could participate, simply by joining a mailing list and having something to say, or by showing up to one of the three annual face-to-face meetings. Standards were decided by participating individuals, irrespective of their company affiliations. The very name for proposed Internet standards, RFCs (Request for Comments), reflects the participatory design of the Net. Though commercial participation was welcomed and encouraged, companies, like individuals, were expected to compete on the basis of their ideas and implementations, not their money or disproportional representation. The IETF approach is where open source and open standards meet.
And while there are successful open source projects like Sendmail, which are largely the creation of a single individual, and have a monolithic architecture, those that have built large development communities have done so because they have a modular architecture that allows easy participation by independent or loosely coordinated developers. The use of Perl, for example, exploded along with CPAN, the Comprehensive Perl Archive Network, and Perl's module system, which allowed anyone to enhance the language with specialized functions, and make them available to other users.
The web, however, took the idea of participation to a new level, because it opened that participation not just to software developers but to all users of the system.
It has always baffled and disappointed me that the open source community has not claimed the web as one of its greatest success stories. If you asked most end users, they are most likely to associate the web with proprietary clients such as Microsoft's Internet Explorer than with the revolutionary open source architecture that made the web possible. That's a PR failure! Tim Berners-Lee's original web implementation was not just open source, it was public domain. NCSA's web server and Mosaic browser were not technically open source, but source was freely available. While the move of the NCSA team to Netscape sought to take key parts of the web infrastructure to the proprietary side, and the Microsoft-Netscape battles made it appear that the web was primarily a proprietary software battleground, we should know better. Apache, the phoenix that grew from the NCSA server, kept the open vision alive, keeping the standards honest, and not succumbing to proprietary embrace-and-extend strategies.
But even more significantly, HTML, the language of web pages, opened participation to ordinary users, not just software developers. The "View Source" menu item migrated from Tim Berners-Lee's original browser, to Mosaic, and then on to Netscape Navigator and even Microsoft's Internet Explorer. Though no one thinks of HTML as an open source technology, its openness was absolutely key to the explosive spread of the web. Barriers to entry for "amateurs" were low, because anyone could look "over the shoulder" of anyone else producing a web page. Dynamic content created with interpreted languages continued the trend toward transparency.
And more germane to my argument here, the fundamental architecture of hyperlinking ensures that the value of the web is created by its users.
In this context, it's worth noting an observation originally made by Dan Bricklin in his paper, The Cornucopia of the Commons. There are three ways to build a large database, wrote Dan. The first, demonstrated by Yahoo, is to pay people to do it. The second, inspired by lessons from the open source community, is to get volunteers to perform the same task. The Open Directory Project, an open source Yahoo competitor, is the result. (Wikipedia provides another example.) But Napster demonstrates a third way. Because Napster set its defaults to automatically share any music that was downloaded, every user automatically helped to build the value of the shared database.
This architectural insight may actually be more central to the success of open source than the more frequently cited appeal to volunteerism. The architecture of Linux, the Internet, and the World Wide Web are such that users pursuing their own "selfish" interests build collective value as an automatic byproduct. In other words, these technologies demonstrate some of the same network effect as eBay and Napster, simply through the way that they have been designed.
These projects can be seen to have a natural architecture of participation. But as Amazon demonstrates, by consistent effort (as well as economic incentives such as the Associates program), it is possible to overlay such an architecture on a system that would not normally seem to possess it.
Note: I had mistakenly attributed the insight about three ways to build a shared database to Clay Shirky when it had originated from Dan Bricklin. Read more in this Radar blog entry.
danah boyd | apophenia » answers to questions from Twitter on teen practices
Before I headed to Atlanta to do fieldwork, I asked folks who follow me on Twitter (@zephoria) what questions I should ask teens. Many of the questions that I received were more general questions about teens, rather than questions for teens. Still, I’m going to take a stab at very briefly answering some of the questions that I received based on what I know and what I learned. I am not answering the larger questions that would require pages and pages and my apologies if my short answers are not sufficient but I wanted to at least respond. Thank you all who contributed questions and my apologies if I didn’t answer yours.
To all who asked questions about Twitter: average teens don’t use Twitter. They may in the future, but they do not now. Those who do are early adopters and not representative of any mainstream teen practice. Because of Oprah and celebs, some teens are starting to hear about it, but they don’t understand it and they aren’t using it.
@connyb: Parents’ concerned with what kids do online, right? I’d ask teens if they know what exactly their parents do at their dayjobs.
Teens do not tend to know exactly what their parents do, nor do they particularly care. (It’s important to note that parental concern stems from a position of power, not interest in the actual activities.)
@mauraweb: when they’re searching for info, how do they know what info to trust? esp. w/internet searches
Media literacy amongst teens is extremely varied, but the short answer is that most don’t know what to trust. They know that they are not supposed to trust Wikipedia because it’s editable (and they automatically recall Wikipedia when you ask about trustworthy information.. that’s so actively hammered down their throat, it’s painful). One girl told me that she trusts websites that “look” like they are reputable. When I asked her about this, she told me that she could “just tell” when something was a good source. And besides, it came from Google. Le sigh.
@AlterSeekers: According to Facebook Era, Teens see email as a “work” tool and prefer to Facebook message. Is this true among these teens?
I was surprised to find that email is deader than ever among teens. As more of their parents and teachers are getting on Facebook (or MySpace), they see little reason to email with anyone. Thus, email is increasingly needed for having an account on various sites and for getting access to or sending attachments. But even when teens do use email for “work”, they do not use it for social purposes.
@mirroredpool: What borders to teens place of social networking sites and education? How would they react to using an SNS to do class work?
@annejonas: i’m curious if they want schools involved in social networks or if they like it as a social space outside the realm of formal edu.
This is messy. Many teens have ZERO interest in interacting with teachers on social network sites, but there are also quite a few who are interested in interacting with SOME teachers there. Still, this is primarily a social space and their interactions with teachers are primarily to get more general advice and help. In some ways, its biggest asset in the classroom is the way in which its not a classroom tool and not loaded this way. Given that teens don’t Friend all of their classmates, there are major issues in terms of using this for groupwork because of boundary issues.
@shcdean: What future do they see for FB or Twitter.
They don’t use Twitter. When asked, teens always say that they’ll use their preferred social network site (or social media service) FOREVER as a sign of their passion for it now. If they expect that they’ll “grow out of it”, it’s a sign that the service is waning among that group at this very moment. So they’re not a good predictor of their own future usage.
@lazygal: Do they really care about/use school library websites? Twitter? Pageflakes? Libguides? or only if teacher insists?
Nope, they don’t. All but Twitter are categorized as school tools and are only used when absolutely necessary and Google won’t suffice.
@anindita: My favorite question: read anything good lately?
I asked “Recent book that you enjoyed” on my questionnaire. Half said “none” and most said books they read in school (with a *). Books that were mentioned: City of Bones, Ashes & Glass, A Year of Impossible Goodbyes, The Outsiders*, Drama High Series, Mice and Men*, Catcher in the Rye*, The Poisonwood Bible*, Twilight series (twice).
@texas_sooner: I’d be interested to know if teens denied access to SNS (by parents/choice/SES reasons etc ) feel left out/pressure to join, etc.
Parental restrictions are a huge source of frustration because of a sense of isolation. (As a result, they are typically ignored.) SES is not actually a predictor of non-use at this point except in more rural regions where Internet access is generally absent for the majority of teens. In these cases, teens don’t feel left out because they aren’t being socially isolated by it.
@SavvyPriya: what is one thing that teens are passionate about?
This varies across teens, but God comes up a lot. The only thing that really competes is friends. Family is also important to some teens. School and sports are also important to some teens. And then some teens have particular hobbies or activities that they love. But God and friends really dominate the passion list.
@paullowe: where do they get their news from and what kind of news do they want to get
Teens primarily get their news from word-of-mouth, not directly from any particular source. School current events and TV time are the other dominant place I hear about. Otherwise, it’s generally osmosis. They walk through the living room when their parents are watching the news. Or they pass by a news article when they get online. But they are not directly and intentionally consuming much news at all.
@thornet: ask ‘em how they judge whether a news outlet is credible.teens r good @ spotting fakes & phonies;wonder what their news criteria r
They don’t watch a lot of news and they have no media literacy training and they’re not even thinking about credibility of news.
@andrewmiller: how does having a smartphone change their interactions w/each other on SNS? more photos/videos? faster rumors? have/have-not gap?
A gap is definitely occurring. A smart phone means more more more more more – more SMS, more web consumption, more status updates, more photos, etc. Certain smart phones are desperately desired items. That said, teens are also doing quite well with the iPod Touch + wifi as an alternative. Smart phones are helping them stay more engaged and connected.
@shawncalhoun: Were teens more engaged in politics by Obamas #socialmedia storm? If so has engagmnt continued evolved in2 something new or faded?
Most teens are pretty oblivious to his social media practices. That’s actually hitting the college/20-somethings more.
@alexleavitt: Ask them if they feel like they’ll want to develop the social Net when they get older: eg., developers developers developers.
No. Most don’t associate using social media with computer science or developing software whatsoever. And the classes on programming in their schools aren’t helping.
@pbernard: do they still care about changing the ringtone on their phone, even though they make less and less calls?
Ringtones are tricky with American youth because it very much depends on who pays for the phone/ringtones. Among teens who can change their ringtones whenever they want, there’s still motivation. The phone still rings (and beeps with new SMSes) and having a cool sound is desired. But of course many teens spend most of their day with their phones on buzz-only.
@harraton: Do they care about their privacy?
VERY much so. But what constitutes privacy for them is often quite different than what constitutes privacy for adults. Privacy is not dead.
@simonchambers: I’d ask how they see themselves helping to solve problems like climate change and extreme poverty…
They don’t. Most teens are not that engaged with larger societal issues (except as activities to get into college). This makes sense – they are not part of public life. They have no voice. They don’t hear the debates. They aren’t exposed to much beyond their narrow worlds. And, for most of them, their parents aren’t involved either.
@dougthomas: Teens; what are their thoughts about downloading songs? films? software? without paying for it.
They want access. Their parents won’t pay for it. They don’t have credit cards. They get what they are looking for by any means necessary. And those who get access to it traffic in that content among their peers who may be less technologically savvy/economically privileged.
@jamesb: how does their mobile contacts differ from social network contacts? When do they crossover?
Mobile consists of their closest friends because of the economics of the phone. Social network sites are their broader peer group. Their closest friends are a subset of their broader peer group.
@alfredtwo: Do teens view all adults in social networking the same or are parents a special case? Young relatives friend me not their parents
Depends on the teen, but many are happy to connect with adults who don’t directly hold power over them or who they “trust” – aunts, older cousins, youth pastors, “cool” teachers, etc.
@mjmantey: how aware are they of general advertising/marketing ways and means?
If it has advertising, they think that it means that it’ll be free for a long time. But they don’t really think much about it.
@mojo_girl: how many email accounts do they have that parents don’t know about- do they use same password 4 all #socialmedia ? #teens
They don’t use email so it’s more a matter of which ones they forgot about. They often forget their passwords so I would guess that they don’t use the same password consistently. Of course, they also share certain passwords with their closest “trusted” friends so that gets messy really fast. And they change it when there’s a breakup.
@matlockmatlock: OMGSEXTINGWTF?
Continuing to be present and very very messy. Sharing of naked photos seems to be more prevalent in certain teen groups than others and I’m still trying to work out what this means.
An interesting question from the comments:
maxoid: is there any data on teen usage of Capitalization and proper grammar vs. SMS-shorthand and all-lowercase? (is format now used as a way to stand out from adults as much as langauge has long been?)
You can definitely look to certain subcultural practices to witness distinctions, such as the culture around AzN pRiDe. But there are huge differences between linguistic practices that are meant to be distinct and culturally resistant (such as those that are actually hard to produce) and those that are meant to make communication easier (fast IMing) or accommodate techno-economic limitations (160 chars). It’s important to remember that a lot of our writing (and speaking) is intentionally redundant to account for issues in hearing and penmanship. With typing, a lot of this falls by the wayside and it’s hard to argue against shorthand except to cling to inertia. Language changes. New genres of media change language. Expect things to change. Expect new generations to be pulled between what they will see as “obvious” shifts and what they’ll be forced to accommodate by those who demand status quo.
