Tagged: UI

UX Unicorns

I don’t mean to be offensive, but then again, whenever anyone says that phrase, something offensive to someone inevitably follows.  There is no such thing as a unicorn.  Nessy nor Bigfoot will be making an appearance; my condolences on this Earth shattering realization.  Quietly, sometimes loudly, we all determine what lingers in our library of wisdom and reality, agree or disagree, it is all good to me.  However, if you ask about a unicorn, or even worse for me to refer to you one, I’ll ask we part amicably with an agreement to disagree.  A UI designer/UI developer/UX researcher/UX analyst/Usability Specialist/HF Guru/Interaction Architect/Information Architect/Interaction Designer/etc., etc., simply doesn’t exist nor should this person be sought.  It’s lame, it’s selfish, it’s counterproductive!  What you’ll likely find at the end of this rabbit hole is a wasted set of candidates or frauds who look more like a horse with a rhino horn stitched on than that awesome unicorn from Legend.  I literally laugh out loud (or at least a modest chuckle) every time I come across a request for someone that can code…but also do UX ‘stuff’ or knows UX.  Are there people out there that can code well, keep users in mind as they design and/or perform research, I’m sure there are, but that isn’t the same as an Ace of all things UX!  If you’re on the hunter-side of this equation, please take a hard look at what you actually NEED.  If you are the prey-side, be very careful when answering this call…as you may find yourself in a position that isn’t fulfilling your short and long-term career goals or worse, a position for which you are not qualified.

Will this undoubtedly upset my peers, especially those that think they differentiate themselves as being this Unicorn?  Maybe, but I can’t with good conscious let this farce continue.  As I speak with recruiters and other individuals in industry looking to understand our already veiled field with polarized lenses, I find it responsible to be honest.  If you want someone with a particular set of skills (pardon the Taken reference), be specific and realistic!  There are generalists out there who can perform a variety of tasks, but remember you’re getting a generalist and likely won’t perform any of those tasks at an expert level.  If that is all you need, fantastic – you have done your homework and expectations are aligned.  However, don’t expect miracles.

Would you hire a person who built a career on painting cars to work on your brakes?

How about a plumber to fix your electrical issues?

Maybe a pastry chef to grill prime steaks at your restaurant?

Ahhh, the handyman!  They’re affordable, know how to do everything, and get the job done…what’s wrong with that?

My two cents (and one of my favorite bars in Key West), if you need a handyman (or woman), great…If you need an expert to drive your program to success, hire an expert or experts.  User Experience is already a muddied field made of bastards…ABSOLUTELY AMAZING AND TALENTED BASTARDS…but INDIVIDUALS who have often had to differntiate themselves from other roles more commonly misunderstood.  These roles, while often related and overlapping, do require unique skillsets and personalities.  You’ll likely have greater success with a project or program if you know exactly what you want.  Take the time, understand the role or roles you need and hire accordingly.  The same can be said for those who are seeking employment.  Just because you are a UI developer, you are not the same as a UI designer, etc.

If you’re a hiring manager, looking to enhance or start a UX practice at your company, recruiter, or anyone else that may find themselves asking what User Experience is and why should I even care…you’re not alone.  This practice has gained a fair amount of light in recent years, which is further complicating the understanding of the UX industry.  Traction, as a necessity for product development, is on the other end of slow telephone mired in a rotary republic.  We can’t afford to continue the ambiguity both in requests for personnel and seeking employment.

Am I saying there are people incapable of filling multiple roles with great success???  ABSOLUTELY NOT!  I’ve met many individuals who can transition in/out these roles like badass UX chameleons.  However, it should not be expected that this is the norm!  Just as there are many handymen out there that are better than specific plumbers or electricians, this should not be the expectation nor should you expect these people are easy to find (or cheap).

If you want someone to develop UIs using the latest and greatest technologies…hire a UI developer!

If you want someone to kick ass at designing a user interface…hire a UI Designer!

If you want someone to understand your users and all the crazy reasons why they’ll make or break you/your product, hire someone with an understanding of Human Factors!

If you want someone to ensure your designs meet the needs of your end users, hire someone experienced in Usability Testing!

Etc. Etc. Etc.

I would love to wake up tomorrow and not see UI developer roles married to Human Factors research roles.  They aren’t the same, stop asking for the same…I’d like to sleep well tonight!

Advertisements

Modern Browser Compatibility and UX

We are in the midst of a quagmire, and not the giggidy giggidy alright kind…I’ve recently been tossed into the fray of deciding how best to determine a browser strategy that will meet both the needs of existing customers as well as not prevent our organization from adopting modern Web technologies that don’t necessarily yield the best results in legacy browsers.  For example, if you’re writing Angular applications, I am hopeful none of your users are on IE 9 or less – yes, some people are still using OLD IE browsers!  What does UX have to do with a company’s browser compatibility strategy?  After all, this is a technology decision right?  In my opinion, we should definitely be a strong voice in the decision, but shouldn’t own it.  Ensure your stakeholders understand the impacts of the decisions being made so that any browser compatibility initiatives are aligned both with end-user needs and business expectations.

A few quick takeaways for those who are into the brevity thing:

1) Know your users as well as where you want/need to be now and a few years from now – don’t get too bogged down into the details of the analysis, the major gotchas will become evident quickly (basically, you don’t need to know the entire picture before taking action).  The needs of an E-commerce site could be very different from an Enterprise site or Business-to-Business Web application.

2) There isn’t a single, one-size fits all solution (as always) – a prescriptive approach is necessary but must be precise and will be determined be each organization’s situation.

3) Pick an approach that is doable in your environment (current product road-map allows for work required to implement change, funds are available and management is behind funding these changes, expertise is available for the desired technologies, and the organization is ready and willing for change!)

The details…

Take the time to understand your users and what is driving their current usage patterns.  The more empirical usage data the better you’ll be able to focus on which facts require in-depth research! However, the usage data cannot stand on its own, it is imperative to know the “why” behind the “what”.  Do you have tech-forward adoption with new technologies or are your users stuck on legacy operating systems with legacy browsers?  Are your users in the process to upgrading and you don’t know?  These are just a couple of questions that could impact strategy that wouldn’t be understood from the raw data alone – some legwork and talking to your users is necessary.

What is industry doing?  Quick searches to industry leaders and competitor’s products will yield enlightening and straight-forward directions; some may work for your situation, some could lead to disastrous results.  Either way, it’s a positive step to investigate what other teams are doing to understand a baseline goal of what you should achieve and how to communicate the message appropriately with your users.

Once a basic understanding of how your products are being utilized is complete, it’s a good time to revisit what the organization was hoping to accomplish via potential changes and determine the correct course for action.  With route A, will your organization be maximizing future potential without jeopardizing current relationships?  With route B, will your organization be too focused on current relationships that don’t provide enough revenue and risk profitable, future relationships for the sake of ‘now’?  There are number of variables and we could go on and on, you have to choose what makes sense for your organization’s goals.  I chose to focus on products and customers that provide the most revenue and strategic importance in balance with which products had the highest usage.  For example, you may want to evaluate all the squeaky wheels to see if more resources are being spent to appease them than they are worth…it can be shocking sometimes.  It makes sense to focus on business-driven decisions in conjunction with the usage data to come up with a strategy that is timely and most importantly DOABLE.

It’s ineffective to develop a strategy on which your organization is not prepared to execute!

Testing – The Potential of the Problem

One of the first steps that should be taken is to test your products to ascertain the current level of compatibility across the browsers/versions that will be supported.  This simple exercise can actually be complicated because it will likely require your testing teams to have or emulate multiple browsers and modes.  In traditional IE shops, this will likely mean training and potentially some technology purchases as well.  In addition to the technical/practical changes required to test across browsers, you’re taking the testing teams away from scheduled test schedules…which will have a variety of impacts on established product delivery dates.  It’s essential to note the UI features that are problematic across browsers.  This way, the adoption of those problematic elements in future design/development efforts can be weighed with their necessity, usability, and impact of extra dev/test time required to manage them.  One thing to note is Internet Explorer and the variations of compatibility in native, compatibility and enterprise modes when a user is running IE11.  If you care about supporting legacy applications in modern browsers, evaluating the various mode combinations in IE11 may be a valuable option.  However, you may find that most of the issues are viewing modern applications in legacy browsers, especially any UIs that are laden with JavaScript.

All Aboard

Now is a great time to start getting all the internal stakeholder teams on board with what has been discovered.  The earlier the better.  You don’t want to surprise your product teams with a “hey, we’re now supporting x, y, and z, you better get on the train, it’s left the station” sort of impression.  Top down support is essential.  Influence management is a positive approach.  However, you may not have the time it will take to be effective via influence alone, especially in an organization supporting many sets of products when you’re trying to achieve a single strategy.

One decision to weigh heavily is what an organization will do with legacy application while they are tossing older for emerging technologies.  Is this a UX problem?  Well, it is if you’re dealing with an experience that spans multiple products/pages/applications that utilize different technologies and have different experiences in different browsers.  If your organization is adopting responsive/adaptive UI development techniques you may be able to leverage those practices as another method to address a product set with varying compatibility.  Specifically around users who have older browsers. Supplying different fidelity UX in an adaptive model will provide your users a positive experience. Those with older browsers can get dished content in a less dynamic/flashy UI than those with modern browsers, all the while the business logic remains the same.  But then again, this requires a disciplined development team and an abstracted UI layer…all of which come with a higher price tag to implement.

Does your shop have the expertise to support the development changes that will be coming? Is training feasible, how bout outsourcing?  How does the potential to outsource impact morale?  How will utilizing a set of new tools/practices be received?  All questions to consider!

Unless your organization has unlimited resources, prioritize the changes accordingly.  It’s unrealistic to think you’ll be able to make the changes all at once across all products.  Utilize whichever decision method makes sense for you organization to identify a set of ‘first round’ products to test and schedule development accordingly.  Then follow-up with the lesser priority products until the compliance review and execution is complete.

Where’s the Beef?

Or cheese I guess it should be…Where’s the money?  The plan is on paper, people have bought in…but nothing is going to happen unless dollars are allocated.  Dollars get the training, the outsourced help, the time allocated, etc.  This isn’t last, this is first.  However, having a clear view of where products stand and how big the problem is can paint a picture management can understand and buy into, literally.

One more thing to consider.

The allure of new technologies is going to outpace adoption; it takes too much time to get resources up to speed compared to the rate at which they’re coming on to the scene. This problem is exacerbated the greater an organization’s product set becomes. Industry trends like are competing and these days they are less stable, even the ones that do win out.  Angular is doing well, but Angular 2 is coming, there a dozen others out there doing OK,  Polymer is showing promise, who knows what else in the near future?  Regardless, it isn’t effective to adopt every year, or maybe it is for your organization?  However, more than likely, it makes sense to evaluate annually and plan for the next 2-3 years on as few of technology choices as possible and know the impacts of technology choices on your cross-browser compatibility.

In Closing

Regardless of technology choice, make a plan to support modern Web standards (like HTML5/CSS3) rather than certain browsers – If necessary for your users, ensure you maintain backward compatibility to suit the those needs.  Having an abstracted UI layer will ensure your products can be upgraded as new technology choices are made.

Before starting your browser strategy, these steps may be helpful to keep in mind:

  • Understand your users
  • Test your products across browsers you plan to support, document the current state of compliance and determine problem design elements that should be avoided
  • Determine if your current certification meets your user’s needs, both current and future
  • Develop a prioritized approach that is in alignment with your user’s needs, involve internal stakeholders in the planning to achieve maximum buy-in
  • Ensure the plan is doable within your environment, set your organization up for success
  • Communicate the plan with your customers
  • Rinse and repeat!