Wednesday, April 18, 2012

I'll analyze the auction house ("broker") feature because -- to say it diplomatically -- there's a reason SW:TOR now has to patch up their "auction house" in their next few patches (if they haven't already).

Use cases for the broker:- Player wants to sell an item they possess.- Player wants to purchase an item they need.

My expectation is for production to understand and own the implications of the use cases in the context of their particular games. Here, we'll look at the first case generally, avoiding going too far into game-specific minutiae.

In Aion, "Player wants to sell an item they possess" involves deciding the price and transferring the item to the broker system, which really means...

Player travels to the broker NPC to interact with it.

The interaction brings up some UI, but the player doesn't really care because...

... the player right-clicks on their item that they want to sell. The UI populates the search field with their right-clicked item.

The user presses Enter or clicks the Search button to see all current listings.

The player now knows what their item is worth. This is an intention!

Compare this against (disclaimer: what I remember of) the equivalent SW:TOR Galactic Market use case.

Player travels to the Galactic Market terminal to interact with it.

The interaction brings up a UI.

The player looks at the drop-down labeled "Required" to understand the drop-down selections.

The player chooses the drop-down selection that seems most appropriate for the item.

The player hits search that returns the listings of that drop-down categorization at that time -- but to enable the Search textbox.

The player types the name of their item into the Search textbox.

The player presses Search to search for listings that correspond to their item.

If no listings are found, the player might go back to step 3 to make a different guess at categorization. If listings are found, the player now knows what their item was worth at the time they searched for the categorization*!

Wednesday, April 4, 2012

I've been called a Google enthusiast. Throughout my time as a Google fan, though, I don't immediately recall a huge push for Google Offers. Today's is the first, executed through Starbucks as a $5 for $10 offer that also donates $3 to American jobs on Google's behalf.

Jobs, drinks, and electronic payment innovation offered today.

Let's consider the hard, prospective gains for each involved party.

Starbucks stands to get more business from Google users.

Google gets some attention to its Google Offers product and Google Wallet product.

I (the common consumer) get five bucks toward Starbucks, as well as -- if you're into this sort of thing -- the feeling of charity for making Google give "American jobs" $3.

The Hope and General Conclusion

Today's experience was generally negative and could be considered a failure. There are many opportunities for this experience to be improved.

As soon as this offer was revealed, my hope was for an innovation in electronic offers and payments. I want to see ideas, which could especially (or only?) come from companies like Google, that eventually replace my wallet -- it's what they're trying to do anyway, and I'm excited! Could my shopping become as easy as installing an app on my phone and tablet from my desktop?

Not yet.

The User Experience

Let's break down one user's experience to clarify the problems and focus future improvement possibilities.

The consumer receives an email, from the My Starbucks Rewards program, to inform them of the offer. A "Sign Up for Google Offers" button is prominent in the email.

The consumer receives an email, from Google Offers, to inform them of the offer. A "VIEW AND BUY" button is prominent, and a relatively clean bullet list reveals details.

The consumer receives an email, from Google Wallet, to inform them of the offer. A "Sign Up for Google Offers" button is prominent in the email.

The consumer follows any of the aforementioned buttons, links, to arrive at the same page.

The user clicks the button to purchase the offer to have Google Wallet load their payment information -- if it exists. I'd love to hear from anyone who didn't have Google Wallet payment information stored.

The user confirms the purchase to complete the transaction.

Google Offers sends the user an email receipt to inform them of the transaction.

I don't know what to do right now. The user attempts to find information to obtain the goods purchased.

The user sees a link to the Google Offers app advertised on the purchase confirmation page (not the email), which says the mobile device can be shown to the retailer -- perfect! -- and downloads the app. Momentary confusion: I have the Google Shopper app; is that different? Answer: apparently, yes.

The user physically makes a trip to a Starbucks to find out more information and purchase a drink with the purchased offer.

The user shows the Starbucks employee the Google Offers screen to obtain the purchased goods, because the app says "Show this screen to retailer to redeem your offer.". The Starbucks employee does not know how to make use of this.

The Starbucks employees try to find out how to make use of the purchased offer. Specifically, they ask other employees, try to interact with the app, and call someone off-site to find out how to make use of the offer.

The user opens up the web browser to navigate to the website listed in the app.

The user navigates through all the required UI actions to get to their purchased offer under "My Offers".

The user follows any UI component that could possibly lead to a resolution, to possibly reach a resolution. It works and a UPC bar appears.

As a consumer, the primary intention was to get $10 for $5. After that, my secondary intention was to get a drink.

I didn't really care which services that involved -- I trust Google, perhaps more than I should. I'm already signed up for many of their services, even when some are not useful.

Sixteen outlined steps is huge. If you had the patience to get through it all, you can see that there's a lot that lies outside of the user intention. We can distill the process according to the user intentions.

Steps 1-4: Information.

Google partnered with Starbucks to give me $10 if I spend $5? Okay, sure -- I want that, but the following doesn't tell me how to get it.

Given the above, describe to me how I get my $10 for $5.

Steps 5-11: User Actions toward Intention.

What do I need to do to get my $10 for $5? Google and Starbucks did not provide the actions required from their consumers. The users could have been informed of the expected process, upfront. Here is what Google developers seem to have expected.

Purchase the offer from Google Offers to take advantage of the offer.

Navigate to google.com/offers, click the "My Offers" button, navigate to the Starbucks offer, and click the "Redeem" button to reach a page with a UPC bar.

Present this UPC bar to a Starbucks employee to complete the transaction, either by printing out the page, or by navigating to this page on your mobile device.

Had this process been communicated to me from the very start, I could not so easily consider this Google Offers attempt a failure.

Steps 12-16: Delivery of Goods According to User Intention.

I expect a Starbucks employee to actually credit me with my purchased offer's goods. Once we all figured out how to do that, this delivery became possible.

The Payment Innovation Hope: A Successful Example

As stated, I'm excited to see the implementation of ideas that streamline the process of payment. Let's look at Eventbrite's implementation, which has achieved the following, simply because of graceful user interaction/experience design.

Made me a user of Eventbrite where I would usually not be an Eventbrite -- or any event-organization service -- user.

Streamlined the acts of making an RSVP, payment for event tickets, and attendance.

I receive an email, from Eventbrite, to inform me that a viewing will happen. Now that I think about it, I'm not exactly sure how they knew to email me -- possibly from GDC -- but that's okay since they correctly targeted an interested consumer.

I select the number of tickets, enter payment information (because I don't want to link my PayPal account), to complete my transaction.

At the door, I show them my Eventbrite app, which immediately displays the barcode to allow me entry. The app was already downloaded and installed.

Note the closer mapping of information, user action, and delivery of goods. Especially consider that the hurdles are user-created -- I chose to consider additional incentives and look in two different mediums (email and twitter). It was not forced upon me by the process.

Let's look at my GDC experience with Eventbrite, which really made me an Eventbrite user.

User "purchases" GDC party tickets from Eventbrite at $0.00, to gain entry to future party. There are many parties which do this.

User forgets printed tickets. Unintended user action.

User looks up confirmation email on mobile device, because it has the QR code in it, to show bouncer and gain entry to party. User sees there is an app.

User downloads app to satisfy curiosity.

User loads QR code from app to show bouncer and gain entry to party.

Again, we see a closer mapping between the user intention -- getting entry to a party -- and the minimized process to reach that. Complications are created by the user.

Eventbrite deserves further commendation because I was never at risk despite my own complications. Without their downloaded app, my QR code was still in my confirmation ticket. Compare that with today's experience for Google Offers, where my email confirmation only has a link to a website, which itself has a link to the actual purchased goods.

Three Recommended Future Steps

I want to see innovation on my payments, services, and delivery of purchased physical and virtual goods. Here's how I would make that happen if I had Google's development power.

Clarify and communicate the process, with consideration for the user intention.Validation/results: user can correctly inform the developer of how to satisfy their intention through the developed system.

Minimize the process, maximize the opportunity for intention satisfaction. Despite the user knowing how to reach their goal, the way to do that can still suck. You can steal Eventbrite's practices directly (why not give me my UPC code in my confirmation email?), or try to minimize the process in a new way -- just iterate with your developers' ideas on how to get better than the process from 1, while always making sure the user can recite it back to you without your having to teach them. Validation/results: user can achieve the same intention as 1 in a more efficient manner, as measured by time, interaction, steps in process, or whatever is relevant to your project.

Reduce external confusion. With some solid process available, we can now expand into reducing the confusion outside of that. Users don't know why Shopper is different from Offers right now. Users don't know why Offers isn't showing the bar code that the Google Offers website does show. Eliminate these questions: choose a medium (I vote for the mobile app, personally) and synchronize all mediums with that one as the primary. Validation/results: you can delete the non-primary services while users know they can achieve their intention with that primary, single medium.