Tags to Richness

Funny but true: a quick illustration of how the brain works

Mon, 07 Feb 2011 18:40:21 -0700

Based on the neuroscience books I’ve read I’ve come up with a really easy way to explain to someone how the brain works. Below the illustration I explain the nature of the three components of the brain: You, the Nag and your Body.

You

Your consciousness and personality. The lump sum of your memory and experience that determines how you make decisions and who you are.

The Nag

The various parts of your biology that you can’t change but that push and pull you to make certain decisions. The Nag tends to be very simple and straightforward in its needs. The Nag’s needs tend to revolve around food, sex and survival. The Nag cannot be reasoned with, only ignored and suppressed.

The Nag is hyper aware of what is outside your body and will scream and yell at you to get something it wants. If you’ve ever driven by a McDonald’s with a three year old in the back seat you know exactly what I’m talking about.

Your Body

The machine that transports You and the Nag. Your Body needs fuel and constant maintenance. Eventually your Body will have too many miles and break down and die.

UX in the near and long-term future, 4 ideas to ponder

Mon, 31 Jan 2011 18:30:00 -0700

I’ve spent some time the last couple weeks trying to envision the near and long-term future of interfaces. I came away with the following useful nuggets.

1. Currently interfaces are moving out into the world where the people are

In my mind the biggest breakthrough with smart phones is that all that functionality that used to be on that computer in the corner is now traveling with me out in the world. I’m more compelled to use technology now because it’s with me as I live my life. Mark Weiser called it ubiquitous computing. My lifetime will most likely see ubiquitous computing reach an advanced level of maturation.

2. But the real event will be when we finally learn to reprogram our biology and the biology around us

Ubiquitous computing in its current state is about making smaller computers that can be a part of a variety of current and future devices. But I ask you, why waste time creating new devices when you can just reprogram the devices already out there, i.e. our bodies, minds and the nature all around us. The sad or happy truth is that this will happen some day whether we like it or not. The six million dollar question is who will do it first and how humanistic will they be? But it’s exciting to me to think about reprogramming the human brain to increase it’s memory speed and capacity, for example. Or better yet, being able to transfer our memories and our identity over time, defeating death.

3. The mash-up of artificial intelligence and applications

Back to the short-term, artificial intelligence is really the future of apps. I don’t know about you but I absolutely hate yet another app I have to learn and spend time using. All those casual consumers who love their Wii’s won’t waste time with Gowalla, only the tech nerds care. I personally don’t want more apps that require more of my time, I want less apps that do more. Artificial intelligence, or the creation of an algorithm that can resolve complex problems for me with little input from me is where the real money is.

4. Eventually all those independent AIs will become the singularity

Eventually all the artificial intelligences we invent will merge into a single superintelligence that governs our lives. This is what Vernor Vinge and Ray Kurzweil called the singularity. The funny thing is after pondering this for some time I realized that as a species we’ve been designing and iterating on the design of the singularity since the beginning of known time, we’ve just called it God or Gods instead of a supercomputer. At some point when the pack of engineers sit down to invent a governing intelligence I imagine them referring to all the religious texts and history to devise the initial version.

There’s one other thing to keep in mind here though, and that has to do with reprogramming our biology. When we start reprogramming our biology and re-engineering our bodies and minds, we may not need a singularity as we conceive of it today simply because at that point we will have become a different kind of species with different needs.

How I tie my UX work to sales and revenue

Mon, 24 Jan 2011 19:23:31 -0700

At my company everything the marketing team does falls under our sales funnel. This means that everything I do as the UX designer falls under one of the segments of this funnel. With this relationship, it’s easy for me to demonstrate how my UX work affects my company’s bottom line.

You’ve probably heard of the sales funnel before. Every company has their own version. I’ve illustrated below the sales funnel my company uses. Below that I briefly list the UX work related to each phase of the funnel. My company’s product is a subscription based web application, so our funnel reflects the sales phases that come with a subscription based app.

My company decides what design we should pursue next by taking a look at the current metrics of our sales funnel. The part of the funnel that is the lowest or suffering the most gets the highest priority.

1. Impressions and Clicks: The UX goal here is to get people to click in less than two seconds and introduce the brand. UX deliverables: Banner ads that are either static, flash or dynamic.

2. Trial Taker Rate: The UX goal here is to introduce people to the application and do whatever else it takes to get them to take the free trial. UX deliverables: Landing pages, homepages and micro sites.

3. Conversion Rate: The UX goal here is to get people to their first success in the application during their free trial, ideally within the first few minutes of their using the app. UX deliverables: The application itself, especially functionality related to the first success. It might also include all the detailed functionality and experience.

4. Retention Rate: The UX goal here is to keep people subscribed to the application for as long as possible once they have converted. UX deliverables: The application itself, with experiences designed to last over time and/or over a desired customer life cycle.

9 Direct Marketing ideas to create UX that sells

Mon, 17 Jan 2011 19:56:51 -0700

In 2005 I had the privilege of attending a three day workshop by the D.M.A. (Direct Marketing Association). I recently dug up my notes for a project I’m working on and came across this great list I had put together based on that workshop. The list is still applicable today as I design UX that sells:

Multiple offers in one promotion equals lesser sales.
Direct marketing leads the customer to take an action. Advertising is solely for building brand awareness.
Broad based media like TV, Radio and Print are best used to find new customers.
40/40/20 rule: Direct marketing success depends on 40% on reaching the right audience, 40% on the offer or promotion and only 20% on the creative execution.
Features are all about the product. Benefits are all about the customer. Benefits are more likely to sell the customer.
The direct marketing industry is highly prone to mistakes. Expect to make a lot of mistakes.
Find out what products your customers want to buy and make those, rather then developing a product and then try to find a market for it.
Average creative can sell a great offer.
Testing equals what, research answers why.

Will software engineering die some day?

Mon, 10 Jan 2011 19:10:00 -0700

In 2010 Wired magazine published an article about the death of the web. Basically it was pointing out the fact that the mobile market was the next big thing and people were moving away from the web. What I can’t wait for is the day when Wired announces the death of development. By that I mean the day when software development is so cheap and easy that most companies will finally put design first.

I realize that some companies put design first already, but they are few and far between where I come from. Most of the companies I have worked for here in Utah don’t work that way. Think about it from the small town, small business owner’s perspective. If I want to start any kind of electronic based business (and I don’t really know what I’m doing) what’s the first and most important hire I’m going to make? The engineer of course. That’s because at the end of the day if I don’t have someone who can actually build what I want built then I’m totally wasting my time. And so the viscous cycle begins.

The vast majority of development today isn’t easy, so I have to hire a very talented and experienced person. These people are not common and aren’t cheap. When I finally find my guy most of my budget goes towards his or her salary. To make a long story short, after hiring an accountant, marketer, customer service rep, lawyer and so on (all extremely critical roles for a business), my money is all spent.

Case in point, I have my current design job primarily because I was originally considered as a flash developer. I had to make my current position as an interaction designer into what it is after I got hired.

Software development hasn’t been around nearly as long as other industries. But if the history of the construction industry is any indicator, someday development will be so refined that almost anyone can do it with just a little education. And then on that day, when development skill is a dime a dozen, perhaps designers won’t be such an afterthought as they are today.

4 UX Portfolio Tips

Mon, 03 Jan 2011 19:33:00 -0700

It’s that time of year again, when many designers take time to update their portfolios to keep them from getting stale. I spent most of my free design time in 2010 fine-tuning my own, here are some of my learnings.

1. The people looking at our portfolios know exactly what we do

I’ve heard many a hiring manager ask a designer, “What exactly did you do on this project?” These hiring managers know what a wireframe, flow chart, persona, usability lab and a prototype are. And more importantly, they know that that is exactly what we are going to be doing day in and day out for them. So that’s exactly what they want to see in your portfolio, your wireframes, flow charts, personas, labs, prototypes and any other artifacts you create. They care less about the overall project and more about your specific contribution.

2. Always project positive confidence and strength

Your portfolio is your sales brochure. At this stage of the sales process the last thing you want to do is introduce any seeds of doubt in your buyer’s mind. Never bring up phrases that say things like “weakness” or “what I learned” even in jest. Mentally those words, regardless of context, are still linked to negative emotions, and though they may be subtle or humorous, they still take your visitors down those emotional roads.

3. Get people to what they came for right up front

People coming to your portfolio want to see your work: your wireframes, flow charts, personas, labs and prototypes. If those aren’t the biggest thing on your homepage, front and center, then you’re failing to help your users reach their goals on your site.

4. If your work is company confidential, do a “snap” like dribbble.com or forrst.com

A “snap” is simply an ambiguous corner of one of your drawings. A “snap” fails to give context, so you aren’t giving away any company secrets, but you are still showing your design work. Hiring managers will still see what they came for, because they have the knowledge needed to assess your skill even without full context for your wireframe, flow chart or prototype. You can save the nitty gritty details for the interview.

What if we made software the same way they make movies?

Mon, 27 Dec 2010 21:28:48 -0700

Having studied film in college and having made a few short films, the thought has crossed my mind once or twice, what if development shops made software the same way they make movies? Imagine this scenario:

1. Assign a director, find the right writer

Today’s software has so many owners that the end result is often a muddled mess. A product owner is the closest thing the software industry has to a director, but the product owner is often not intimately involved with every aspect of the process nor given the same kind of ownership as the director of a movie.

After the software director is chosen, they would then find the right writer, which in the software world would be the right interaction designer.

2. Pre-production, 3-6 months

After hiring the right Interaction Designer, begin the following tasks:

Requirements gathering
Conceptualizing
Wireframing
Site maps and flow charts
Prototypes
Usability Labs

2. Production, 2-4 months

This would be the development phase. Notice the development phase is much less than the pre-production phase. What would a product be like that spent more time nailing down the particulars of the design than time spent developing?

3. Post-Production, 6-8 months

This is the QA phase, the loop of finding bugs and polishing them. Notice this is the longest of the phases. And appropriately so, because this is where the software would be polished as close to perfection as time and money would allow.

Summary

The software industry can stand to learn a thing or two from the movie industry. Unless you’re a Microsoft or an Apple, software today is often very messy, made by messy processes. What would it be like if the software industry followed a similar process to the the process of making a movie? I’d be willing to bet that the end product would be much more well conceived and executed, just as the majority of movies are today.

If you want to own a product, go into business, not design

Mon, 20 Dec 2010 17:56:53 -0700

For the longest time I’ve been under the assumption that as the senior interaction designer I would eventually be able to define my company’s product. Come to find out, I’ll never be able to define the product because it’s not mine, it belongs to our marketing team and ultimately our C.E.O. The real problem is that there are things about the design of the product that the true owners and I will always disagree about. I love what I do, I’m not complaining at all, I’m just acknowledging the fact that I realize I want to own my own product one day and that that’ll never happen as the designer.

I’m sure a lot of designers have that ownership itch. You know you’ve got it when you spend a lot of time trying to influence the product, using every means you know, even branching into that scary world we call politics. But at the end of the day you realize the nagging feeling is true, it’s just simply not your ship to steer and it never will be. That’s what Product Owners, V.P.s and C.E.O.s do.

If you’re a designer and you constantly find yourself wanting to own a product’s definition and direction, I hate to tell you, but you went into the wrong profession. Designers are still just tools for the business people, heavy influencers at best, but never owners and original creators. If someday you want to own the product, stop what you are doing and go get an MBA or start your own business.

Show the wrong design as early as possible

Mon, 13 Dec 2010 20:25:52 -0700

I’ve developed a design method I call showing the wrong thing as soon as possible. The idea is this: When I start a new project for a client, I have an initial meeting with them where I hear their idea. I then go off and design the first thing that comes to my mind that fits their need. It’s often not polished and not the right solution, but it represents a complete and concrete idea in higher fidelity. I then hurry to get the design in front of the client. What happens next is always the same, the client rips it to shreds. And that’s exactly what I want them to do.

Humans are very skilled at noticing differences, it’s how our brain is engineered. So when I’m showing a client something wrong, what happens is their brain freaks out about all the differences between what they are seeing in my design with what they are seeing in their head. So the client’s feedback starts flowing like a river as they describe all the problems they see with the design. I quietly write down everything I hear, encouraging them to talk as long and as harshly as they need to. I take none of it personally.

This is how I am able to read my client’s mind faster than any other methods I’ve tried, by forcing their brain to point out all the flaws. With all those flaws verbalized I can now easily go back and design the right picture based on the negative space left behind by the wrong picture.

My recent process for finding freelancers

Mon, 06 Dec 2010 18:04:00 -0700

Recently I was given a small budget to hire some freelancers to help with the large backlog of design tasks we have. Below are some of the steps I used to find the right people.

1. Posted on a design specific job board

I ignored the general job boards like workforce services, craigslist, hotjobs or monster. I went straight to authenticjobs.com, a very well known job board in the design community. My second and third choices would have been jobs.37signals.com and krop.com.

2. 30 seconds and three folders: Yes, No, Maybe

I didn’t read the emails I received. Instead I scanned them for a link to a portfolio. Obviously if there wasn’t a link to a portfolio I threw the email in the No folder. If there was a portfolio link I clicked through and could tell within 30 seconds of looking at their work samples if this was a Yes, No or Maybe.

3. First paid task is a test

You really don’t know what someone is going to be like and what their skill is until they actually do a job for you. So I would hand the freelancer I was considering their first task, paid of course, and the result would tell me what I was getting into. If the result was so-so I might ask for a second task and decide from there whether to keep them or move on.

One challenge we are having with Agile, long term planning

Mon, 29 Nov 2010 20:25:51 -0700

Agile at my company tends to be a very heads down speedy process in which design and development are always producing customer ready work. What Agile at my company doesn’t account for yet is any kind of long term planning. We desperately need a “planning” sprint where-in the design, dev and business teams purposefully spend time on foundational and long-term needs.

In UX long-term needs are things like a sitemap, ux bugs, personas, a style guide and our primary use cases. For the longest time I kept expecting someone from the product group to create or ask me to create any one of these items. But they never did. In our Agile process it became so easy to be focused on sprinting that no one bothered to think about or define where exactly it was we were sprinting to.

In our flavor of Agile, “documentation” tends to be a swear word not unlike the bad blood Agile has towards the word “waterfall.” But the sad truth is good planning requires good documentation. This is the fatal flaw of our Agile, in our effort to eliminate time-wasting documentation we also threw out the time-saving documentation.

How I’m doing my part

I known I’ll never be given a formal opportunity to stop what I’m doing and create a foundational element like a persona or a sitemap. Instead I have to slowly build them and grow them over time, a little here and a little there.

I’ve forced my schedule to include what I call the 5 UX buckets. I make what time I can along the way to slowly build and document the following foundational UX elements. And as Dan Brown says in his book Communicating Design, these documents are meant to be living breathing documents. So I’m ok with the fact that they are never “done” but are slowing growing and evolving over time.

My five UX buckets

Sitemap or content audit

Every time a new feature comes up no one can remember all the parts of the site that feature might impact. With a sitemap I am able to build a mental model that significantly aids in the recall of every nook and cranny of the site.

Regular usability labs to generate what we call UX Bugs

Every other sprint we end up asking ourselves what should we do next. Without the prior groundwork of regular usability labs and a backlog generated from them, we end up guessing in the dark about what we should do.

Personas and Customer Segments

For now this is a simple list of the types of people we encounter in our market niche. What ends up happening is we talk about them off and on here and there. And as we do I keep a master list of these features that slowly evolves as our understanding of our customers grows.

A style guide

When we are designing in some isolated piece of the site it’s easy to get caught up in a design that is unique to that problem but that ignores the consistency of the site as a whole. Until now we’ve been rushing so fast to get something done that we haven’t had the time to create a proper style guide. It’s easy to turn a style guide into a massive time-consuming inventory project that no one will end up using. Instead, as I come across a reoccurring UI or graphics pattern that I know will be too hard to remember later, I write it down in a master list.

Primary use cases

What are the critical paths that have to work, and work well, for our customers to get what they came for? The Primary use cases provide us with a way to prioritize the growing list of UX bugs we are generating from the usability labs. I can quickly rank a given list of UX bugs when I know which interactions of the site are more important than the others.

How I'm utilizing freelancers

Mon, 22 Nov 2010 18:36:10 -0700

A little over a month ago I had a budget to hire freelancers and after settling into a pattern with them, this is how I’m getting value from them. For this discussion there are essentially two phases to design, the critical thinking phase and the polish phase. The critical thinking phase deals with mocking and feedback loops until the key ideas are captured in rough drawings. The polish phase is when the website’s specific aesthetic details get applied to these mocks, like line width, color, margin size, etc.

I’ve found that it’s really fast and easy to get critical thinking from the freelancers, but that the polish will take a significant investment of time and energy in the freelancer before they are where I need them. The issue has been that because I have a limited freelancer budget and because the freelancers tend to have day jobs I end up only getting 2-10 hours a week of their time at most. For now I’ve found it’s more valuable to keep them cranking out critical thinking in the form of mocks while internally we apply the polish.

This method is similar to how Mike Shinoda describes Linkin Park’s album creation process.

In the new version of our process we’re no longer making albums and then touring and then starting from scratch and making new albums we are just writing all the time so that is to say when we’ve got a collection of songs we think is an album we release it

Like Linkin Park, I am having my freelancers create a pool of fleshed out ideas. And when the various priorities align I can easily take one, apply the polish and hand it off to the development team.

(Quote Source: Meeting of a Thousand Suns (Video Documentary) on the iTunes A Thousand Suns (Deluxe Version) LP)

How I dealt with a difficult situation at work

Mon, 15 Nov 2010 19:21:12 -0700

I’m by no means an expert at this kind of thing, but I thought it’d be worth sharing the strategy I employed recently for dealing with a difficult situation at work.

The Problem

I want to do my best to avoid hurting anyone here, so I’ll be as vague as I can without losing the insights. Basically we have a large project going on for our flagship product. The project is in the conceptualizing and definition stages. Our biz dev guy is driving the project. The problem is that one of the lead dev guys got involved and started negatively affecting the project. I could tell almost immediately that the project was going to quickly derail into a real messy battle of wills. What to do?

What I did

I put my foot down. In a series of email exchanges related to the project I tactfully made it clear that I felt strongly we were making the wrong choices. I was specific and provided alternatives, and why those alternatives had value. My boss has always told me that if you feel strongly about something, he wants to know. I knew this was an appropriate time for resistance.

I spent the weekend framing the problem for myself. For the better part of a weekend I wrote a series of notes, thoughts, streams of consciousness and mock email drafts. I didn’t intend to send any of them, they were purely for me to work through my emotions and clearly frame my issues in writing. At the end of that excersize I felt like I had a very clear strategy for dealing with the situation.

I wrote a small set of strengths and challenges. I basically made a mental model of the individual in question. This list gave me a strategy on how to best navigate the individual.

Strengths of the individual

Highly decisive and direct

Highly skilled at getting a group to get things done

Amazing depth of memorized knowledge

Highly skilled at logistics

No bullshit

Very experienced at what they do

Challenges and what to watch out for

Lacks critical diplomacy skills

Does not pick up on subtle social cues or doesn’t care

Passive Aggressive in communication

Lack of thoughtfulness in regards to people and processes

Has very low tolerance for the activity of thinking and discussing

Kryptonite to creativity

Not the kind of person who’s going to think about “why” we are doing something, only “how” we are gonna get ‘er done

Resulting strategy

The individual is going to be harmful and unhappy in phases of projects that require creativity, cooperation and exploration of ideas. Make sure to keep them out of these situations and focused on what they are good at, logistics and getting the final decision built.

Use their bluntness to my advantage, as an alert that maybe I am thinking too much and just need to act at that moment in time.

Learn from them about how to get things done faster personally and with a group

I stopped taking it personal. Once I had this strategy in hand I was then able to stop taking the individual’s actions personal and I stopped getting emotional about it. As the following week progressed I was able to clearly identify a behavior they exhibited and categorize it appropriately within my strategy.

And finally, I discussed my conclusions with my coworkers. I’ve learned the hard way that even when you’re right, others have to come to that conclusion on their own before they will embrace it, you can’t just tell them. I met with each person I felt needed to know what I had discovered and asked what they thought about what I’d concluded. Within days I saw the effect, they started seeing the individual’s actions more clearly and I felt that the potentially harmful situation was being managed.

Conclusion

I’m obviously leaving out a lot of detail here and over simplifying some things, but I hope I have been appropriately tactful and presented something useful. If you’d like to know more details please contact me directly.

Why I don't work on a Mac, for now

Wed, 03 Nov 2010 15:46:00 -0600

The chart above shows the operating systems my customers used in 2010 to date. As an Interaction Designer it’s my job to get inside the heads of my customers as much as possible. One way I get inside their heads is by forcing myself to use the same operating system as they do. I believe it gives me some additional insight into my users when I too have to deal with that annoying UAC crap in Windows (for example).

Granted I will let myself upgrade to the latest version of Windows, I’m not that hardcore to still use XP, but when XP was the latest version of Windows I used it for years. Even though Macs are far superior (I’m definitely not a Windows fan-boy), I believe it helps me become a better Interaction Designer by doing everything I can to understand and empathize with my customer’s needs and issues.

6 Months later, why I still prefer Illustrator to Fireworks

Mon, 01 Nov 2010 22:40:29 -0600

At my job I have to be the web designer, the print designer and the flash animator. So it’s easier for me to stay in the one drawing tool that makes the transition between those tasks easiest.

That doesn’t mean I’m poo-poo-ing Fireworks, I’m not. Fireworks is freakin’ awesome. It’s just not the best tool for my specific role at my company. But rest assured I spend time in Fireworks weekly so I’m ready for the day when I work at a company that has Fireworks as it’s primary work flow tool.

So until that day, here are the main reasons I still prefer Illustrator over Fireworks.

1. I’m always Flash ready. If I’m always in Illustrator then I’m always sharpening my vector drawing skills, which means I’m always ready to create artwork for Flash. Bitmaps do not work in Flash for the simple reason that they are HUGE in file size, let alone the fact that you lose all the transformation abilities of a vector image.

2. I’m always Printer ready. We all know bitmaps make horrible printing compared to vector illustrations. Besides that, who would ever work in 300 dpi when they are doing web design? Maybe the iPhone’s retina display will change this.

3. It’s the best damn 2D vector tool out there. People always tell me “But Fireworks does vector too!” That’s like saying WordPad lets you write term papers just like MS Word. Yea Fireworks does vector, but why would I purposefully hurt myself like that?

4. I’m just way f-ing fast in it. I spend time every week trying to make myself just as fast in Fireworks, but you can’t argue with the speed I can go in Illustrator. I’m definitely at that point where there is no delay between idea in my head to realized drawing in Illustrator. It will take years to get that fast in Fireworks.

Cartooning prepared me for interaction design

Mon, 25 Oct 2010 19:56:53 -0600

After repeatedly and methodically constructing comic strips on a monthly then a weekly deadline for years, I started to get the hang of it. I learned to write out a bunch of ideas to discover the best one. Then I learned to rough sketch the panels until I found the mix of drawings that told the joke best. And finally I would put on the polish with detailed ink and shading.

Interaction Design wasn’t too much of a leap after constructing strips for so long. Like comic strips, the best way for me to start designing an interaction is to first write it out. I write scripts that tell the story of the user performing the critical actions of the design. Then I follow up with sketches (wireframes) to find the right delivery and finally add the polish with ui and graphic design details.

3 UX Take-aways from John Sculley's interview about Steve Jobs

Mon, 18 Oct 2010 19:51:42 -0600

This week I read through the insightful John Sculley interview about Steve Jobs. I found the article very simple and yet very rich. Here are three things relating to designing products that I found most interesting.

1. Difference between Microsoft products and Apple products

Bill [Gates] was brillant too - but Bill was never interested in great taste. He was always interested in being able to dominate a market. he would put whatever he had out there to own that space. Steve [Jobs] would never do that.

2. Customer experience

He always looked at things from the perspective of what was the user’s experience going to be? … Apple wasn’t just about computers. It was about designing products and designing marketing and it was about positioning.

3. No focus groups

Steve said: ‘How can I possibly ask somebody what a graphics-based computer ought to be when they have no idea what a graphic based computer is? No one has ever seen one before.’

I don’t agree about no focus groups, though I do agree that focus groups aren’t for coming up with things that don’t exist. Focus groups are for generating mental maps that are helpful as you design.

Read the full article here

Google.com needs the web equivalent of an AppStore (concept sketch)

Mon, 11 Oct 2010 21:19:00 -0600

In my mind there are essentially two things on the web, information and applications. Google does an amazing job of organizing information, but as far as organizing all the web applications out there Google falls short.

This difference really hit home to me as I was watching what all those amazing SEO gurus do what they do. They are basically filling the web with amazingly organized and robust information. And that’s great if I’m seeking information, but what about actually doing stuff? All that great information is crowding out the apps in Google’s search results.

Since the web is a platform, just like the phone is a platform, where do I turn when I’m on the web and I want to find a web-based music application for example? Or see the top 25 paid and free applications in a given category? Today I ask my friends, or I wait for them to make a mention on Twitter or Facebook about an app they liked.

As of this writing there are two web app directories I know about AppUseful and Go2Web20. But the only reason I know about these two is because I found them as part of my job. For most everyone else in the world, if it’s not easy to find on Google it doesn’t exist.

Maybe my girlfriend, kids, parents and brother know they need to search Google for “listen to free music”, and maybe they don’t. But I do know they are pretty comfortable using the app stores on their phones.

I propose Google create a “web app” category of results. A web app category on google.com would help both web users and web app businesses in the same way app stores are helping mobile phone users and mobile app developers today. Developers would have a new additional channel to market in and users would have a directory for those of us who’d rather think in terms of a directory.

Beginnings of a UX handbook for my department

Mon, 04 Oct 2010 20:38:00 -0600

Last week I started a preliminary outline to answer to the question what is the UX department at my company responsible for. This is by no means comprehensive, it’s just a start.

1. Backlog grooming

Backlog grooming is just the Scrum way of saying make sure there is always a bunch of designs ready to go. My boss should never come to me and say he doesn’t know what to give the dev guys next sprint because there are no designs ready.

2. Continuous UI improvement on the site

This is the really tricky one at a small company like mine simply because at the executive level we never have the time and resources to do anything that doesn’t have a large ROI. I’m still developing a strategy for this, but for now it ends up being skunkworks projects in collaboration with the HTML guys.

3. Monitor and drive the A/B testing

This is where UX gets its monetary value. I finally realized that the only way I could sell usability improvements to my bosses was under the guise of A/B testing. Now they are anxious to try new things. Improvements inside our application are called conversion rate a/b tests, and improvements that get people to sign up are called trial-taker a/b tests.

4. Create, maintain and own the sitemap of the current site

Site-mapping a large app like ours always seemed too overwhelming and time consuming to be worth the effort. But I’ve since realized it helps managing the entire experience so much easier. I don’t build it all at once, that’d take too long, so day to day I add a little more until I have it all charted out. And now that I have it I don’t forget all the little pages that are out there on the site.

5. Get involved at the top and influence company direction

This one is still in development, but the way I’m accomplishing this is two-fold. First I get involved with as many executive planning meetings as I can. And second I spend time pouring over the same reports, stats and email discussions the executive team have so that I’m not only in the loop, but forming a mental model of how they think and why they make the decisions they do. At some point I’m going to be able to understand exactly where they are coming from and what they are trying to do, even if I don’t agree.

6. Never be invisible

The most important lesson I learned from the book Never Eat Alone was to never be invisible. I’ve also learned that executives love useful statistics and reports. So my goal now is to regularly deliver useful reports and statistics they wouldn’t normally have so that I’m never invisible and so that I’m adding value to what they do.

7. 20% time envisioning killer ideas for the company

After 4.5 years I quickly realized we are never going to do anything revolutionary unless I make it happen. And the easiest way to do this is to say screw it and spend about an hour every day working on some concept sketches of killer ideas for the company. Once people can actually see ideas drawn up then they start taking the ideas seriously and they start to kindle a desire of their own to pursue the ideas.

Seriously Apple, why isn't my iPhone a watch yet? (concept image included)

Mon, 27 Sep 2010 18:19:37 -0600

When Apple first announced those new Nano’s with the small square touch interface did anyone else think, my God that could easily be a watch?! I know it was just the Nano, but that could easily be the iPhone. I don’t know about you, but I get tired of having to pull my phone out of my pocket all the time. Wouldn’t it be so much nicer to just flick my wrist and see my latest text message or to answer a call? Let alone the fact I would be much less likely to misplace a watch or not feel the vibrating ringer because it’s in my pocket again.

The watch would have to look really nice though for me to be willing to wear it. I don’t want some gay looking 1980s calculator crap. But Apple could easily pull off wearable style with a partnership from Citizen, TAG Heuer or any other higher end watch company. I’m sure that when Chester Gould created the 2-Way Wrist Radio for his comic strip Dick Tracy he was thinking on some level about ease of use and practicality. All I can say is that brick of technology in my pocket is so last century :)

Here’s my quick concept sketch to inspire the Apple guys. I’m using the gorgeous Movado Men’s 605063 Sapphire Stainless Steel Watch as the watch piece.

Just sayin :)