It’s live!

From the email:

Employees can now automatically match Facebook friends to open jobs then easily invite them to apply in just a few clicks. No spam and no automatic posts. All users choose what job-related information they want to share with friends.

Job seekers can privately request referrals and view job listings at their friends’ companies. They can Jobvite friends or apply to the job directly within Facebook. And, they have complete control over what, if any, information from their Facebook profile is shared with a potential employer.

Go here to install it. We have hundreds of customers like Twitter, Groupon, Living Social and LinkedIn.

 Comments | Comment

The UX Speakeasy Conference  is on March 31 at the San Diego Zoo — rumor has it, they’re going to let me out of my cage.

It’s only $179, not bad for a one day event. Don’t go just because I’ll be there:  Aaron Irizarry, Angel Anderson, Dennis Wixon and Russ Unger are going to offer their thoughts on our wonderful industry. And you get a free ticket to the San Diego Zoo to boot! Such a bargain!

You should go. I’ll bring the hooch.

Ping me and I’ll give you the promo code for 15 percent off that $179.

 Comments | Comment

Gorgeous. You have to see this:

The clean, re-imagined Windows 8 concept is a refreshing break from Microsoft's Metro user interface. It's a kickback to earlier versions of Windows, and has us wishing that Microsoft could buy out Phyek's design to offer it as an alternative. Don't get us wrong, Windows Metro aligns with Microsoft's 2010 mobile operating system, Windows Phone "Mango", and in itself is an innovative product. Microsoft developed a solution for integrating social media, and up-to-date information, alongside the typical icons for files that all operating systems to this day have used.

One thing is sure: Metro is absolutely far from a mimicry of Apple's OS X. As  ZDnet  humorously  points out, it brings back memories of 2006, when Apple's Bertrand Serlet compared the uncanny similarities between Mac OS X Tiger and Microsoft's Windows Vista. Microsoft's fervent desire to differentiate itself from Apple has been evident, and to that extent, the designers over at Microsoft have accomplished their goal with Metro.

 Comments | Comment

[slideshare id=11640731&doc=whyweshareixd12slideshare-120217150855-phpapp01]

Seems appropriate that I’m sharing this.

 Comments | Comment

Apple turns bad customers into more profitable customers. Here’s how:

At Apple, store managers call every detractor within 24 hours. Initially, they found there were some detractors they couldn't reach. Subsequent studies showed that detractors that they did reach purchased substantially   more Apple products and services than the others. Further studies showed that every hour spent calling detractors was generating more than $1,000 in revenue or additional sales of $25 million in the first year, which was a good return on the investment.  

In traditional management, where customers are secondary, the expense of following up with customers would seem like the first kind of expense to cut in a crunch. With these numbers in hand, Apple's managers realize that this is one of the last things that should be cut.

…

At Apple, customer focus is thus not a vague slogan. It's at the core of the way the stores are managed. Employees know where they stand among their peers in terms of NPS and where their stores stands relative to the rest of the stores in the region.

It makes Apple a lot of money:

Where a typical electronics store averages $1,200 per square foot in sales, mature Apple stores exceed $6,000 per square foot-the highest productivity in retailing of any kind.

…

Thus Apple practices  radical management, where making money is the result, not the goal of the organization. The bottom line of its business is to delight the customer. We are indebted to  The Ultimate Question 2.0  for showing us how they accomplish that on a daily basis.

 Comments | Comment

He says he’s amused. Technically, I think it is the widest dialog box ever.

 Comments | Comment

What should be built is a question all software development companies struggle with. If you don’t launch enough of a feature set, user adoption will suffer.

Laura Klein makes a compelling argument that launching a limited product that solves a user need and then improving on it is a better than launching a product that’s packed not only with features but bugs and usability issues.

Great post:

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn't crash relentlessly. It doesn't have enormous usability problems.

…

But a limited product probably doesn't do anything else. It doesn't have bells and whistles. It doesn't have "nice to have" features. It may only support the problems of a small subset of the market. It may only be released to beta users.

…

A shitty product, on the other hand, often tries to do too many things at once, and it doesn't do any of those things particularly well.

You really don't want a shitty product because, when people don't use it, you have no idea if they aren't using it because you have a bad idea or the wrong market, or if it's just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren't "polished." They will abandon products that are just bad.

…

So, when I'm yelling at you to Fucking Ship It Already, I don't mean that you should ship something bad. I mean that you should ship something limited – something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again.  Do this over and over again as many times as you can for as long as you can.

 Comments | Comment

Adam Colson is a product manager I’ve worked with, and he works as a product manager that manages mostly APIs. Great User Experience designers should understand how APIs work and how to consume them. I personally love them, because once I understand an API I want to think of great ways to use it.

Great technical companies now create APIs for all of their data so front end engineers can consume it. It requires foresight, but enables much more flexibility. There was a famous post about Amazon’s services on this that’s also worth reading.  

He wrote this post to describe what he does. Cheers.

Often times I’m asked what it is I do. I usually answer with a short response like “I sit behind a computer most of the day and send emails” or “I help build Web sites and apps”. You see, describing what a product manager does to someone not in technology isn’t easy. You want to tell them in intricate detail what it is you do but you don’t want to bore them or tell them something that will just go right over their heads, like “I write product specifications for RESTful APIs”.

Recently, a VP of Engineering where I work reached out to me to help understand what I did, so that they could better identify a candidate for an API/SOA product role that they were looking to fill. The questions were:

• What are the responsibilities of this product manager?
• How do you define what is done by product and what is done by an engineer?
• What type of documentation is produced by this product manager?

An API product manager’s responsibilities

An API PM is a fairly specialized product role. My experience in job searches is that there simply are not a lot of these types of roles out there. Hence, there is probably also not a lot of product candidates with explicit API experience.

It seems most organizations see APIs as a feature or bi-product of a larger feature. Organizations that take the distribution of their data and services seriously realize that making APIs a product and applying product management disciplines is key to success. So don't despair if the field is small or the perfect candidate doesn't surface.

That said, here is a quick summary of my role as the Product Manager responsible for APIs. Maybe finding candidates with this skill set and experience, plus the necessary technical understanding, will work.

Product  Manager Responsibilities

• Subject matter expert and product expert for API or other products that are managed
• Deep understanding of client needs and market trends, through client interaction and other market research
• Owning and creating the product strategy and roadmap
• Reviewing the roadmap with key stakeholders
• Determining product priorities, including new features and bug fixes
• Owning and creating the business/product requirements documentation
• Managing feature iteration throughout the product lifecycle
• Management of client API integrations and pipeline
• Ownership of API documentation (ie – developer's site)

API  Engineer Deliverables

• The product manager defines the "what", while the engineer defines the "how"
• API architecture
• Development of API features and functionality
• Documentation of how specific methods work
• Description of how to test specific methods (for QA – if applicable)

 API  PM Deliverables

This is using developing a new Web service for an existing system as an example.

• Black box use cases (or user stories in Agile development methodology)
• Description of services needed
• Description of functions (ie – method calls) needed for each service and what they should do
• Specific requirements for each method call:
  • Is it for Creating, Reading, Updating or Deleting data?
  • What are the data or input parameters?
  • What business rules or conditions should be respected or created?
  • What data inputs should be validated and how?
  • What should be returned in the response?
  • What data should be validated in the response?
  • What exceptions should be handled? If a business rule, condition, validation or other logic didn't pass, what error response should be returned?

You can read the rest of his blog here.

 Comments | Comment

Posted over at Johnny Holland.

Brandon Stephens, Axure? Really?

 Comments | Comment

Courtesy of Douglas Wray. Very funny. And true.

 Comments | Comment

Reputation and trust is essential in a world where we don’t meet the people we do business or trust our information with. The reality of this world is that many companies have much more information about us that we prefer to have (or, what does VISA know about your buying habits online or at a physical adult bookstore?).

But that’s different, because we’re making a conscious choice to share information by making that purchase. Only when companies don’t disclose their intentions (like downloading our entire address book, for example, and then explaining that since it wasn’t required in the TOS, we didn’t notify the user) is our trust broken. And rightfully so.

Companies like Southwest Airlines have built trust with their customers by offering plainspoken terms of business. It’s essential that online companies (especially startups) do the same. When we expose our lives online, it’s essential that we know the parties at the other end have the best intentions.

From Ghost in the Pixel:

Trust  is an absolutely fundamental element of a user's experience and core to the creation of a viable customer relationship, even the business model itself, embedded in the value proposition. Yes, trust is a cornerstone of the business. It ensures a healthy customer – provider connection with positive multiplier and viral effects. Trust is infectious as "good word of mouth" spreads, and transactions increase, usage grows, value is augmented. It's a virtuous cycle.

But just as infectious is  distrust. A violation of the customer's sense of identify, privacy, and sense of their own dignity. But especially their sense of pride in a brand they enjoyed and believed in and defended, trying to persuade friends to participate and join in. All of that gets eradicated in a few seconds.

The "path" (ha!) from success to disaster is a quick and easy route. And saddens everyone, including it's fan base of faithful users.

 Comments | Comment

That’s about right:

Usability is user experience

The fundamental difference is "Can easily use" vs. "Want to use". Let's take the best possible example here – the usability guru:  Jakob Nielsen's website. Usability guru that he is, his site is very functional and easy to use. But how do you think it scores on user experience? Would visitors love to browse the site for better experience? The answer is no.

Again, there are some practitioners who believe building a good user experience is all that's needed for making the site usable. That had led to the myth in question.  Superior user experiences have failed miserably in usability, as it's just one of the dimensions of usability. It is still important to have the right balance.

…

Usability is good design

Good design (leaving apart the subjective angle) is only an element or output of usability – in practical sense. Otherwise, it's more like a philosophy. Usability done with a philosophy of good design, would make it  effective, error-tolerant, engaging, etc.  This part I echo. My argument is towards the literal aspect about the myth, that a good design brings usability. In a way, this has a resemblance to Usability is User Experience. A good user interface design is not going to save a product if it is not useful or low on performance or erroneous. The usability and acceptance of such products have no connection with the presence or absence of good design.

 Comments | Comment

 Comments | Comment