Tech

Learn When to Say No.

Tom Henrich |

The one skill that’s been most helpful to me professionally, more than any tech knowledge, is knowing when and how to say “No.”

Obviously any profession has certain skillsets that are required for basic completion of the relevant tasks. Architects need to be able to sketch designs and understand building stress points. Firefighters need to know how to hook up hoses and where to aim the water for best coverage. I’m a front-end developer; I need to know how to write proper XHTML and CSS, use Photoshop, and manage project timelines.

Even so, none of the various technical abilities I’ve acquired over the years are as important as simply knowing when it’s necessary to say “no” to people. It’s a “soft skill” but it’s just as vital as any knowledge of coding languages, operating systems, or tech support tips. I’ve learned that saying “yes” all the time leads to nothing but stress and ultimately sub-par work. You end up trying to please all the people all the time, and it’s just not doable.

I think too many people have this idea that it’s unacceptable to say no (or worse, to hear it from others). There’s a fear that saying “no” will somehow make them look incapable of handling the work, make them look like they can’t be trusted to get stuff done. They’re half right, technically. There’s a point at which workload outweighs available time, and when that happens the work will suffer, the person will suffer, and the client will suffer.

No one wants that.

I’ve learned — the hard way — that my health (mental and physical) and my output are directly affected by my ability to regulate my workload effectively. Knowing when and more importantly how to tell people that you can’t currently oblige their request is absolutely critical to keeping yourself in balance.

I just wish more people understood that.

Tech

Notes from the September mkeUX meetup: Search

Tom Henrich |

Last night’s mkeUX was all about search – both SEO and paid search. Ross Monaghan and Jordon Meyer were great presenters and obviously have the background to back up their claims (and, after having a drink with the guys beforehand, not such bad guys in general). Twitter is a pretty good place to follow the action — search the hashtag #mkeUX — but I took some notes along the way, presented here for your amusement.

Ross Monaghan — “SEO & UX. WTF?”

Accessibility! There are already search engine optimization standards established by companies and groups like Google and the W3C. They’re designed to help you make sure your content is accessible. So… use them!

Search engines are essentially heavily disabled users. They have extremely limited ability to process Javascript, they can’t see your images, they won’t watch your Flash, and they won’t listen to your audio. If you don’t provide alternate means of consuming this content, it’s essentially invisible to search. The same goes for things that require user interaction – dropdown forms, etc. Search engines won’t jump through the hoops that human users may be willing to tolerate.

Keep it clean!

Keeping your URLs clean and human-friendly, and making good use of canonical URLs, will go a long way toward improving your search engine performance. Excessive use of querystring parameters, or extensive tagging without proper compensating techniques like using robots.txt to exclude “tag overview” pages, will inevitably start to dilute the value of the other links throughout your site. So be careful how you implement those “features.”

If I can read your page and immediately tell you what keywords you’re targeting, you’re doing it wrong.

Architecture. Sometimes you have to take a step back and ask yourself (or your client), “Why the hell are we building this website to begin with?” If there’s no clear answer, STOP. If there is a clear answer, then… great! Now what? You need to ensure a consistent and reliable strategy — taxonomies, structure, labeling, and organizational themes.

Jordon Meyer — “Paid Search Usability”

Paid search gets a bad rap.

— Jordan

In 2009, Google got $23 billion in revenue selling paid search ads and had 37 billion clicks on those ads. However, only around 2% of those clicks ever turned into an actual conversion. 98% of the ads ended up meaning absolutely nothing. Why? (Possible answer: people just distrust paid search results?)

Five opportunities to lose customers:

  • Irrelevant keywords – buying every conceivable keyword just in hopes of getting someone to click? Bad!
  • Misleading copy – “office chairs under $50!” when none of your office chairs are under $100
  • Generic keywords
  • Poor choice of destination – don’t send every click to your homepage! Take into account what the user is searching for, why they clicked, and where they expect to land.
  • Low quality of destination – if you have no calls to action, too much (or not enough) copy, high load times, etc… people will leave. And they may not come back.

You got the click to your site, now do something with it! Standards exist and evolve for a reason. Use them to your advantage.

Tech

Twitter Bio Generator

Tom Henrich |

Agonizing over what to put in your Twitter bio? 140 characters in which to describe your endless intricacies and greatest feats to the world – that’s a tall order. Luckily for you there’s a service to do all the hard work for you. Introducing the Twitter Bio Generator from @joshjs. Maybe you’re a…

Twitter afficionado. Amateur tv nerd. Passionate travel fan. Music maven. Bacon geek.

No? How about…

Pop culture guru. Tv scholar. Award-winning zombie fan. Alcohol maven. Internet fanatic.

See? Easy peasy lemon squeezy. Enjoy.

Photo by West McGowan. cc

Tech

Notes from the August MKE UX Meetup: Sketching

Tom Henrich |

Last night was the August edition of #mkeUX, and just as its previous iterations it was a great time. This month’s topic was sketching and how such a relatively simple act can provide enormous benefits to the UX process.

Mike Rohde and Cyndi Thomas were the presenters for the evening, though really in a setting like mkeUX, everyone is a presenter in some way. As expected, both of them know their material and were well prepared to discuss it at length (and there was no shortage of audience questions & comments, some of which made their way to Twitter). But without further ado… some quickly jotted down notes from the evening.

Why should you embrace sketching?

It’s a great tool that makes it safe to fail.

A common hangup is the sentiment that “I can’t draw!” but this isn’t really the point. Regardless of your “drawing” ability, you can’t do it wrong! Sketching is not drawing — sketching is thinking, just in a more visual form.

sketching != drawing

sketching = thinking

— @deziner

Sketching helps you break through the limitations inherent with spoken language and accelerate the process of brainstorming, without necessarily committing too much detail to quibble over. Hi-fidelity wireframes tend to have a “finished” vibe to them that often leads to mis-directed discussions on the insignificant details, rather than focusing on the big picture. The informal nature of sketches can lower that barrier.

Why sketch?

Sketching helps quickly move ideas from the inaccessible reaches of your brain to a visible, tangible something that others can react to. You can’t have a discussion with others around something that’s only in your head.

Sketching forces you to take the idea and break it down into its elemental components, which you can then re-arrange as needed rather than getting lost on the big picture only.

Sketching is extremely quick and easy to do, which allows for far more rapid iterations of ideas and approaches so that you can quickly find your way to the best one. This sort of rapid iteration isn’t so easy to do in formalized tools. The key is volume. You want to get as many ideas down as you can – try everything.

You can also use sketching to get immediate feedback from clients/stakeholders. A great tactic can be to quickly get a sketch on paper, then slide that paper over to them and simply hand them the marker. “Here, show me your ideas on this.” People love to draw, whether they’re good at it or not, and it’s a form of play. People don’t get to play as often as they’d like, and this becomes a great way to give them more direct input and make them feel more involved (or at least give them the much-needed illusion of being more involved).

Cyndi suggested that you set a goal for yourself of x number of ideas to generate, and don’t stop until you hit that mark. Yes, some of the ideas will suck. Some will come easier than others. But if you don’t set that goal, you’ll just stop after the first couple that easily come to mind, and those aren’t necessarily going to be the best ones. Forcing yourself to churn out more will force you to reconsider everything and come up with new possibilities.

Remember: it doesn’t have to look good!

Wrap-up

The take-away was pretty clear. Sketching can be an amazingly useful technique if you spend any time at all coming up with concepts, wireframes, or mockups of any sort to share with clients and stakeholders. The speed and informality inherent in sketching helps to reduce barriers and focus the conversation on what’s best, rather than getting caught up in nit-picky details. And even if you “can’t draw,” you can still sketch. So try it!

As always, a huge thanks to the mkeUX organizers, Michael Seidel and Mike Kornacki, as well as to the Bay View Brew Haus for hosting. I’m already looking forward to the September mkeUX meetup, September 28 at 7PM (usually goes until 9PM), at Irish Pub (I presume the one downtown on Wisconsin Ave.) – if I heard correctly the topic will be search (it’s like they’re reading my mind for topics of interest!).

Be there!

Tech

Notes from the July MKE UX meetup: Mobile UX

Tom Henrich |

The July 11 mkeUX meetup was amazing. The back room of Sugar Maple was absolutely packed with people evidently interested in mobile UX, the topic du jour. (See photos from the event by Michael Seidel on Flickr.) The two presenters were obviously well-qualified and well-prepared, and the discussion amongst the group was always intriguing. Clearly these people know their stuff, and are passionate about it. Even the backchannel chatter was on topic. (Hint: follow the #mkeUX hashtag for ongoing discussions.)

I remembered to take along a notepad and a writing implement to save some of the discussion for posterity:

Andy Wright on the intimacy of mobile

Connectivity. The availability of tools like Skype for conversations over 3G is replacing the need for traditional phones. You don’t need minutes anymore, you just need a data package. The same goes for Facebook, etc. Potential problems come around when you lose signal… what happens when your device is offline?

Context. It comes down to the right things in the right places. Mobile is intimately personal as a platform – your phone is almost always with you, and your interactions with and through it are bound to be personal. What do users actually do with their phones? (There’s a claim that over 60% of the time, it’s just checking the time!)
You need to investigate what your users/customers are actually doing before you do anything new – it’s not worth your time to create or try to sell them something they have no interest in.
Foursquare may be the ultimate in context-aware applications – it’s intended to tie in with your physical context.

The growth of mobile search is extraordinary, especially when you consider someone’s location relative to their search query. Are they looking for nearby food, entertainment venues…? The next trend in mobile search is likely to be some strain of predictive search – based on where you are, can search predict what you’re trying to find?

Location. Knowing where your users are is a huge advantage, since you can immediately tailor the experience for them. Apps should just know this information automatically; as a user, I shouldn’t have to tell the app (but I should still have the option if needed). This is especially true since you may not always know where you actually are. If I’m in Poughkeepsie, I don’t have the slightest clue what the ZIP code there is – I should be able to let my phone access GPS and fill that information in for me, or have some way of entering a human-readable search.

Continuity. Mobile usage is inherently plagued by partial attention and constant interruptions. I’m out and about, I’m checking my email, then I get a call or a text, or some notification that pulls my attention away from whatever I was doing. This can be overcome by syncing across platforms; the e-book market is becoming a great example. The Kindle can automatically sync, to the word, your progress through a book on every platform – your Kindle, your computer, and your phone.

Accessibility. This concept is completely changing in the mobile space. It’s an entirely new paradigm with entirely new interactions to consider. Touch, accelerometers, voice control, etc. It’s not just pushing buttons anymore.

Speed. This is absolutely essential for any mobile apps or sites. Users need to have an immediately responsive experience. People are focused on this, then that, then this, and they can’t sit and wait through long response times.
Also, don’t over-burden users with options. Simplicity is better – don’t make me think about how to do something, just let me do it.

Scalability. Optimize for more than just one particular situation, platform and user type. Not everyone has an iPhone, not everyone has a Droid. Make sure your solution will work for as many of your users as possible.

Simplicity. It’s hard to make complex things look simple, but it’s absolutely critical to do so. Prototype early and iterate often. Using is greater than thinking. Don’t worry about the design too early in the process; focus on functionality, and then make it pretty.

Mike Massie on the idea-to-production flow

When trying to produce something that will eventually be consumed by users, you have to become a user yourself. If it pisses you off, it’ll piss others off too. So think!

Be like electricity – follow the path of least resistance. Simplicity is king sometimes. Don’t overload your product with features; you have to consider things like battery life, task complexity, limitations of the hardware and software of the platform, etc. Don’t just assume what users want.

(Somewhere in the middle of all this the room spun into a tangential discussion of who calls themselves a developer versus a programmer, and what the difference between the roles is. I think it ended up with a relative consensus that developers tend to have a broader view of a project and wider responsibilities, while programmers are generally just code-writers. For the record, I consider myself a developer.)

Don’t bother users with tasks they don’t care about, but balance simplicity with utility. Give them options when it makes sense, but make your product just do the rest automatically. (But don’t just assume that because you do something everyone else will. You are not everyone else. Everyone has their own needs and particular use cases.)