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!
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?
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!