Recent Blog Posts

Netflix is perhaps my favorite use of clever signaling, as well as a nicely understandable analogy. The DVDs are the data. They are sent via mail – the USPS is the traffic channel. The website (and to a lesser degree, email and RSS) is nothing but a signaling channel: a way to indicate what data is needed, queue future data, and confirm sending or receiving of data packets.

A similar method is used when the credit card company calls you to confirm a transaction you are performing in person, or on the computer. The phone call is an out-of-channel data confirmation signal, different from the ordering and payment process you are trying to perform elsewhere. A key use of out-of-channel confirmations is for security purposes – spoofing or intercepting one channel likely does not mean other channels have become vulnerable.

One of the things that has always made mobile telephony neat to me is that it’s inherently multi-channel. The IS-95 standard – the one with which I am most familiar – uses the paging channel to send information about the network, separately and at much lower bandwidth consumption than the traffic channels. (This is why add-on VoIP systems blow your battery so fast; signaling occurs in the traffic channel, so it has to stay up all the time).

One of the more beneficial ones is SMS. We do a lot of projects that use SMS as a signaling method. Much like the Netflix example above, users can receive an SMS with a link. This can then fires off a download, a web address or an already-installed application (usually. A few carriers like Verizon don’t let most messages carry active links).

That last – coupled with Java push messaging, not requiring the user to explicitly accept the SMS – is by far the snazziest. Pretty much every application on my phone, even the “widget engines” sits there dumbly until I fire it up, and often continues to sit there until I explicitly request data. Instead, you can build a push system, and whenever a weather alert is sounded for your area, or the flight is delayed, or a co-worker loads changes to the project plan, a specially-formatted SMS is sent to your phone and the appropriate application opens right to the most relevant screen.

(As an aside, credit card companies are starting to perform a variant of the out-of-channel confirmation signaling over SMS)

Other such practices, extending these principles, will presumably emerge over time. Telemetry data (your position, and other such information) is already being sent to the operators routinely. If this back-channel signal can get used by 3rd party services, they can analyze it and send out messaging based on your current state. Most talk along these lines is for push advertising (visit the Starbucks 1 block over and get $2 off!) but most any mobile service could be enhanced by it. This is the contextually sensitive world I’m waiting for.

A while back, I posted a link to the Squidoo lens on mobile design that I’ve been assembling. I try to keep it up to date; there are 11 top mobile design blogs represented there below the various link resources.

Content includes:

1. Mobile design resources
2. Mobile Web Strategy
3. Mobile Design conferences
4. Miscellaneous Resources
5. Design Resources on Amazon.com
6. Companies to help you in mobile design
7. Developer Resources
8. Top Blogs
9. Mobile design bookmarks

First, let me summarize the back story. Jono DiCarlo, as part of his These things I believe post states in point #6 that UI design is not marketing. His point seemed to be that marketing through UI was inherently a lie, so failed the consumer or end user.

Chris Fahey more or less rebutted this in his UX of a Salesman post last week by stating approximately the opposite. You need to go to one of his two upcoming presentations to get the full story, but overall, he's pushing the role of satisfying the user's demand at acquisition time. So as far as I can tell, yeah, usability and design is about marketing to him.

Khoi Vinh then posts in the Subtraction blog (where I finally ran across this, then had to catch up) that he, again, feels that "interface is marketing." It's a designer's role to make things that are covetous, so people will want to buy them.

This started to really get to me, and make me think I should talk about it, when this totally unrelated post touched on the same issues.

Okay, so first, what is everyone really talking about? I think there are several issues.

1. Design
2. Marketing
3. Customer experience

Customer experience is one most folks seem to have not heard about. Organizations that really care have been doing this – and doing it well – for a long time, but I've only been aware of it as a codified job area for a few years. The whole job of a CX team is to make sure every customer touchpoint, throughout the customer lifecycle is consistent, satisfying and reinforces the brand. Think or search and you'll find examples like Nordstrom and Zappos.

So, where do UX-types (to include interaction designers) fall into this? Well, I say, all of it. Sure you have to market, and consider the lifecycle experience, but tell me you haven't been doing that anyway?

Consider a product – as I was just this morning – that requires registration to proceed past the intro graphics and sample version. What does your design center around? I say:

• Communicate what the product does, once the user signs up
• Do everything within the corporate and product brand
• Entice them to act now
• Clearly state what is involved in the process
• Carry through on this – keep the interface consistent with the expectation already set

That is, you consider how to market to the user, to get them to want to click the right part of the page, and you build the whole signup and first-run process as a consistent, satisfying experience.

That all just falls into the larger goals. If you can make a signup box and process to market to the customer, you can make the whole product, or a whole set of products for your company or clients appeal to users and meet corporate goals about selling, or signup, or churn.

In fact, we've said this all along. Check out our home page for another take on this. Brand is core and will guide your decisions; strategy, marketing, technology and design all contribute to success.

And, no matter how cynical you'd like to be about marketing, there's not a bit of lying. You are communicating what the product actually does. I am comfortable saying anything about a product or feature, and enticing users to click on things and sign up for service and make purchases, as long as it's all centered around unambiguously truthful information. If anything, I say most interactive products are undersold, with perfectly cool, easy-to-use features no one knows about. It's your job to make that design work for the company and the end user, so the product is used to the fullest extent.

Lots of marketing metrics are actually useful, and worth fighting towards. Churn – how many customers leave (or stop using) your product after a certain time period – is a favorite measure of mobile operators, but also one of my favorites. Customers churn, mostly, when they are unhappy. Improving customer experience, and user experience has demonstrable effects on churn. When you design a better experience, you are improving marketing metrics, and pleasing customers. The two can and should work hand in hand.

In Rachel Hinman’s ongoing thought series, she points out how we disengage with the world:

Lately I have been thinking of a sad sight I see often – a person, walking around utterly disengaged with the world around them, head buried in a mobile phone. It’s evidence of an incredibly unfortunate relationship that we humans have established with technology objects. They demand we disengage from the world and focus on the object – give deference to it, instead of the world.

The iPod Shuffle is far less likely to engage its wearer so much that she crosses the street without looking. The Touch and iPhone require more interaction. Perhaps if I were listening to music and I could just pull the earpieces out without missing much, I’d feel differently. As we frequently discuss, a good design is optimized for the context in which it will be used.

This is a problem that we as the mobile industry tend to exacerbate. Cool highly interactive experiences, like much of the iPhone’s UI and many touch interactions, require the user to stop and exclude the world. Fine for games, not so good for music players. Despite my iPod Touch, I still use my iPod Shuffle for being out in the world. I’ll use the Touch only when I have the freedom of some guaranteed uninterrupted time. I like to be able to interact with the world with only one second’s delay.

The takeaway: decide whether you need to design for users immersed or emersed in your product, or perhaps facilitate both behaviors. Then do it. But don’t assume.

The Interaction Design Association mailing list is currently running a straw poll asking, “What are the top 3 things you find yourself doing now with your iPhone that you did not do before and why?”.

I’ve included the list below, but notice something: only two items in the list are things I have not been able to do on my three year old feature phone. Not only that, I have been doing these things on my three year old feature phone, for three years. These are technically sophisticated users, but they are reporting “new” stuff they’re doing.

So, why? I think there are four reasons:

1. Better marketing.
2. Better web browser (compared to most phones in the US)
3. Better integration with music, podcasts, and now application store (online and computer)
4. The above made an unlimited data plan be normal

Better marketing means that people are more aware of the services. Better browser stimulates browsing (but it has a long long way to go). Better integration with distribution like iTunes (application and iTunes Store) makes content get onto the device without much effort. And of course unlimited data stimulates use across the board.

In many ways, I wish I still worked at an operator right now – preferably at a senior level. Apple is giving me lots of ammunition.

Task-based responses as of 1700 GMT-6:

email 7
listen to music/podcasts 5
browsing 5
games 4
maps 3
texting 2
GPS apps (e.g., iWant, urbanspoon, showtimes) 2
install apps 2
stopwatch 2
wikipedia 1
checking stock 1
news 1
movies 1
pictures 1

Responses that were more about the value:

diversions 3
not trapped at desk 2
resolving arguments/book review/contextual web 2
communicating 1
feeling connected 1
deciding not to go to work 1
facilitate work 1

Almost every project I have worked on, for most of my career in interactive design has had at least some security component. Users have some sort of account, or submit payment information, or do something else which requires authentication, authorization and protection.

Security has to be baked into product design, and done so with a security mindset. Security conscious designers will assume the worst, and be able to dream up ways of attacking their systems.

Ideally, these are the principles of any good designer; you should always be looking for flaws in your design, and be willing to take a big brush out and paint over parts that don’t work. It’s always best to get these things fixed early, before users become upset, data stores get overloaded and security is compromised. It’s always easier to fix things in design. And however painful it is to ask for a change now, it’ll be worse when the client comes back to ask why the product is broken six months after launch.

So, that said, here’s a set of security principles, guidelines and concepts I work towards with my designs, in no particularly well thought out order:

Evaluate the risks

Consider what is being secured. An online game needs much less security than a banking application. The key to deciphering this is to understand the risk involved. How much damage could inappropriate access cause? Be realistic. Not all financial liability is the same. Unauthorized bills for 99¢ games is not the same as a banking app offering access to real world accounts.

Users rely on you

Remember that there’s a counter-risk to excessive security. If it’s too hard to use, or too hard to recover passwords, your service may not get the use you wanted. The risk is not just to your sales and churn numbers. If users come to rely on a mobile banking application, then cannot pay their bills for a week while out of town due to an authentication failure they cannot fix from the road, that’s well-nigh as bad as people stealing from their bank accounts.

No lock is impervious

A key to security theory is that no lock is unbreakable. The safecracker has to not just get the lock open, but do it before the cops come and stop him. Your front door lock works on this principle. No matter how great a lock you have, it’s pretty easy to pry the whole door off, or bust out a window. But you or the neighbors will probably notice that. The same principle applies to security of interactive systems. Make appropriate security measures, and have ways to detect and fix them when they are violated.

• Detect – The reason you get all those emails saying you changed your eBay password, or purchased something with Amazon 1-click is not just for your records, but so you have a chance to say “no, I didn’t” and fix it. Sometimes, end-of-month bills are enough. Often, immediate notification is better. Out-of-channel (e.g. send an email) is often a good system, as many security violations are only going to have access to one system. The evil doers often have no way to intercept such messages, so the window of opportunity is smaller.
• Limit – The user should be able to lock their account, or otherwise stop any suspected security violations, immediately. If your system has serious liability potential, have some phone support 24/7, just for fraud issues. Automatic detection can also work. Severe changes in user activity can be detected by your system and acted upon – usually, first you notify the customer; try not to shut them off without callig first. Credit card companies are good at all of this. Look at how they detect and limit fraud, while not excessively bothering their customers.
• Fix – How can a security violation be repaired? Often, it’s easy. If you sell games, you probably have a refund system already in place. Just extend it to fraud situations. Sometimes it’s hard. Social networking sites that allowed inappropriately authorized user posts could destroy their reputation. Consider ways to block old comments, or over-write them with a notice that these may have been hijacked, and should be disregarded. It’s not perfect, but if the service can say something that’s got a lot more weight than the user trying to defend himself.
  If you sell banking services, or something else hard to fix, then work on detect and limit, a lot.

If someone finds a hole, believe them

Anyone can build a system they cannot break. Ideally, your system is multi-dimensionally robust enough that a breach is not going to become catastrophic, anyway. Regardless, if someone else on the team, or your mom, or your nephew, finds a way to break the security, believe it. Don’t blow it off and assume it’s an edge case. Security violations are all about edge cases. Fix it, and if possible see if there’s a bigger root cause to the gap.

Know your user

Too many systems (and designers, and developers) assume you can be signed on, or not. Wrong. There are at least three levels:

• Anonymous – Users who are totally new, or have no cookie, or similar are anonymous. Depending on the way the system identifies users, you might be able to assume they are new, and offer them different information.
• Identified – A lot of folks call this “cookied” but that’s just a technology to accomplish it. Device possession (mobile devices being fairly personal) is a good way to do it. One way or the other, the system has a good idea who the user is, and can offer them the full personalized experience.
• Authenticated – This is the signed on one. The user can get full access to whatever they need. But often, it works well as a subset of “identified.” When the user hits an area that invokes financial liability, or they want to change their password, or something else, you can hit them up for a password to become authenticated.

Add factors

I am not a big fan of multi-factor authentication, because it’s generally too much for the user to deal with. In certain cases, smart cards and similar devices are useful, but they generally fail for consumer applications.

However, there is one case where it’s useful, and that is using device-possession. It’s not quite the same level, but once the device has been validated as being owned by the registered user, it can serve as an authenticator (as well as the identifier, above). This can be used any number of ways, depending on your application. A suddenly different device could require additional authentication, re-validation and fire a notification, so the user is aware of the change in case it is not valid access. This is much harder to do reliably with desktop computers.

Authentication is not (necessarily) authorization

Authorization and authentication are often confused. Authentication just means you entered credentials, and now the system is sure it knows who you are. Authorization is what you are allowed to see and do. That can vary by user, by device (mobiles, or home computers might not be able to have access to some systems that work on the internal network) or by authentication level. Identified users will also have an authorization table, revealing what they can access and accomplish.

Design for profiles

This is a topic worthy of a series of posts. I have several different powerpoint decks on it. What I am talking about is different security profiles for different access methods. You might need, or want, different credentials, different recovery systems and different authorization depending on the method of access. If carefully handled, this doesn’t have to be a problem; my online banking authentication has no relationship to ATM authentication, for example.

Even if you don’t need this today, you might be expanding later. All the security systems need to be expandable, so you are not stuck when your product is a huge success and grows by orders of magnitude. Create, in summary, a target security architecture and build whatever is needed of that. But make sure all the developers have a copy of the target, and are building in that framework.

Don’t give away the store

Any discussion of adding identification usually talks about cookies, and url strings. And those rapidly degrade into talking about how much information to place in those keys. The only right answer is “none.” Treat these as keys, only. They should have arbitrary values, not related in any way to the user’s name, account number, phone number, etc. The server then looks it up and decide to who it’s attached, and to what they have access.

I also want to emphasize how much key values should not be hackable. Do not use obscure data, do not use known user data to encode a key, and do not even use the timestamp of a session as the seed for a key generator. All of these can be easily found, decoded with varying degrees of difficulty, then used to easily decode all the other keys used on your site or application. This happens all the time. You are not immune.

Recovery schemes

Users will forget their usernames and password. They will need to change devices. Recovery schemes need to be provided to let them get access back, rapidly. Sometimes it’s desirable to delay them, or take them out of channel. But unless there are specific security reasons or a suspicion of fraud, you generally want to be as helpful as possible and let them back in right away.

Having actual people answering phones can be nice, but if that’s the only way to regain access, it has to be friendly and fast. Minimize time on IVRs, and make sure there’s no transferring to do this. It’s considered a simple task, and the user is already annoyed. The best is to provide a self-care system and let the user reset themselves.

I use reset and recover somewhat interchangeably in these discussions, but I am wrong to do so; don’t follow my lead. They are different and which one you use depends on the manner of reset or recovery. Most often I will allow recovery of usernames (you don’t generally want to change those), but allow users to see their old password, then require them to change it. A sort of reset/recovery. This has the advantage of reminding them what /sort/ of password they use, which might help them pick one they will not forget in the future.

As far as which method to use to recover or reset, I like question & answer pairs. The whole “what color was your first car?” sorts of questions. This method of secondary credentials have gotten a bad rap from poor implementations (mostly, bad questions) but are often a pretty good solution. If keeping users in-channel is good (and it may not be from a security standpoint for your application) they should be considered. For mobiles, users often cannot get to a computer so you might have to allow recovery from the device if you want that user to continue paying for your service.

• Use questions that are not time-dependent. E.g. What was the color of the /first/ house you lived in?
• Use questions that are not possible to derive from generally-available records. Mother’s maiden name, parts of SSN, and other keys are easy to hack if someone has access to customer data, can be used to build a record of customer data themselves, and are now actually disallowed in the U.S. by the FCC (if you are a carrier/operator). More rules are coming so get ahead of them.
• Try to ask for information that encourages simple answers. As a bad example, if asking for city of birth, tell them to leave out the state.
• Think about data storage and processing methods. Usually, disregarding spaces and special characters is best. Then running stuff together and commas are of no significance to the entry. For the city example above, you can probably just look for all possible state names and abbreviations (and mis-spellings) and disregard them. Case should also be converted to one of them, only.

Personal space

Mobiles make entry of information difficult, and are often used in situations where the user is distracted. Entering passwords the normal way is harrowing, and invites keying errors so bad I’ve seen plenty of people never get past the sign on screen. By “normal” I mean masked, or dots-instead-of-actual-characters. Instead, accept that mobiles are very personal. The small screen means there is almost no way to look over someone’s shoulder casually enough to read passwords, so they can be simply left unmasked.

Let your users take some responsibility

I don’t mean make them sign a waiver. I mean, don’t be too annoying about password requirements. Let the user choose their own. If you give them onerous requirements they’ll just keep forgetting it, or have that much more dislike for your service from day one.

As a general rule, mobiles have numeric keypads. Therefore, pretty much all mobile passwords should be numeric only (I guess, making them “PINs” instead of “passwords”).

Device-level security

Often, the best security is to remind users how to best secure things. Many devices, especially mobiles, have device-level security. If a user is truly worried about someone getting into your website or application, they are first worried about someone gaining access to the device (especially if you use device-possession as part of the credentials).

Therefore, I never turn on the full security of any application by default. Security settings pages allow users to require PIN, and add other restrictions, but also tell them to consider locking the device instead.

Barbara thinks this should be added to the wiki but I am not sure. It’s mostly general guidelines, instead of mobile-specific. Some of the mobile guidelines, and others not discussed here are already covered in the Text Entry topic.

Tell me if you think it should be in the wiki or, better yet, add it yourself.