Representative Users – Pitfalls, Alligators and Gold

End user knowledge is the linchpin of product design.  Incorporate that knowledge, you’ll more than likely you have a better chance of usability, adoption, and overall success.  Sideline end user knowledge, you’ll almost certainly enter a world of pain from where Walter Sobchak would not even want to enter.  So, what are we to do when we know we need this knowledge, but don’t have the resources…is there a compromise?  In the harsh realistic world, void of unicorns (UX or other) and leprechauns, there will always be a time when we must rely on representative users to help us make semi-informed decisions.

Relying on representative users (RUs) can be beneficial; I’m not saying the knowledge and advice gleaned from their experience isn’t valuable.  However, this approach of using their input as the sole source of end user knowledge will come with risks and these risks should be recognized/accepted early on by all stakeholders (especially those directly responsible for the product).  Representative user input can never replace the value/knowledge gained from even minimal end user interaction.  One of the most significant pitfalls of relying on RUs is you are basing design decisions on someone’s experience; this experience may be vast or may be minimal.  Or worse, the alligators of this metaphor, your RU may be misinformed.  More often than not, the people you’re working with are not trained observers or researchers; they’re business/ marketing people who perceive products and users from a completely different perspective.  Varied perspective is a positive input into our process, we need that multifaceted view to balance the overall approach and achieve a compromise that produces a usable product that is cost-effective and marketable.  However, we need to know the RU observational perspective can be a contributor to risk just as much as reward!

So then…how do we gauge the level of knowledge and trust our RUs are providing useful input?  Before any project, the team should have a basic understanding of the target audience. If you don’t know the answers and your RU cannot address the following basic questions, in my opinion, you’re off to a world of pain.  This is not an exhaustive list, more a litmus test – please share other questions that you find useful:

  • Who are the target users of this solution? How many are there, how different are they across environments/locales, what specifically are their roles, the types of tasks they perform, frequency of those tasks?
  • Are there special needs of users in the population?
  • What is the defined business problem being solved by the proposed product or enhancement, why is this important to the target users and/or business?
  • What are the primary use cases that will be driving the product/enhancement?
  • How do users commonly interact with the product (desktop, mobile, laptop, etc.)?

Now that you’ve got these questions answered – Document and share with the team!  During design discussions, refer back to these questions/answers as the drivers for decisions that are being made!  Do not get caught up in the “What-Ifs” that kill progress.  These answers will help the team stay focused on the problems that you’re trying to solve.  They’re gold!

Advertisements

Navigation and the Dodo

Evolution is cruel.  Our cool calm world is easily scattered into pieces by a comet, global warming, or some other lame metaphor that has no business interfering with our standard UX life.  Nothing lives forever, that simple truth and its application to all aspects of life fits beautifully in our world of UI design patterns, especially around navigation.  The fact that nothing is permanent not only enables us to smell the roses but also inspires us want something better.  What are we to do in the ever-evolving world of standards, frameworks, device sizes, interaction variances, and the myriad of other ‘things’ that would drive us to make deliberate design decisions for the betterment of a product?  How do we differentiate, innovate, and make those amazing leaps for navigation concepts that outlast fads and the interest of something because it is different?

The Dodo was a pretty sweet beast.  Over time, it had evolved to a flightless juicy turkey who up to a point in time was completely fat dumb and happy.  However, humans (also evolving) were learning to explore their world via boat, and one day come to a place where Dodos have been chilling for who knows how long.  Sailors were hungry…they found an easy meal with very little work to acquire.  In addition, with the sailors came animals and pests the Dodo wasn’t used to managing.  If the Dodo could have just flown, we’d see them today (maybe?) probably have them as pets.  Instead, in about 100 years (a brief amount of time considering how long they were probably there), we are left with little to no knowledge of their existence.  Are we to assume those cozy and comfortable Navigation patterns will go the way of the Dodo or will endure longer as evolution sees fit?  I’m a huge fan of evolution.  I firmly believe, like natural selection, that navigation design patterns follow similar evolutionary patterns.  If it works for the users/usage intended…it prevails.  If it is flashy, but doesn’t do much OR is lazy OR it is counterproductive…it fades and disappears.

So, have we reached a point in navigation patterns where natural selection has determined a winner?  I say yes!  The two prevailing application patterns will continue to prevail and won’t greatly evolve in the world of desktops driven by mice.  We should recognize this, focus on the brave new worlds outside this one and stop trying to slap natural selection in the face…it is silly.  Our winners are; 1) Horizontal top and 2) Vertical left.  And yes, this is speaking in the context of Left-to-Right language displays (the opposite applies for RTL).  There is no such thing as a good reason to have a right navigation, just stop it!

While in the waiting room of metaphors to die, those of you who brought forward the primary right vertical menu because you thought you’d be different…I hope you are wearing a Dodo hat as you read this…you deserve it!  There is a reason why certain design patterns are so prevalent…because they work for the users that are using them!

So, now what Mr./Mrs. negative, non-mobile pants?  Responsive/Adaptive layouts kick major ass.  If you’re not doing it, and you have users on various devices/viewing sizes, I am fairly certain you wouldn’t be reading this anyway.  That being said, how do we make the best design decisions for those who will access our products with so many different landscapes?  Mobile first?  That isn’t the right approach, nor do I feel there is a meaningful silver bullet (pardon the overused metaphor) for all occasions.  As always, know your users and usage patterns and let that drive your decision.  If more people will access via mobile device, design your navigation accordingly (so that it responds adaptively :)) or multiple patterns/applications based on the device or viewing size.  You can’t expect that left navigation will work well in any environment.

It’s time to evolve, however ONLY if and when you must…

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!

Why Development Frameworks are the Devil

From the perspective of a User Experience professional, the use of development frameworks has to be one of the most significant limiting choices an organization makes when deciding to build software User Interfaces.  Before we get too far along, I want to be clear on what I mean in regards to what a “Framework” is in the context of this conversation.  I’m talking about the set of tools/products and libraries teams use to develop and test Web applications.

Don’t get me wrong, I get it…the appeal, a company’s desire to have a standard set of components, expedite and simplify development/test, and a horde of other false promises the tasty Framework of the week offers.  I am in no way saying UI development frameworks can’t be successful, there are many examples out there for great applications being built using frameworks.  However, I have yet to experience an organization’s ability to take a collection of complex products and rely on one single framework strategy to solve complex sets of functions that span those products.  If your organization has a limited product catalog or a few simple products that can adapted quickly…a framework is probably a good choice.  If you don’t have the expertise in house to develop a set of standard components and UI guidelines that will evolve with the company’s strategic direction; it makes sense to rely on a framework, rely on those who have supposedly invested time to provide usable constraints in which to deliver functionality.  But prepare to deal with their way of delivering; there may be little room to adapt UI interactions to meet end-user’s needs and thus a limited or unusable experience for your use cases.

I firmly believe that if you have experienced (aka expensive, but awesome at their job) people developing your User Interfaces, the need for the heavy and unforgiving frameworks all but disappears.  Some frameworks are more forgiving or flexible, while others provide a strict model by which deviation quickly extinguishes any hope for development savings.  So, why are Development Frameworks the devil?

They don’t typically enable enterprises to make design and interaction choices that benefit end users for relevant use cases.

Here may be some practical points to consider:

Time to market, ramp up of design, development and test skillsets

We’ll leave the research phase out of the discussion, once an organization chooses a framework and the relevant technology stack needed to support it, personnel will need to get trained appropriately.  Outside help is another option, assuming it can be found in the timeline constraints for the project(s).  With the increasing pace of these frameworks, by the time the teams are proficient enough to be successful, it’s almost always the time to move on to the next best choice…the cycle continues.

Expertise hard to find

Cutting edge means the internal talent pool likely isn’t up to speed on the latest trends, outside help will be expensive and hard to find.

This is inherently risky for increased time to market; as people learn as they go, the lessons learned won’t apply to the next iteration…which can be too late.

Unattractive (non-sexy) framework choices are less desirable to developers, despite potential usability benefits (again, users not at front), people want to build the skills around what is marketable and what is enjoyable.

Competing frameworks may negatively impact usability

Within an organization, if you have various frameworks in play for UI development, this may not be an issue.  It does become an issue when products and/or functionality is integrated.  Frameworks have their own ways of enabling users to complete tasks, users can very easily pick up on variations (not always a bad aspect of usability), this can lead to conflicting interactions that may lead to usability issues.

Legacy application incompatibility – look, feel, interaction…all different

If you have existing applications, it is likely that your viable legacy UIs will have to be rewritten in parallel with your new applications being developed, if you’re looking for a consistent experience across your products.  If you are brand new or only have 1 or 2 small products, a framework may help compliment your strategy.  However, it may be helpful to choose one that has common design standards but also manages change well…especially if your organization is concerned with aesthetic vogue.  Otherwise, you may find yourself adopting new frameworks every few years, forcing an eternally inconsistent user experience and an even more challenging internal development environment.

Cross browser compatibility

Do you care about cross-browser compatibility?  If your organization is pushing for modern modern modern, ensure this dovetails with any existing legacy applications you may have to support.  Is there funding to update the UI layer of those legacy applications?  If not, going modern and pushing your users to adopt modern browsers may cause a very serious problem.  OR the other problem, not realizing your users don’t have the ability to upgrade to a modern browser may leave them unable to use your modern application UIs.  For example, have you tried to use Angular/Bootstrap in IE 8?  Have you tested your applications in IE11, chrome, safari, FF?  The devil is definitely in the details when it comes to the ability for users to even access content across browsers.  It’s absolutely fundamental to know what you NEED to support and what you want to support long term.  So, does your framework choice enable or hinder cross browser compliance?

In Closing

These days, I’d much rather work with a team of people who are skilled in HTML5/CSS3, Jquery, JS, etc. than those who know x,y,or z framework.  I firmly believe that a solid team who know the fundamentals of web application design will vastly outperform and create a more attractive, usable product than a much larger team of less-skilled individuals utilizing a rigid framework!  I believe it’s primarily the short-sighted financial decisions that lead to the adopting of frameworks in general, organizations don’t want to pay skilled labor wages.  They think they can short cut the process by buying a framework (or going open source) and paying less skilled people to drive as the framework allows.  If your organization is following user-centered design, you’ll more than likely find that what users want, how they need to interact with your application in order to be most successful will NOT be in alignment with what the framework will allow!  And that, my friends, is why frameworks are the devil!

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!