• UX Design
  • Research
  • About
  • Blog
  • Contact
Menu

Rick Hines - Illustration

  • UX Design
  • Research
  • About
  • Blog
  • Contact
building-ux.png

Building a Healthy UX Culture

October 17, 2019

UX is all the rage. There’s a growing education infrastructure supporting fledgling UXers, and companies are competing for the best UX talent available.

The problem is that there’s still widespread ignorance about what UX is, and how it fits into a company’s culture or process. That’s the rub: People don’t realize that the culture itself has to change; The culture has to start with UX not the other way around. 

For example, most teams adhere to agile processes, but struggle with how to grudgingly include UX. Business operates from a place of urgency, they need to release something – anything within a sprint cycle. And UX will just slow them down and prevent them from shipping an iteration. This is the established culture. (I have strong feelings about how Agile is misinterpreted, too. Some other time…) The focus then shifts to the conflict of UX integration rather than working on the next iteration of the product. Teams struggle to figure it out while in the throes of a sprint cycle, wasting time and money. This also creates frustration, and friction between team members trying to navigate this integration.

This is why it’s so important for managers, and leaders to get more involved. They can bring a level of authority, and guidance to the process of establishing a healthy UX culture. The process should be inclusive, but leadership is instrumental in guiding and shaping it. It’s hard enough to ship deliverables in a sprint cycle without having to manage up or educate team members about the what and why of UX. Managers can use their influence to help establish a UX culture that is optimized for success.

We all have roles to play in how to successfully create healthy UX processes and cultures. But without the support of business, and leadership it’s much harder than it needs to be.

Here’s a great article about fitting UX into Agile.
https://blinkux.com/ideas/agile-ux-research

Comment
word.png

Words Matter

September 11, 2019

As UX professionals we all share a common vocabulary. We talk about users, flows, research, data… We also know that our goal is to find out what users need not what they like or want. Likes or wants are subjective, and many times don’t properly address the problems we’re trying to solve for users. We’re also burdened with the task of educating our clients about what UX is, and what value we bring to the process. So, it’s important that we communicate about what we do in ways that explain, and support the value we bring to the table.

On occasion I’ve had to bite my tongue after attending UX presentations that completely undermine our discipline. UX designers, and researchers using phrases like “users preferred” or “they liked.” What?! I’m used to hearing clients or other non-UX professionals use such terminology – but not my UX brothers and sisters. This is blasphemy! Say it ain’t so!

It’s bad enough when we use such blasphemous terminology within our own group, but when clients hear us use these words or phrases it sends the wrong message about what we do. In their minds our job is merely asking people what they like or don’t like. “Sheesh, I can do that,” say the unwashed non-UX civilians. And our jobs are tough enough without us shooting ourselves in the foot. Guilty as charged, I’ve done it, we’ve all done it.

Let’s make a pact! Let’s promise to be more mindful of the words we use when talking about UX, and when presenting work. Deal?!

1 Comment

the imitation game

September 14, 2016

Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.

This was prompted by an article by Owen Campbell-Moore over on Ev’s blog called Designing Great UIs for Progressive Web Apps. He begins with this advice:

Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.

This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.

With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:

PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.

See, when a developer has to implement a feature that the browser should be providing, that seems like a bad code smell to me. This is a problem that Opera is solving (and Google says it is solving, while meanwhile penalising developers who expose the URL to end users).

Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.

If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:

  1. Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
  2. Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
  3. App—sure, borrow what works from native apps if it makes sense for your situation.

Jason asks questions about how your progressive web app will behave when it’s added to the home screen. How much do you match the platform? How do you manage going chromeless? And the big one: what do users expect?

Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?

These are good questions and I share Jason’s hunch:

My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.

In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).

People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?

I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.

My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.

The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.

I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:

  1. Switch over to HTTPS if you aren’t already.
  2. Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.
  3. Make a manifest file to point to an icon and specify some colours.

See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.

I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.

 

1 Comment
Illustration: Rick Hines

Illustration: Rick Hines

UX is a Team Sport

June 2, 2016

The more I work in this field, the more I realize that UX is really a team sport. Especially when it comes to complex product development. There are just too many variables to consider for one person. And I welcome contributions from others; Usually someone's caught a use case I hadn't considered, an error state that wasn't represented or any number of useful insights another pair of eyes helped catch.

Ownership of the UX is shared by everyone who contributes directly and indirectly to the process. That said, yes, the UX person should be the "owner" of the process. But ultimately we all share in the ownership of UX, and that's a good thing. 

Comment

The Tiny Designer

June 1, 2016

Cool site about UX

Read More
1 Comment

My first blog experience...

June 1, 2016

Hi all,

I thought I'd add my voice to the rest regarding UX or any other topics you'd like to discuss. Let's do this!

1 Comment

Jared Spool

June 1, 2016

https://www.uie.com/about/

1 Comment

Latest & Greatest

Featured
Oct 17, 2019
Building a Healthy UX Culture
Oct 17, 2019
Oct 17, 2019
Sep 11, 2019
Words Matter
Sep 11, 2019
Sep 11, 2019
Sep 14, 2016
the imitation game
Sep 14, 2016
Sep 14, 2016
Jun 2, 2016
UX is a Team Sport
Jun 2, 2016
Jun 2, 2016
Jun 1, 2016
The Tiny Designer
Jun 1, 2016
Jun 1, 2016
Jun 1, 2016
My first blog experience...
Jun 1, 2016
Jun 1, 2016
Jun 1, 2016
Jared Spool
Jun 1, 2016
Jun 1, 2016

My opinions and rants...

Let's exchange ideas about UX design

 

I'm a UX Designer working in Seattle. UX has become popular these days, which is great! Let's discuss the topic and learn from one another.