Japanese User Experience

I recently took a trip to Japan with a few associates to study how our customers there search, use our products and make online purchase decisions. We conducted usability and cognitive studies in Tokyo with different sets of customers. Below are highlights of key findings that will be useful if your goal is to optimize your product for the Japanese market. This list contains ideas that I found to be the most counter-intuitive based on my admittedly western view of user experience. 

Instruction. The Japanese culture favors more instruction on web pages that helps them understand what might happen once they click on something. We had a saying in our UX department that if you have to explain the feature, you’ve designed it poorly but it’s apparent to me that this statement is less true for the Japanese market. Culturally, we observed that people not only wanted to know what was going to happen before clicking on things, they also longed for instruction and/or details about the thing they were going to purchase. This isn’t just the web, walk into any electronics, furniture store etc and you’ll seem catalogs full of detailed specification and product photos. 

Trust.  We learned from Japanese users that they wanted to feel like they could trust the organization they are purchasing from. They would spend more time on tertiary pages like the “about us,” “FAQs”, “Licensing terms” than other users in an attempt to gain a higher level of trust in the organization they are purchasing from. People want to know that the company behind a product/service is legitimate and Japanese companies invest in “corporate campaigns” to make the company name a trustworthy one. 

Text Heavy web pages  - Many western UX Professionals comment on how cramped / cluttered many Japanese websites are. It’s not visual clutter if the user finds the content valuable. Take a look at this collection of Japanese product pages. http://lp-web.com/  You’ll notice right away that they are text heavy but they often convert better anyway. Japan web aesthetic favors information density - in part because of the number of glyphs in the Japanese language, but also due in part to the instruction topic raised above. 

Very Few Fonts - You’ll need to design your webpage to look good using one of the basic Japanese fonts such as Meiryo or Hiragino Kaku because there aren’t nearly as many font options as latin character sets. Creating a new font requires 8000+ glyph and that’s a large task. An even heavier task is the work your browser will need to do to load some of the fancier Japanese fonts. Here’s some details about Japanese Web Fonts. 

Mobile + Image heavy pages - It’s common knowledge that images tend to convert higher than just plain copy in much of the landing page and email tests online, but if your image heavy page has a slow load time in Japan due to your servers being located in the US or Europe, than you are probably hurting your conversion more than helping it with the images. Mobile web usage is over 60% in Japan so more than half your traffic is loading the page on their phone. The Japanese culture has a much longer relationship with mobile web browsers with the early adoption of mobile phones and 3G.

Collectivism - (出る杭は打たれる)Japan is noted as a culture that puts the harmony of the group over the expression of the individual. We saw this in user experience research as well hearing from Japanese customers making purchasing decisions that they would have greater trust in an organization if they knew that many other people were already using that service. It seems like social proof might help conversion on pages with purchasing decisions. Here’s a famous Japanese proverb that means “The nail that sticks up will be hammered down.” 出る杭は打たれる

Typing Roman characters => Hiragana => Kanji.  Watching Japanese users type is a fascinating experience considering they are using four types of characters: Roman characters + Hiragana (phonetic) + Katakana (phonetic/foreign words) + Kanji (pictographic). The web was born from Roman numerals, so Japanese type on a Roman keyboard, but the type appears as either Hiragana or Katakana (depending on what they choose.) Then they hit the spacebar, which make suggested Kanji appear. If it’s the correct Kanji, hitting the enter key will select it. If it’s incorrect, then tapping the spacebar a second time will make a drop down menu of Kanji appear where you can select the correct Kanji. Watching Japanese users, this complexity seems insignificant as they tap away, but it’s an important aspect of usability because in some cases a sentence in a western language that takes 8-10 keystrokes, can take up to 50 keystrokes in Japanese. Here’s a video illustrating the complexity. This may appear complicated, but in some ways it’s actually more efficient because of suggested words, phrases and the fact that sometimes Kanji can very precisely mean something that takes 10 english words to express. 

Flick Input on mobile.  I can’t find stats on this, but anecdotally at events we attended, we saw people under the age of 40 using flick (which is available in both Android and IOS) instead of an ascii keyboard to communicate much faster than the typical writing described above. In this input system, the userstarts from a seed hiragana (“A” and other consonant/vowel combinations ending in “A”), and flicks it in the other four directions to get vowel/consonant combinations. Here’s a description of how it works and here’s an example of how fast it can be. Many young people in Japan have converted to this input system, which allows faster, more direct input than using romaji to spell out hiragana.

A written language. A Japanese friend of mine told me that there exists a disproportionate volume of fax machines still in use throughout Japanese business. One reason is  because it’s still easier to write a document freehand and fax it over to someone than to type an email. Food for thought when you are asking for information from a Japanese user in form fields. There are other reasons as well documented here in the NY Times and here in the BBC. 

Search Experience - Users we observed typed shorter queries (fewer terms) than Users in western languages. The Japanese language is more specific and accurate than many western languages. For example, in English there is only one word for brother but in Japanese, there are two words “older brother” (兄) and “younger brother” (弟). This level of specificity requires a search engine’s accuracy of keyword translations to be more nuanced than other languages.

10 A/B Testing Lessons I Learned The Hard Way

This article originally appeared January 13, 2013 on The Hired Guns .

After a decade in Product Development at Shutterstock and Beatport, I’ve performed a ton of A/B tests. Some were great. Others weren’t so great. But each one taught me something valuable, and each one made me better at what I do. I’m surrounded by some really smart people, but we’ve still had to stumble our way through some of these hard lessons because what seems intuitive is not always your winner. With that in mind, here’s something I wish I had started with years ago: a pragmatic list of lessons learned the hard way.

No two products are the same, so the tests we’ve run won’t work for your business. So instead of including details around specific tests, this list focuses on core principles that will help others succeed in testing. Have fun!

1. It’s a hypothesis. Don’t fall in love. Most tests don’t turn out the way you plan them. There’s a roughly 70% chance that you are wrong. Try lots of ideas quickly and cheaply. Consider excluding difficult browsers like IE and excluding customer segments that introduce lots of edge cases. Do what it takes to get a test out fast.

2. Test small changes. Don’t spend months building a test just to throw it away when it doesn’t work. If you have to spend a long time creating it, then you’re doing it wrong. Find the smallest amount of development you can conduct to create a test based on your hypothesis. One variable at a time is best.

3. Tell the story of the customer with qualitative research. It’s difficult to narrate the customer psychology surrounding your test without having some qualitative research to back up your metrics. It’s really not as hard as it sounds. Tools like Qualvu.com are great for helping you measure your qualitative research and turn it into something actionable. The key to great testing is understanding when to use quantitative and when to use qualitative. Qualitative analysis is great for generating test ideas or for telling the story of a winning test.

4. UX details matter. It’s the details that lead to big wins. Many of our winning tests were based on a small detail that none of us were able to articulate prior to the test. Pre-selecting a box, using a button instead of a link, slightly altering the visual priority on a page or making a minor copy change — these are the things that drive winning tests and revenue gains.

5. You can’t test strategy. Know what to use A/B testing for and what not to. If you have a new product release that is meant to fit a new customer segment, don’t test your way into it. That path only leads to frustration. Release the product and follow up with A/B tests later to optimize the product. If you are concerned with how customers might react to a new feature, consider a “smoke test.” This is where you release it to a small customer segment for a short period to see if there are strong negative outcomes that would prevent you from releasing the product and/or potentially give you an opportunity to improve it before a full release.

6. Don’t neglect site performance. Performance testing should be considered part of your design and optimization. Even a small page load increase can foul what would otherwise be a winning design. Page weight and load should be tested alongside other tests. I’ve seen winning tests lose on performance issues alone.

7. Leave your visual design principles at the door. Don’t confuse beautiful design with what converts. Ultimately, the two concepts don’t have much to do with one another. Designers with conversion experience know that it’s function over form. Over the years, we’ve designed some beautiful pages that have lost a lot of money. This point gets exacerbated when you’re testing internationally because markets and cultures respond differently to the same presentation.

8. Price Framing is crucial. Pricing tests are won and lost on framing. How customers see the price point on the page in relation to the other price points often matters more than the actual price point. If you are selling something on the page for $9.99, it can be highly effective to have a red herring for $29.99 that frames the lower priced item you wish the customer to purchase.

9. View many different health metrics. The metric you tried to move probably won’t tell the whole story. Plenty of very smart people have been puzzled by A/B test results. You’ll need to look at lots of different metrics to figure out what change really happened, and more often than not you’ll be incorrect. When a test fails, don’t give up. Instead, learn what happened (figure out, for example, which metric DID move) and use that to inform future iterations.

10. Instead of creating one control cell, create two. This simple testing principle helps read significance (when the controls flatten out) and also helps identify errors in data collection/methodology. If your identical controls are giving you very different reads, something is wrong with the test.

The Downside of Timelines

Linear project timelines can be useless or damaging in product/tech organizations. Most product development cycles look more like a decision tree and less like a Gantt Chart as noted in the graphic above. This sounds controversial, especially within software vendors and companies who are accustomed to RFP’s but hear me out. Before getting to my point, a few caveats; #1 I’m talking primarily about web development, not manufacturing. #2 Lightweight relative T-shirt sizing (small, medium, large for days, months quarters) is a helpful distinction for debating opportunity cost. What I’m referring to is the traditional date driven timeline based on specifications (or release planning in Agile methods.) Those timelines are costly and potentially damaging. Here’s a few reasons why.

1. Product development, especially finding product / market fit - is not linear. I’ve never built a great product linearly, in order to find the right product fit, the team may need to change their mind a few times and try something totally different than what they imagined at first. We call this learning and it doesn’t always fit neatly into a schedule.

2. Estimates are largely wrong. Technology estimates are incorrect more than half the time. Estimating substantial complexity is near impossible. In over a decade of development, I’ve observed dev teams ability to estimate two weeks worth of work to roughly 80% accuracy. When you stretch that to 4 weeks estimate, the accuracy drops to 50%  and so on as the work gets more abstract. Add to this the fact that people are generally optimistic and you end up with a gap between expectations and reality.

3. Poor allocation of resources (i.e; you are wasting precious time estimating. You could be building something). Estimates are not worth the time they take to generate. A litmus test I often use is having a conversation with my associates about the time / cost of estimating. It goes like this, “Ok guys, how important is the estimate? Is it so important that we are cool with the development team spend the next month estimating instead of building ” 9 times out of 10 the answer is no, we’d rather have something real completed (even if it’s wrong) than spend time estimating - and that is because the estimate itself is rarely a deciding piece of information. 

4. The timeline is abstract. Unless you are building the same thing over and over again, your team will not be able to get a realistic assessment of what it will take until they get started.  This is because there are too many unknowns that only become known when you try to build. In David Allen’s book Getting Things Done: The Art of Stress-Free Productivity he promotes adhering to specific next steps rather than abstract larger goals. "The latter looming in the back of our mind like a nagging mother, never fully silenced until specific actionable steps are taken."

5. There are better tools for accountability. I often hear that dates are a good way to motivate teams and there’s some truth to that. I’ve found short sprints to be a decent gauge of accountability. At the end of a short period, either the team finished all their work, or they learned that something else was more important and shifted during the iteration and that’s a helpful to know. However, creating accountability around abstract concepts like a date far off in the future is potentially damaging because your teams don’t’ understand what they are signing up for. 

If you build the same thing repeatedly, there are big efficiency gains to be had by optimizing timelines. The same can be said for hardware development where adherence to process quality and timelines is important. On the web, we work in a world of uncertainty, where we rarely build the same thing twice. In this world, timelines aren’t a very helpful tool. So, for those of you in the same arena, let’s have more productive conversations today. 

* Product people - Let’s talk about priority instead of haggling feature trade-offs related to a date.

* Leadership - let’s debate user value / metrics instead of timelines. (T-shirt sizing is good enough)

* Engineering - let’s build a prototype instead of “scoping and estimating” abstract concepts. 

Happy Building.

-Wyatt Jenkins

Inspiration vs. Motivation

One of the things I love about coming to work at Shutterstock is helping people on our teams succeed. Over the years leading teams of technologists, designers, researchers, sales and customer service I’ve learned a helpful distinction - the difference between inspiration and motivation. Great leaders know the difference between inspiration and motivation.  As a leader, you’ll need to use both, but if you want your teams to be more productive and satisfied, I’d suggest more inspiration and less motivation.  What’s the difference? In searching for definitions of both there are blogs such as this one where the author posits commonly held motivational techniques such as affirmation, reward and punishment as mistakes. I agree, but would take it a step further, there exists an underlying failure in the concept of motivation.  SImply put, motivation is largely based in fear.

Motivation is rooted in fear

American Psychologist Abraham Maslow when defining his hierarchy of needs came up with another word "Metamotivational" to help him distinguish between basic motivations and an activity that drives “self actualized” people because the traditional definition lacked something for his purpose. Motivation can be defined as the reaction to a deficiency or need driving us toward a goal.  To put this in perspective, when we hear people say, “I’m self motivated.” what they often mean is “I’m afraid of failure” or “I’m afraid of looking bad.”  As a leader you may hear about the need to motivate your team. If you are resorting to motivation too often, you could be missing the point.  Some of the least successful people I’ve worked with were highly motivated, but how their motives were actualized was un-constructive. Why not create the space for inspiration instead?

For instance, an engineer highly motivated to hit a deadline because he needs a paycheck could write shoddy code to get there full well knowing that it will need to be re-written and cost the organization later. I’d argue this engineer is not inspired to create a great, scalable product but rather motivated to complete a task. Alternatively, inspiration can create something beyond the goals and expectations we have for each other on a team.

Inspiration exceeds reason

Inspiration is less talked about in psychological circles and referenced more often in terms of creativity leading to musical, literary or artistic endeavors. Without debating the definition of inspiration, I’d posit that one of the key attributes of inspiration is the creation of new action without the need of a goal. Inspiration comes from within, It’s important to note that you cannot create inspiration in another person, but you can help them find their own inspiration.  Rewarding your top team members financially is both necessary and a great motivator, but if in addition they are inspired, you now have a force multiplier. 

As a leader, you succeed based on your team’s performance. Your team is innately motivated by their fears, having enough to eat, looking good, fear of failure and a host of other things that would make us more effective if we stopped doing.  Ask yourself if you’ve created enough space in the workplace for your team’s inspiration. You cannot inspire someone else, you can be inspired and that can be contagious, but those are different concepts.  You must offer the space for other’s inspiration. 

There are many payoffs to inspired teams of people. One benefit is that your message is amplified because inspiration is contagious, other’s can sense it.  This contagion creates new courses of action outside of what you had originally imagined in goal-setting. Adversely, because they are largely based in fear, motivations tend to be ideas people keep to themselves.

So What

There’s a time and place for both inspiration and motivation, but realize that motivations alone won’t grow the business. Here’s a practical list of questions you ask your team to create inspiration. Being open to the answers to these questions - even if they aren’t what you imagined - creates the space for their inspiration.

1. How comfortable are you doing this work?

2. What does your perfect day at work look like?

3. What are your best skills?  The areas you enjoy most.

How to Build a Team That Builds Great Products

This article originally appeared August 2, 2012 on The Hired Guns .

Hiring is a topic I’m passionate about because I like to work with bright, enthusiastic people who challenge me every day. I’ve spent the last decade building teams (most recently a product organization that includes designers, researchers, and product owners), and I’ve learned a number of lessons in that time. Let’s focus specifically on product ownership — a role that many gravitate toward, but few do well. I’ve seen many different types of people find success as product owners — from former developers, English majors, designers, and project managers, all the way to former CEOs and small business owners. (I prefer the term “product owner” to the more well-known “product manager” because managers manage and owners own, and building great products demands ownership.) I want people who are technical enough to dig deep with the development team and at the same time enjoy interacting with customers to discover value. Finding the right person with the right combination of customer focus, consensus building, and technical savvy isn’t easy, so I’ve put together a few things to look for during the interviewing process.

Things to avoid

Here are a few traits that are guaranteed non-starters.

1. Poor listening.  You know those interviewees who start rattling off their answer before they’ve really had a chance to listen to the question? In the same category are people who answer the question they want to answer, even if it’s not exactly what we asked. In our team-based environments, these personalities haven’t been successful. Besides, one of the key characteristics of a great product owner is listening to customers and not letting their own egos drown out the needs of our users.

2. Inability to connect the dots.  I look for people who have been active in all aspects of product development from the idea, concept, and research stages, all the way through to execution and optimization with wins under their belt.  When a candidate points to a different department and says, “The research team would talk to customers and tell me what to do,” or “I would hand off the specs to the development team,” I perceive this as a gap in their skill set.

3. Unclear communication.  One of the most effective attributes of a great product owner is the ability to distill a complex idea into a few concise statements. Simply put, the ability to deconstruct complex subjects into clear, simple statements of value is a requirement of great product owners. Whether talking to developers or evangelizing to stakeholders, the gift of simple communication is one that is necessary to perform the job at a high level.

4. Pirates not politicians. I recently asked a candidate what makes a great boss and he replied, “You scratch my back and I scratch yours,” which didn’t sit well with me.  How can you lead a group of innovators having learned all too well how to “play the game?” Your team will recognize when you speak from the heart versus when you’re just scratching someone’s back and lose trust in you over time. Immediately, I knew this candidate was from a big, slow organization and would have to unlearn some bad habits in order to be successful in our product organization.

Things we love

Here are a few qualities that will get you back for a second interview, even if you don’t necessarily have the domain knowledge.

1. Being the customer.  I appreciate product owners who can empathize with customers and dig deep in research by conducting face-to-face interviews with real users.  This pseud-method acting is a positive skill for product owners who want to excel, especially those without deep domain knowledge.  If you’re building a product for photographers but have very little domain knowledge, we better hear how you can’t wait to buy a camera and start learning the craft. Fast Company has a great article about this topic here.

2. Going deep technically.  It’s perfectly OK if you aren’t a great developer. What I look for iscuriosity.  If you’re a learner, you’ll figure out what you need to study in order to have a mutually beneficial conversation with your team and technical stakeholders. Different types of products will require different levels of technical depth, but generally, being willing and able to learn is the important part. More on this topic here.

3. Ownership/Attitude.  It’s good to see evidence of perseverance. You’ll see this in people who have started their own company, candidates with an aura of “unstoppability”, or those who have shown the stick-to-it-ive-ness to solve tough problems. This is a cornerstone of great product people. There will be a million reasons why something can’t be done, but those product owners who are unlikely to give up, those who push through tough problems and those who actually enjoy the process of doing so are the ones who stand out.

I want to work with the best and be challenged every day. Recruiting top talent is the most important part of building a great company. Take it personally, don’t let recruiters do all the work on your behalf, and make sure that the employees doing the interviewing are the ones you’d like more of. Anytime I feel like recruiting is difficult, typically because I’m struggling to find the right talent, I check out a quote or post from Paul English to remind myself how important it is to wait for the right person to fill these roles.

Do you have what it takes? If so, sign up. We have stuff to build.

Betting on Mobile at the Workplace

Mobile is reinventing how people work by moving previously complex tasks to smaller portable devices. This work process reinvention is one of my bets on where to place your development resources in the next few years. Lets review the facts illustrating the changes we’ve seen recently.  

* Smartphones outsold PC’s in 2011 and PC sales stagnate while mindshare moves to other devices. Users are getting used to attaining “most of what they need” from a small portable device and reserving complex work for the desktop.  

* TV advertising is trending down. The tube can no longer hold our attention when competing with the other 2 or 3 devices we have in our life.  

* Traditional software vendors are pivoting to cloud-based subscription strategies to cater to the changing needs of their customers across devices.  Microsoft and Adobe are two big examples. 

Changes coming in complex tasks.

Smartphone market penetration is past the 50% mark in the United states with a ways to go in emerging markets, tablets are on an aggressive growth path as well.  However, in terms of using tablets and smartphones for our work, users still haven’t adopted much of what’s possible. There’s also a stigma slowing usage in the workplace; “If my boss sees me on a phone or tablet, they assume I’m not working.” Users have adopted the basics - social, location based services and games, but still reserve elaborate chores for the desktop. Walk around any office and observe people working with traditional desktop software packages.  You’re getting a glimpse at an arena ripe for change. Here are two ways I see this changing.

1. Compartmentalizing complexity - save time by pushing some tasks within a complex workflow to the train-ride to work, or while you are watching the game.

2. Collaboration - simplify collaboration across groups of people at any time of the day.

What are people doing differently?

Last year we conducted qualitative research at Shutterstock while building the iPad app.   Users’ mental mode on tablets displayed an aptitude for leisurely discovery and browsing. Also, they felt less constrained by time than other devices.  Recently, Google released research that highlights some of the big changes in the device world. Here are three concepts I found particularly relevant:

1. Mental Mode on different devices. 

* PC - productivity, focus, work, business.

* Smartphone - on the go, short bursts of time, quick information

* Tablet - entertainment, browsing, less constrained by time. 

2. People are using devices simultaneously and in succession.  No single device is holding our attention for long periods of time, people are shifting between devices based on which is better for the task. People work while they watch TV or they start a search on a mobile device and then make the purchase decision later on the PC. 

3. Found Time. This is my favorite concept from the Google research and relevant to using mobile devices at the office.  User’s experience a sense of “found time” when they can use a device simultaneously with a question they have.  I would extend this to complex workflows where a user may outsource a particular step in a workflow to a mobile device to make them more efficient at the desktop. Music producers can perform editing tasks on a tablet or smartphone. As a graphic designer, can you select color palettes and fonts on a device prior to sitting at your desk to work in photoshop? Outlining a presentation on a tablet is more intuitive than the creating it on the desktop, the tablet forces the user to summarize. 

How to take advantage of these opportunities.

From a reductionist point of view, a complex task is simply a large set of simple tasks that must take place in some order.  If you add “found time” to this, user’s will divide complex tasks on a PC and tasks that can be moved to other portable devices for efficiency.  Each one of these outsourced tasks will represent an opportunity for creating user value and a disruption to software on desktops. Some areas I see potential change are finance software, design, music production, photo editing and presentation making just because they are closest to me, but I’m sure the list is much longer than that.  In opportunity areas ask yourself “could we do part of this workflow on a smartphone? on a tablet?” I’m betting you can. 

Authentic User Conversations

Let’s have more thoughtful, authentic conversations with our users, and let’s start with surveys.  Your survey IS a bad user experience.  It has no character, I don’t enjoy taking it and I don’t understand how it will benefit me to finish it. Paying me won’t help either.  With payment, I may actually try to finish it, but don’t mistake that for caring about your product. In fact, paying me to finish your survey further cheapens the experience because by doing so, you’ve told me that you are fully aware of how bad it sucks and are willing to put me through it anyway. Taking a survey is about as fun as standing in line to get a driver’s license. Survey response rates are down and attitudes towards data collection are changing.  Here’s a few reasons why.

Every experience counts. We need to put care and empathy into every interaction. In the experience economy people value experience with a product over any of the single features that we can add. Every touchpoint a user has is either adding to their positive mentality about your product or taking from it. A Q&A session or survey is an opportunity cost in the eyes of a customer - what could they be doing with that time otherwise?  Now consider the ramifications of a 25 question 1/2 hour survey with typical demographic and rating style questions and you’ll realize that the survey you just sent out is  damaging user’s perception of your product. 

Personal Data is the new oil.  This has been the title of some blogs and a great panel I attended at SXSW.  Social Networks and targeted advertising have illuminated people to the value of their personal data. Asking someone a personal question is more and more like reaching for their wallet.  

“In practical terms, a person’s data would be equivalent to their ‘money,’” wrote the WEF in its “Personal Data” report. “It would reside in an account where it would be controlled, managed, exchanged and accounted for just like personal banking services operate today.”

If user’s data is equivalent to their money, we as stakeholders should measure progress in data collection by lowering the number of survey’s we send in order to feel confident in our customer’s perception of the product. With the survey’s we do send, let’s take steps to be courteous, authentic and clearly articulate the benefits of having the interaction.  Let’s walk through a few scenarios. 

Have an authentic conversation.  I want to know why I’m answering this question, what’s in it for me?  Am I supposed to trust you the first time we’ve met? On a practical level, I try to imagine each question like a real life conversation in a bar. If a stranger came up to me in a bar and asked, “how does this site compare to your idea of an ideal website, rate one to ten.” I’d probably just tell them to go away. Here’s why;

* First, It’s a deep question, I’m not sure what my ideal site looks like and would need a few minutes to figure it out - a few minutes that you, as a stranger, aren’t going to get from me.

* Secondly, if I tell you this, what are you going to do for me?  Explain that first.  

* Thirdly, I don’t know if you and I are on the same page regarding the difference between a 6 and an 8 on your question scale.  Can we be more specific? how about I think it’s ALOT like my ideal site, or it’s just SORT OF like my ideal site.  See the point?

* Lastly, how about an introduction first, who are you, why are you asking me this, what will change about my life if I answer it?  Let’s be specific. “Hey, I’m Jim, I work here at the bar. I’d like to know how this place stacks up to other bars you hang out in.  If you tell me what’s wrong, I’ll try to improve it.”  

Store Better Data.  People expect a lot these days, ask dumb questions at your own risk.  I can’t tell you how often I get the “How often do you purchase from this website?” question. You can’t tell?! Questions of your users should leverage all the data that you have at your disposal to personalize the experience for people who are using your product. Make user’s feel like you have a clue. 

Keep it short and keep it within the product. For more details about the specifics of writing great surveys, here’s one of my favorite posts. Generally speaking, don’t create a survey that takes a user more than 5 minutes to finish.  Additionally, try introducing 1-2 question survey’s onsite within the product instead of sending email surveys.  Within email, the user is disconnected from the product; they may not have visited your product for weeks.  Asking the question on-site provides better results and doesn’t force your user to try to remember the thing they liked or didn’t like 3 weeks ago. 

In summary, Let’s try to take our user conversations up a notch.  Entertain someone, make them laugh, be real and you’ll be rewarded with more honest feedback and loyalty.

6 ways to foster creative product teams

I’ve been lucky enough to be involved with teams that built great products at Shutterstock the last few years (previously at  Beatport and the team at Native Instruments as well.)  The word “great” can be a little ambiguous, let’s refer to products that have disruptive attributes - stuff that’s ground breaking, profitable and/or deemed by it’s constituency as creative.  While no one has the perfect formula for continuously delivering ground breaking work, there are a few traits of these teams which I thought worth sharing. There’s a reason this is such an important topic, especially If you are building for web or mobile: you are competing with highly iterative and risk seeking teams somewhere else in the world that have a lot less to lose. In other words, building something great is now par for the course - if you develop a half ass product, someone will build something better a few months later and put you out of business. 

Keep the team small - including stakeholders

"Nothing is what happens when everyone has to agree" (Great quote from Seth Godin). Your team should be just big enough to be able to execute all the necessary tasks. This goes for stakeholders outside of the team as well - if you have 4 or 5 stakeholders who need to be notified every few days, you’ll eventually drain every ounce of creativity from the project. In product development, some of the teams I’ve seen work best are in the 6-9 team member range including dedicated development, design, QA, and product at the least.  Assign roles in a way that key decisions don’t necessarily require everyone’s vote, but they have a forum to voice their opinion.  The small team must be bought in to what you are doing even if they may disagree on some details. 

Practice organic communication

Scheduling a meeting is not a solution to a problem.  Sometimes a 5 minute chat by someone’s desk or a quick whiteboard session will get you past a difficult spot more effectively than scheduling something for next Tuesday. More “off the cuff” communication or “organic” meetings are great ways to foster teams who need to break new ground. People talk about “brainstorming” meetings to discuss ideas, but I haven’t seen that work too often. Scheduled meetings are better suited for information sharing and creating alignment; adversely, they can be a bad forum for creative problem solving. There are a few caveats to organic communication.

     * Don’t annoy your team-mates, some people really need long periods of time to think - especially in technology.  If you want to have an impromptu meeting with someone, be empathetic to their specific workflow. 

     * Hey meeting guy, If you are the type of person who finds yourself in back to back meetings all day (I put myself in this category far too often), you may not be best suited to be the creative driver of a team.  Back off and let the people closest to the problem solve it.

     * Places to think, talk and problem solve, Surround yourself with whiteboard paint, hang up dashboards with goals that your team wants to reach, create visual omnipresent references to the problems you are trying to solve. 

     * Team’s sitting together, organic communication tends to break down when your team isn’t sitting together. I can’t stress how much co-location can help create outstanding work.

Dont’ try to fit it into a schedule - there’s no start and end. 

If you want to build something great, you’ll need to let go of the notion that it has a start and end point.  The thing you release the first time will probably suck anyway and you’ll need to fix it, so get over the idea of a “project” within a fixed set of time and resources. Besides, “fixing it,” or iterating based on customer feedback is when the real learning starts anyway. I like to think of it as the beginning of a relationship between the build team and the customers who will use the product. During this relationship with the customer, needs will change and you’ll have to change with the by letting go of things you previously held close. This concept is difficult for companies to grasp because financial systems, RFP’s and manufacturing processes are all designed to put your development into a box or a timeline, but that’s the antithesis to creating something wonderful.

Get a team of “Do-ers”

Some of the best work I’ve ever seen came from a team of can-do personalities with the right mix of fearlessness, passion and curiosity.  If we are talking about ground breaking work, I’ll take a group of scrappy production level folks who are passionate about solving customer problems over “strategy/idea” people every time.  We all read books about “insert genius CEO here” and that makes for great story-telling, but I just haven’t seen that work in real life - your CEO is busy.  My favorite teams are a group of cast offs with a chip on their shoulder, the ability to dig deep into a problem, a healthy dose of humility and a love for their craft. This obviously isn’t’ a black and white issue, because lots of teams have different personalities, but there’s something to the notion that when people feel like they are overachieving, the passion inside of them leads to good things. Which carries me to my next point:

Create flow by intelligently stretching teams.

Truly enjoying the work you do lies somewhere between what you are capable of and a challenge you’ve never quite met. This goes for teams as well.  If the challenge is something completely out of their reach, frustration will set in because the goal seems unobtainable. However, if it’s something they’ve done over and over, they will be bored and/or not put in their best effort. If you want great work out of your team, help them set the goal just out of reach, but not in a completely different zip code. Mihaly Csikszentmihalyi has written books on flow that are great reading and I’ve seen this stretch rule act as a practical application of his research. 

Create a direct line to customer empathy

One sure way to build crappy product is to remove the team’s connection to the customer. In a perfect world, the people writing the code are the same people talking to customers. I’ve seen lots of organizations add too many links in the communication chain - nobody is going to feel customer empathy by looking at bullet points in a powerpoint presentation.  If you want to build something wonderful, get your developers and designers in direct contact with end users and remove the phone game.  The working team has to feel the customer pain deeply to build something awesome. 

Read more about the author.

Childlike Curiosity

I enjoy coming to work at Shutterstock. The people I work with are bright, hard working and inspire me to believe that we can build things that make people happy - that’s awesome! The qualities of great co-workers are vast, but a few of my favorites are humility, a willingness to learn and a childlike curiosity (or Shoshin in Zen Buddhism).  When we are childlike, there are no dumb questions and no preconceptions that hinder creative problem solving.  

This childlike curiosity’s positive effects can be seen amongst high preforming teams. When a team displays Shoshin everyone is working as though it’s day one and no single team member is working off assumptions that aren’t shared amongst the group. This opens up the communication lanes allowing for better collaboration. It also allows for the team members to think holistically.  For example, as a developer, it’s OK to have an opinion on the color palette of the design.  As an ethnographic researcher, it’s ok to question the quantitative analysis.  If you want to create something great, cross pollinated thinking is REQUIRED because it puts the team in a consistent state of learning. Additionally, titles, directives and politics fade into the background and you are left with a group of people working together to solve a problem.

Some of the most successful leaders I have worked with have an uncanny ability to stay in this mindset for long periods of time.  Entrepreneurs are forced to think this way when they start a company because when their first approach doesn’t work, they either have to revisit the problem with an open mind or they will go out of business. Good product leaders are like this as well, especially after a few failed product releases under their belt to create the humility required to build something great. I’ve also seen the opposite amongst leaders. Many leaders who have climbed the ladder have achieved their status through a string of successes.  However, all too often those successes become a crutch of preconception over time. It takes courage to simply say “I don’t know, but I’ll take steps to learn.” 

This type of thinking has permeated technology. Here are a few examples:

* The lean startup methodology embraces the Minimum Viable Product (MVP) because it’s wise for a startup to spend more time building and testing than years trying to perfect a product that may not work. There’s humility and curiosity in this thinking. 

* The Agile Manifesto favors “responding to change over following a plan” because the creation of a long term project plan changes a team’s thinking. The team spends time trying to predict the future instead of trying to iterate on the problem at hand. The existence of an overly detailed plan suggests that all the learning has been completed, when in truth, the learning has just begun when you start building.

* SVPG started by experienced technologist Marty Cagan promotes “Product Discovery” or rapid prototyping in short iterations to discover something that is useful to customers.  Marty even says more explicitly that you’ll probably need to try 3-5 times before you get it right, so focus on getting those attempts done efficiently.

* Facebook has “Fail Fast” posters all over the office enforcing the notion that failure is just a part of the creative process and encouraging employees to do it often. Facebook knows that failure is akin to learning. 

My goal isn’t to add another blog about development processes, but to focus on some of the characteristics of teams working in these positive environments because I hope more organizations work this way - not just technology companies. I’d argue that working in organizations where learning is encouraged, where people ask questions about things that aren’t their specialty, where it’s ok to fail, or even encouraged is required to create greatness. 

Let’s take a deeper look at the psychology of accepting failure.  A friend of mine told me about a great book by Jonah Lehrer, “How we decide.” In the second chapter, the book reviews research by Carol Dweck, a psychologist from Stanford who spent decades proving that a great education stems from the ability to learn from mistakes or to “fail often.” Here’s an excerpt from the book: 

        "(Failure should be embraced in schools) unfortunately, children are taught the exact opposite. Instead of praising kids for trying hard, teachers typically praise them for their innate intelligence (being smart). Dweck has shown that this type of encouragement actually backfires, since it leads students to see mistakes as signs of stupidity and not as the building blocks of knowledge.  The regrettable outcome is that kids never learn how to learn.”

In Dweck’s most famous test with hundreds of schoolchildren in NYC, Kids were given a relatively easy test in 2 groups.  The first group, upon finishing the test successfully were praised for their intelligence. “You must be smart at this.” The other group was praised for their effort: “You must have worked really hard.” The students were then allowed to choose between two subsequent tests, a difficult test and a relatively easy one. 90% of the kids who were praised for their efforts chose the difficult test while almost all of the kids praised for their “intelligence” chose the easy one.  

"When we praise children for their intelligence," Dweck wrote, "we tell them that this is the name of the game: look smart, don’t risk making mistakes." Dweck’s next few tests proved that the praise of innate intelligence actually inhibits learning. She used a very difficult test for the next round - well above the students grade level.  The group who was praised for their innate intelligence struggled and was fast to give up, "Maybe I’m not that smart after all." Meanwhile t he group praised for hard work "got very involved" in the difficult test and outscored the other group while proclaiming unprovoked "this is my favorite test." 

Now let’s take a look back at our organizations, teams and leaders.  How many people are afraid of failure and inhibiting their own ability to learn? Let’s embrace a culture that encourages people to fail more often, ask any question, try ideas quickly and start the learning. There is no shortcut to creating a great new product, your team is going to have to try a few times until they get it right. Let’s work to build systems that allow teams the flexibility to experiment, practice and learn rapidly, instead of spending months and months debating which idea to try. 

I’m lucky to work with people I admire in this respect. Every one of us has moments where we fall into the trap of “knowing everything,” but more often than not, the people I get to problem solve with on a daily basis help me get past that blockage. They have the patience to allow me to learn. Always a student. 

Read more about the author