Feb
08

Getting Specific on Soft Skills for UX Professionals

Source: UXMatters

By Baruch Sachs

Published: February 8, 2016

“The majority of what we do in the business world is essentially improvisation. Despite all the time we spend doing strategic planning for our work, we still end up having to improvise because of changing environments….”

My last column received tremendous feedback with regard to the importance of soft skills in the profession of User Experience. One consistent theme was the desire for me to get more specific about the types of soft skills that are often lacking in UX professional’s interactions. To answer this request, I will touch upon the following five soft skills in this column:

  1. adaptability
  2. communication
  3. conflict resolution
  4. argumentation and negotiation
  5. gravitas mixed with social grace

Getting Specific on Soft Skills for UX Professionals

Feb
08

How to Create a Globally Appealing User Experience

Source: UXMatters

By Ania Rodriguez

Published: February 8, 2016

“Human needs that are based on cultural tendencies are the factors that come into play when your goal is to design a globally appealing user experience.”

If you’re designing a product you want to sell globally, assuming every consumer across the world has the same needs and expectations won’t get you far. Knowing and understanding what makes people different is what will determine your success.

Psychologist Abraham Maslow studied human needs throughout his career and social psychologists such as Geert Hofstede continue to research this topic today. (Dirk Knemeyer wrote a three-part series for UXmatters titled, “Applied Empathy: A Design Framework for Meeting Human Needs and Desires.”)
How to Create a Globally Appealing User Experience

Feb
08

Information Architecture in Review, Part 1

Source: UXMatters

By Nathaniel Davis

Published: February 8, 2016

“We’ve seen some new books on information architecture hit the market in the last few years.”

Information architecture is not the easiest topic to write about. So, when a book comes out on the subject, we know that’s a rare event. Nevertheless, we’ve seen some new books on information architecture hit the market in the last few years. Arguably, this trend began in 2011 with the publication of Pervasive Information Architecture: Designing Cross-Channel User Experiences, by Andrea Resmini and Luca Rosati. More on that book in a future review.

In this review, I’ll highlight Abby Covert’s and Andrew Hinton’s latest works. Both are veteran practitioners of information architecture and well-known contributors to the field’s body of knowledge.
Information Architecture in Review, Part 1

Feb
08

Robots Do It Better: Why Users Love Self-Service Technologies

Source: UXMatters

By Keith Smith

Published: February 8, 2016

“Customers are increasingly opting for self-service. … Customers may want what you’re selling, but they don’t want you to force them to go through a human to get it.”

Let’s face it. While the Internet was designed to make us more connected, it’s also making it easier for us to avoid one another. Just think about that for a moment. Yes, you can reach out and communicate with people in the most distant corners of the Earth, but at the same time, there is nothing more irksome than receiving an actual phone call when an email message would have sufficed.

For example, there’s been a shift in hiring practices. Remember when you were supposed to pound the pavement, handing out a stack of resumes and letting people see your face? Today, no HR manager in the world wants you showing up at his or her door. Even if you did, they would just tell you to go online and fill out a form or submit your resume via email.
Robots Do It Better: Why Users Love Self-Service Technologies

Feb
08

Validating Product Ideas Through Lean User Research

Source: UXMatters

By Tomer Sharon

Published: February 8, 2016

This is a sample chapter from Tomer Sharon’s new book Validating Product Ideas Through Lean User Research. 2016 Rosenfeld Media.

Chapter 5: Do People Want the Product?

Mmm…” I thought to myself as I was reading Nate Bolt’s Facebook post about the Automatic app (see Figure 5.1). “A smart driving assistant? One that hooks up to my car’s computer and sends data to an iPhone app that will help me save energy and money? I want that!” (See Figure 5.2.)

I ordered an Automatic two minutes after I saw that post. It cost me $70. At the time, the product wasn’t shipping yet, and I was paying to participate in a beta that was going to start in a few months. Usually, I’m extremely skeptical about such things. But this was different. I really wanted that thing. I thought the idea was brilliant, and I was 100% positive that I would use and love it. The beautiful, smooth Automatic Web site and purchasing workflow reassured me that I could trust my instincts. When the Automatic package arrived at my doorstep a few months later, I was happy. Unboxing it was very “Apple-like,” and onboarding was great. I hooked the Automatic car adapter to my car (somewhere under the steering wheel where I was able to find the data port quickly), installed the app, and made sure it worked when I drove the car.
Validating Product Ideas Through Lean User Research

Feb
02

This week’s sponsor: Hired

Source: A List Apart

Get 5+ job offers with 1 application from companies like Uber, Square, and Facebook—plus a $1000 bonus when you get a job—with our sponsor Hired. Join today.


Read the full article

Feb
02

The Art of the Commit

Source: A List Apart

A note from the editors: We’re pleased to share an excerpt from Chapter 5 of David Demaree’s new book, Git for Humans, available now from A Book Apart.

Git and tools like GitHub offer many ways to view what has changed in a commit. But a well-crafted commit message can save you from having to use those tools by neatly (and succinctly) summarizing what has changed.

The log message is arguably the most important part of a commit, because it’s the only place that captures not only what was changed, but why.

What goes into a good message? First, it needs to be short, and not just because brevity is the soul of wit. Most of the time, you’ll be viewing commit messages in the context of Git’s commit log, where there’s often not a lot of space to display text.

Think of the commit log as a newsfeed for your project, in which the log message is the headline for each commit. Have you ever skimmed the headlines in a newspaper (or, for a more current example, BuzzFeed) and come away thinking you’d gotten a summary of what was happening in the world? A good headline doesn’t have to tell the whole story, but it should tell you enough to know what the story is about before you read it.

If you’re working by yourself, or closely with one or two collaborators, the log may seem interesting just for historical purposes, because you would have been there for most of the commits. But in Git repositories with a lot of collaborators, the commit log can be more valuable as a way of knowing what happened when you weren’t looking.

Commit messages can, strictly speaking, span multiple lines, and can be as long or as detailed as you want. Git doesn’t place any hard limit on what goes into a commit message, and in fact, if a given commit does call for additional context, you can add additional paragraphs to a message, like so:


Updated Ruby on Rails version because security

Bumped Rails version to 3.2.11 to fix JSON security bug. 
See also http://weblog.rubyonrails.org/2013/1/8/Rails-3-2-11-3-1-10-3-0-19-and-2-3-15-have-been-released/

Note that although this message contains a lot more context than just one line, the first line is important because only the first line will be shown in the log:


commit f0c8f185e677026f0832a9c13ab72322773ad9cf
Author: David Demaree 
Date:   Sat Jan 3 15:49:03 2013 -0500

Updated Ruby on Rails version because security

Like a good headline, the first line here summarizes the reason for the commit; the rest of the message goes into more detail.

Writing commit messages in your favorite text editor

Although the examples in this book all have you type your message inline, using the --message or -m argument to git commit, you may be more comfortable writing in your preferred text editor. Git integrates nicely with many popular editors, both on the command line (e.g., Vim, Emacs) or more modern, graphical apps like Atom, Sublime Text, or TextMate. With an editor configured, you can omit the --message flag and Git will hand off a draft commit message to that other program for authoring. When you’re done, you can usually just close the window and Git will automatically pick up the message you entered.

To take advantage of this sweet integration, first you’ll need to configure Git to use your editor (specifically, your editor’s command-line program, if it has one). Here, I’m telling Git to hand off commit messages to Atom:


$: git config --global core.editor "atom --wait"

Every text editor has a slightly different set of arguments or options to pass in to integrate nicely with Git. (As you can see here, we had to pass the --wait option to Atom to get it to work.) GitHub’s help documentation has a good, brief guide to setting up several popular editors.

Elements of commit message style

There are few hard rules for crafting effective commit messages—just lots of guidelines and good practices, which, if you were to try to follow all of them all of the time, would quickly tie your mind in knots.

To ease the way, here are a few guidelines I’d recommend always following.

Be useful

The purpose of a commit message is to summarize a change. But the purpose of summarizing a change is to help you and your team understand what is going on in your project. The information you put into a message, therefore, should be valuable and useful to the people who will read it.

As fun as it is to use the commit message space for cursing—at a bug, or Git, or your own clumsiness—avoid editorializing. Avoid the temptation to write a commit message like “Aaaaahhh stupid bugs.” Instead, take a deep breath, grab a coffee or some herbal tea or do whatever you need to do to clear your head. Then write a message that describes what changed in the commit, as clearly and succinctly as you can.

In addition to a short, clear description, when a commit is relevant to some piece of information in another system—for instance, if it fixes a bug logged in your bug tracker—it’s also common to include the issue or bug number, like so:


Replace jQuery onReady listener with plain JS; fixes #1357

Some bug trackers (including the one built into every GitHub project) can even be hooked into Git so that commit messages like this one will automatically mark the bug numbered 1357 as done as soon as the commit with this message is merged into master.

Be detailed (enough)

As a recovering software engineer, I understand the temptation to fill the commit message—and emails, and status reports, and stand-up meetings—with nerdy details. I love nerdy details. However, while some details are important for understanding a change, there’s almost always a more general reason for a change that can be explained more succinctly. Besides, there’s often not enough room to list every single detail about a change and still yield a commit log that’s easy to scan in a Terminal window. Finding simpler ways to describe something doesn’t just make the changes you’ve made more comprehensible to your teammates; it’s also a great way to save space.

A good rule of thumb is to keep the “subject” portion of your commit messages to one line, or about 70 characters. If there are important details worth including in the message, but that don’t need to be in the subject line, remember you can still include them as a separate paragraph.

Be consistent

However you and your colleagues decide to write commit messages, your commit log will be more valuable if you all try to follow a similar set of rules. Commit messages are too short to require an elaborate style guide, but having a conversation to establish some conventions, or making a short wiki page with some examples of particularly good (or bad) commit messages, will help things run more smoothly.

Use the active voice

The commit log isn’t a list of static things; it’s a list of changes. It’s a list of actions you (or someone) have taken that have resulted in versions of your work. Although it may be tempting to use a commit message to label a version of the work—“Version 1.0,” “Jan 24th deliverable”—there are other, better ways of doing that. Besides, it’s all too easy to end up in an embarrassing situation like this:


# Making the last homepage update before releasing the new site
$: git commit -m "Version 1.0"


# Ten minutes later, after discovering a typo in your CSS
$: git commit -m "Version 1.0 (really)"


# Forty minutes later, after discovering another typo
$: git commit -m "Version 1.0 (oh FFS)"

Describing changes is not only the most correct format for a commit message, but it’s also one of the easiest rules to stick to. Rather than concern yourself with abstract questions like whether a given commit is the release version of a thing, you can focus on a much simpler story: I just did a thing, and this is the thing I just did.

Those “Version 1.0” commits, therefore, could be described much more simply and accurately:


$: git commit -m "Update homepage for launch"
$: git commit -m "Fix typo in screen.scss"
$: git commit -m "Fix misspelled name on about page"

I also recommend picking a tense and sticking with it, for consistency’s sake. I tend to use the imperative present tense to describe commits: Fix misspelled name on About page rather than fixed or fixing. There’s nothing wrong with fixed or fixing, except that they’re slightly longer. If another style works better for you or your team, go for it—just try to go for it consistently.

What happens if your commit message style isn’t consistent? Your Git repo will collapse into itself and all of your work will be ruined. Kidding! People are fallible, lapses will happen, and a little bit of nonsense in your logs is inevitable. Note, though, that following style rules like these gets easier the more practice you get. Aim to write the best commit messages you can, and your logs will be better and more valuable for it.


Read the full article

Jan
27

The High Price of Free

Source: A List Apart

Doing business in the web industry has unbelievably low start-up and fixed running costs. You need little more than a computer and an internet connection. The overheads of freelancers and small agencies that build websites and applications for other people, or develop a digital product, are tiny in comparison to a traditional business. Your training can be free, as so many industry experts write and teach and share this information without charging for it. Even the tools you use to build websites can be downloaded free of charge, or purchased for very little.

As an industry we have become accustomed to getting hundreds of hours of work, and the benefit of years of hard-won knowledge for free.

My free time in the last couple of years has been put into looking at the Grid Layout spec. I start most days answering emailed questions about the examples I’ve posted, before I get down to the work that pays the bills.

I’m not unusual in that. Most of my friends in the industry have tales of invites to events where no payment is offered, a queue of issues raised on their personal project on GitHub, or people requesting general web development technical support via email.

What pays the bills for me, and enables me to spend my spare time doing unpaid work, is my product Perch. Yet we launched Perch to complaints that it wasn’t open source. There are very good reasons why someone might want, or be required, to use software that has an open source license. However, when we ask about it, people rarely cite these reasons. When they say open source, they mean free of charge.

I’ll be 41 this year. I don’t feel 41, but the reality is that at some point I won’t be able to keep up a pace of work that encompasses running a business, putting together talks and workshops, writing books, and contributing as much as possible to the industry that I love being a part of. I need to make sure that I am building not only a body of work and contributions that I’m proud of, but also financial security for when I can’t do this anymore. Yes, that free work does sometimes result in someone trying my software or offering me paid consultancy, but not as often as you might think. Despite having very marketable skills, I don’t own a home, much less have a pension and savings in place.

I wondered how other independent and freelance web workers dealt with this conflict between earning money and contributing back. I also wondered if I was alone in feeling that the clock is ticking. I put together a survey (the responses to which probably will be the background to several other pieces of research), and a few things stood out immediately.

Of the 211 people who responded and said they worked for themselves, 33% said they had some provision but not enough to fully retire, while 39% said they had no pension or retirement savings at all. In fact, 30% of the 211 said that they live pretty much “month to month” without so much as a contingency fund. Even filtering out the under-40 age groups, those percentages remained roughly the same.

I asked the question, “Are you involved in open source projects, writing tutorials, mentoring, speaking at events-that you do free of charge or for expenses only?” 59% said they were not involved, with 27% of those people citing time constraints. Some people did explain that they were involved in volunteer work outside of the web. By the time I filtered out the under-40s, the non-involvement figure rose to 70%.

We know that not paying speakers and not covering speaker expenses causes events to become less diverse. The ability to give time, energy and professional skills free of charge is a privilege. It is a privilege that not everyone has to begin with, but that we can also lose as our responsibilities increase or as we start to lose the youthful ability to pull all-nighters. Perhaps we begin to realize how much that free work is taking us away from our families, friends, and hobbies; away from work that might improve our situation and enable us to save for the future.

If you are in your early twenties, willing to work all night for the love of this industry, and have few pressing expenses, then building up your professional reputation on open source projects and sharing your ideas is a great thing to do. It’s how we all got started, how I and the majority of my peers found our voices. As I get older, however, I have started to feel the pressure of the finite amount of time we all have. I’ve started to see people of my generation taking a step back. I’ve seen people leave the industry, temporarily or permanently, due to burnout. Others disappear into companies, often in managerial (rather than hands-on) roles that leave limited time for giving back to the community.

Some take on job roles that enable them to continue to be a contributing part of the community. The fact that so many companies essentially pay people to travel around and talk about the web or to work on standards is a great thing. Yet, I believe independent voices are important too. I believe that independent software is important. For example, I would love to see more people who are not tied to a big company be able to contribute to the standards process. I endorse that, yet know that in doing so I am also advocating that people give themselves another unpaid job to do.

The enthusiasm of newcomers to the industry is something I value. I sit in conference audiences and have my mind changed and my eyes opened by speakers who are often not much older than my daughter. However, there is also value in experience. When experience can work alongside fresh ideas, I believe that is where some of the best things happen.

Do we want our future to be dictated by big companies, with independent input coming only from those young or privileged enough to be able to work some of the time without payment? Do we want our brightest minds to become burned out, leaving the industry or heading into jobs where the best scenario is contribution under their terms of employment? Do we want to see more fundraisers for living or medical expenses from people who have spent their lives making it possible for us to do the work that we do? I don’t believe these are things that anyone wants. When we gripe about paying for something or put pressure on a sole project maintainer to quickly fix an issue, we’re thinking only about our own need to get things done. But in doing so we are devaluing the work of all of us, of our industry as a whole. We risk turning one of the greatest assets of our community into the reason we lose the very people who have given the most.


Read the full article

Jan
25

The Purpose of Site Maps and Other Design Deliverables

Source: UXMatters

By Janet M. Six

Published: January 25, 2016

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our expert panel discusses the purpose of site maps. Web site design has come a long way since designers slapped a Site Map link at the bottom of every Web page to help users who were perplexed by a Web site’s organization—or has it? Sometimes yes, sometimes no. Our experts cover exactly what constitutes a site map and how site maps differ from other UX design deliverables. They also consider the evolution of the term site map over the years, how site maps apply to increasingly responsive Web designs, and how agile development has impacted the use of site maps.

Every month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: ask.uxmatters@uxmatters.com.
The Purpose of Site Maps and Other Design Deliverables

Jan
25

The Crucial Role Deep Linking Should Play in Your Mobile App

Source: UXMatters

By Bobby Emamian

Published: January 25, 2016

“While most Web-site creators have mastered the art of effective hyperlinking, the mobile community has yet to catch on fully. Sure, many apps feature hyperlinks—but they’re not deep links.”

Hyperlinks exist everywhere on the Web—in articles, email messages, social-media posts, you name it. In theory, they should provide one-click access for those who seek additional information. But every now and then, users encounter a link that leads only to a Web site’s landing page, an app’s home screen, or completely unrelated content—basically, nowhere useful.

While most Web-site creators have mastered the art of effective hyperlinking, the mobile community has yet to catch on fully. Sure, many apps feature hyperlinks—but they’re not deep links.

Deep links provide direct access to specific content. While generic links might go to a Web site’s homepage—for example, http://www.website.com—deep links send users straight to a particular page or section within that site—for example, http://www.website.com/page/section/.
The Crucial Role Deep Linking Should Play in Your Mobile App

Older posts «