It’s Users All The Way Down

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

  1. handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
  2. sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
  3. maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Notes from GiantConf 2014′s “Embracing the Suck” presentation by Chris Harrison

In his presentation on day one of GiantConf 2014, Chris Harrison talked to us about “Embracing the Suck”. Here are my notes from his talk.

Chris Harrison – Embracing the Suck – 10:45a Thursday, June 12

@cdharrison
cdharrison.com

Embracing the Suck: Military phrase meaning to make the best of whatever situation you’re in..

Background:
– Weight loss – 529 to 377
– weight gain due to being depressed, hating what he did, etc.
– Making sites since 1996.
– Former fulltime freelancer
– now: frontend dev for Morris Communications (magazine division)

2013 state of the workplace
30% engaged and inspired
18% actively Disengaged – sabotage their coworkers (cost 450-550 million a year)
52% permanent case of the mondays – do just enough not to get fired

Sometimes you just gotta suck it up.
– Consider the alternative – it could be worse.

– dan willis, “great takes work”
– choose your battles and spend your energy wisely

Negativity is a cancer! (this could be a talk topic!)

Sometimes complaining takes more effort than just getting things done.

Don’t fear new. New = opportunity. (he was told he’d be doing all joomla and drupal work. This was not happy news)
– learn on the companie’s dime
– doubtful he could have learned this stuff as a freelancer (no time/money in it)

Everything you do is a learning process for everything.

– thomas edison’s quote about opportunity and how it looks like work.
– fabio at mailchimp, lead html email designer. was hired to do ui/ux, but they approached him to do HTML emails.
– we know as an industry that html emails suck.
– when he heard this, he embraced the challenge.
– 5 years later he’s an innovator in a field where it was thought there was no room for innovation left.

Opportunity opens doors…

Help your team…
– concept of jumping on hand grenades (someday you’ll need help from the person you help today)

Small wins are still wins. (make it something awesome despite the scope)

Make learning a priority
– learning about sass etc and givng talks about it.
– things suck less when you share what you know with your coworkers
– codeschool etc. as good options for continued learning.

“Sneak” new technology/techniques into projects, but strive to get buy-in from your coworkers (if not management)
– Demonstrate the benefits of incorporating these new techs into an existing workflow

Find creative outlets
– draw more.
– starting doing illustrator avatars for friends
– take pictures! (vader, ninja turtles)
– lilvaderadventures tubmler

Scratch your own itch – side projects rock
– itembrowser.com – his first responsive project
– learned media queries, etc.

Start using your powers for good
– jingle jam (10k) benefiting safeHOMES charity
– design + development + marketing
– someone could really use your talents!

Happiness depends on ourselves – aristotle
Even sucky work can make you happy. Give it a chance.