Design Like a Lady. Code Like a Geek. » Design

Find Out Why – You Don’t Know C.R.A.P. about UX & UI

Lindsay — Tue, 02 Aug 2011 02:11:09 +0000

Stop banging your head against the wall, asking the wrong questions of your users and processing the feedback incorrectly; learn how to get ahead of the curve by designing better experiences and interfaces for your applications! I am very excited to announce that this month I will be teaching a beginner’s class on User Experience and User Interface Design as part of the NY-based startup SkillShare’s launch in Philadelphia!

Who: Yours Truly (View My Portfolio for Credentials)

What: Learn practical UX & UI skills to user on your future projects.

Where: CitySpace, 2200 Walnut Street in Philly

When: August 23rd, from 7:00PM – 8:30PM

Why? Because the future of application development is in the experience and you only get one chance to make a first impression! It’s not just a matter of redesigning your Web 1.0 (alternating colored rows in a table, yuck!) app by implementing the flashiest new jQuery plugin (Woohoo, the form slides in from the left!!), it’s about picking the right design for the right use, and converting visitors to real users.

If that’s not enough, all proceeds go to the local Philly organization TechGirlz, dedicated to training the next generation of female technologists.

>> Register now for the course!

Let’s Start a Learning Revolution

Thinking About It?

I would like to hear from you if you cannot make the class (so I can schedule Take 2) OR if you want to take the class AND have questions about what you will learn OR have specific goals for the class that you would like to share with me. SkillShare is all about teaching and learning, as well as building a community, so please contact me in the comments or via email (lindsaytabas [at] gmail [dot] com).

Take a Gander At…

Women in Science Fair

Lindsay — Thu, 12 May 2011 19:54:18 +0000

This week I presented at Cheltenham Elementary School’s Women in Science Fair as the first ever “computer” participant in the fair’s history. I decided to teach the children the basic design principles – C.R.A.P. – though I had to rearrange the letters – P.A.R.C – to take into consideration my K-5th grade audience. So we learned about Proximity, Alignment, Repetition and Contrast by assembling a poster about Toy City.

To prepare for the fair, I used stencils, spray paint and markers to create an interactive poster board. In the center, I put the pieces of information for the Toy City website on velcro so the children could move the information around and see the results spatially on the board.

The day began with the Kindergarteners who, we all agreed, were too young to grasp the “science” part of the fair. They did understand the mission given to them by their teachers: Get at least 6 sign-offs from the different tables indicating you visited. It probably wasn’t until the 3rd graders that the students really started to grasp the concepts of layout and design. I think this is a big take-away for anyone else out there keen on teaching design to younger children.

The typical conversation with each student went this way. After approaching, I would say:

Lindsay: Hi there, do you like to play with computers?

Student: YES!

Lindsay: What do you like to do on computers?

Student: Play gaa-a-ames!

Lindsay: Oh what kind of games?

Student: [INSERT SOME GAME I DON'T KNOW]

Lindsay: Well do you want to play a game today?

Student: Yes!

Lindsay: We’re going to design a website! Have you ever done that?

Student:

Lindsay: Well let’s design a website for ToyCity, the BEST Playground & Toy store in Philadelphia. Before we begin, lets organize the information into groups (prompt them to organize all the pieces on the table. pieces that were similar were also in the same color).

The groups of information were: Name of the Store, Taglines, Products & Availability. I walked them through each one, pointing out principles of alignment and repetition. I found Contrast was almost negligible in this exercise.

I think the highlight of the morning was the one 4th grader who, when asked what he likes to do most on the computer, answered enthusiastically, “Search facts on Wikipedia!” And when I asked him if he wanted to design a website, he cooed extra excitedly “I’ve always wanted to do that!” Unfortunately, his teacher chirped for all her students less than 20 seconds into the exercise.

Here’s the full slideshow of photos:

My Top 10 (UX/UI/IX) Design Principles

Lindsay — Wed, 23 Feb 2011 19:04:35 +0000

No one would ever want to design an interface like the HCFA, but I had to because it was what the user wanted. I couldn't be stubborn, I had to admit I was not a user, I had to come to a 360 degree understanding, and realize that I could not change what the users do.

Last week, I posted my tips for being an effective designer in a lean environment. This week, while perusing the UX topic on Quora, I noticed someone posted a question “What are the top 3 commandments of Web UX?“. It reminded me that I had started a Top 10 list last year and never got around to publishing it. So here you go, my Top 10 Design Principles.

Build something that supports what people do, not changes how they do it. I do not believe I have to expound on this one.
Training is not an excuse for poor design. I wrote a blog post on this topic last year. If you ever hear a teammate say “Oh, but we can train the users how to do this” then your product’s design is going in the wrong direction.
The users are always right, but they never know what they need. Listen to your users, they have vast wealths of information about their problems and what they would like to see fixed. But software designers, they are not. If a user tells you the solution, ask them first to describe the problem. Once, a non-profit explained to me that they needed users to sign-up with their website so they could RSVP to events and download a member registration form. I could have spent hours developing a multi-user system, but instead I asked them more about their event planning and how one become a member of their organization. It turns out Eventbrite could handle their events, and they were fine with the form being publicly available.
I am not the user. My teammates are not the users. The customer is not always the user. This is fairly simple. The users are the users, and they have to be able to use what you design and build for them.
Empathize with the users’ problems and end goals. If after discovery, you don’t feel like you are burdened by their problems too, you’re not going to design a world class product and the solution they need.
Don’t settle until you have a 360 degree view of the problem. If you do not have a full grasp of the entire service system, something like accounting or managerial over site will come bite you in the behind when you’re about to launch. ”Oh, the solution cannot work like that, you did not take into account XYZ.” Oh, well no one told me about XYZ. That’s not their fault, you should have asked.
Your Design should be C.R.A.P.-y : In my first semester in HCI, the first homework assignment was to redesign posters by the C.R.A.P. principles: Contrast, Repetition, Alignment and Proximity. Here’s a nice post about C.R.A.P.
Friends don’t let friends design alone (i.e. share your designs with others). It took me at least my first semester at the School of Information to go from an objective, standards-based engineer (things were fairly black and white), to a designer that fully grasped the subjectivity that is the human language and opinion. Pull in your team members, it’s part of operating in a lean environment anyways.
Stubborness is the worst trait of a designer. If a user or co-worker critics your design, take the feedback and go back to the drawing board. It took me 4 iterations to get a 10-key form right, but the users love it.
If something is difficult to do, people will not do it (ref) Also, fairly simple. It also goes very well with a sentiment I have been building that goes like, “If people don’t already do it, just because you make it easier, doesn’t mean they are going to start.” This goes well with #1.For example, providing easy social media tools to niche populations. If they’re not already talking and sharing naturally, they probably won’t talk and share just because you build them a custom app.

The UX Designer’s Downward Dog: Designing in a Lean Environment

Lindsay — Tue, 15 Feb 2011 14:35:39 +0000

Don Norman said once in a lecture at the I-School that if the HCI people aren’t part of the product planning, then their value is actually lost (*paraphrased). Possibly, in the past year or two, the importance of user experience (UX) design is rising to its appropriate place in entrepreneurship circles and startup teams.

As a community, we are realizing a trained designer with a diverse skill set goes beyond the placement of buttons and the creation of CSS sprites. We UX designers now come prepackaged with the features to help inform the product roadmap (if not manage the product), work closely with software developers, and contribute to sales calls and client visits. We are a diverse breed because at the crux of our skills is not only the know how to make things look pretty and function properly, but the ability to empathize with our users’ problems and to understand people.

Today, I found myself writing an essay-of-a-response to an interesting blog article from Cooper, a design and strategy firm in San Francisco. Tim McCoy wrote in “Lean UX, Product Stewardship, and Integrated Teams” how UX designers are finding their place in start-ups, flexing their diverse skill set, and effectively contributing to lean development team. I had a few pieces to contribute that went beyond the maximum permissible (in my opinion) characters of a good comment, so here I share with you.

McCoy posits that traditional UX methodologies were developed in waterfall environments, which we can all agree upon because almost everything regarding software development began in the waterfall environment.

In the past decade of my education and career, user-centered design rose to the challenge of modern software development techniques by being inherently iterative. Research, design, develop (Lo-Fi Testing), research, design, develop (Hi-Fi Testing), research, design, develop (Alpha/Beta). My design project from the iSchool (circa 2006), LightsOn, made it to 3 iterations before the final project was due; we only had to test with 3-4 potential users each time. As I left graduate school, it seemed we were ready for agile environments, but developers and engineers were not ready for us.

It’s a combination of multiple facets that has prepared us for this meeting point where:

The users have a stronger voice, demanding better experience
There are enough designers to meet the call of duty
The developers and engineers understand where their skills end and a designer’s begins

So what can we designers do to improve our downward dog, be agile and flexible, and meet the demands of a fast moving software development team? In response to McCoy, I detail a few techniques that I use to apply myself effectively to my teams:

Involve developers and engineers in your process: Your teammates are more likely to value your user personas and user feedback if you actually explain to them who the users are. Some of my teammates have told me they really don’t care, “just get me the requirements”, while others have joined me in developing activity diagrams, data requirements and new design ideas.
Become a partner in design: In line with #1, if an interaction or data requirement is outside of your expertise, it’s a great way to involve the developers and engineers in your work. Ask, “Is this interaction even possible? Can we implement it this way?” Explain why it has to be done that way, and negotiate a solution. Be partners in design. The worst thing for you to do is to design a new feature, hand it to a developer, and, then find out the implementation is technically impossible. You just wasted a week, and probably another.
Test with anyone, at first: In one project, I put together a simple lo-fi prototype to test the intuitiveness of a new feature’s interaction. I met with one of our sales representatives for 1-hour; the meeting revealed a list of design changes, as well as new ideas given her experience with the product. You don’t necessarily need a representative from your user community to get valuable usability feedback.
Ignore LOUD users: The worst thing a company can do is adhere to the complaints and demands of a few loud users. A business-side employee pushed through a new feature that permanently locked text notes because one client did not trust his employees to make edits. It was a PR disaster. We rolled back that change in less than 24 hours, took 1 month to rethink and research, then relaunch.
Cultivate a strong relationship with Customer Support and Community Leaders: It’s really simple. The people on the phones everyday with the users know why the users want the changes they have requested. They are always my first step when researching a new feature request.
Learn the Basics of Objected-Oriented Programming and Database Structures: My 4-5 semesters between undergraduate and graduate school did not make me a trained software developer, but understanding 0…* relationships and class diagrams, as well as being able to speak in “if”, “else”, “while” and “for” gave me the tools to walk the bridge to my teammates’ side of the chasm.
Take a Tip from Business Development: When you start a new business, you value your first few customers more than any others. You never raise their fees and you service their requests in a timely matter. They repay you in recommendations and referrals. Do the same with a handful of users that you keep in touch with. Politely call them with questions about new features and bugs; it’s cheaper than running community-wide surveys and less intensive than deploying poorly designed features and processing all of the complaints.
Teach Nielsen’s Usability Heuristics: I’m a firm believer in Jakob Nielsen’s Usability Heuristics and the Heuristic Evaluation. After running a project with 90% of my coworkers with my last employer, we all shared a common language to discuss new product features.
Develop a Style Guide: Marketing and Advertising departments have style guides for the way the company logo can be used, so you should maintain one for the way the software should function. It maintains consistency, and becomes the de facto guide for any developer left to their own design-devices. They detail the shape, size and color of buttons, whether a link should open in a new window versus the existing window, and how the navigation system should function across all levels of the site hierarchy.
Finally, be well rounded. What makes me good as a designer is that I have tried a little of everything: I’ve pressed send on marketing e-mail campaigns, designed logos, built websites, and met with customers to up-sell them on products. Designing is my core skill, but in an agile environment, I can fill in on any team that is lacking a particular talent.

McCoy posted a slide deck that addresses even more ideas for integrating with a lean environment:

Lean UX, Product Stewardship & Integrated Teams

View more presentations from Tim McCoy.

Subject to Change

Lindsay — Sun, 22 Nov 2009 04:24:48 +0000

While in Southern California this past week, I made my way over to Hennesy + Ingalls in Santa Monica at the behest of my friend Nate. The store is packed with books on creativity, architecture, graphic design and photography; basically it was amazing!

There, we picked up Adaptive Path‘s “Subject to Change: Creating Great Products and Services for an Uncertain World.” This was the first time I had a chance to hold the book in my hands and check out the bibliography in the back. Lo and behold, there was my name (along with the primary author, Professor Bob Glushko from Berkeley’s School of Information) for a paper I helped author called “Bridging the Front Stage and Back Stage of Service Design”. To be honest, it was pretty amazing to see the citation, and my name in print. It’s also great to know that someone else read what I had to say on a topic, and found it thought-provoking enough to share it with others in their own publications.

Here are a couple of pictures Nate took to capture my “moment”!

Avoid Using Flash: The jQuery Cycle Plugin

Lindsay — Thu, 08 Oct 2009 18:02:38 +0000

My cousin Alexandra ran into an entertainment industry snafu earlier this year when an uncredited appearance on Lost gave the tv show’s internet fans free reigns to guess her name. Unofficial credits began appearing on the photographer’s flickr photos, then TV Guide and, finally, on Lostpedia entries in English, and Spanish. When she realized that a search of Alexandra Tobas wielded more content than a search of her correctly spelled name, Alexandra Tabas (with an ‘a’), she called me for help. We did a bit of troubleshooting on her IMDB page, and on each Lostpedia entry. I then did a ‘whois’ on her domain name. She owned her domain name and didn’t have anything up yet! This is a tidbit for everyone out there – if you do not like your search results, you only have yourself to blame if you do not have a site up under www.yourname.com.

While I do not have time to build her an entire portfolio right now, I went ahead and put up a simple page using the jQuery Cycle Plugin. This plugin is an excellent way to mimic Flash objects without having to actually use Flash. I never learned to use Flash seriously because it is a black box to search engines, although I’ve heard this has changed in recent years. If this is old news, the new headlines are reporting that Flash uses unregulated cookies and is invading our privacy, which means I’m still staying away from it with a ten foot pole. Many web designers hate Flash on similar principles, if not just for the sole reason that there is this misnomer that your website, brand or image is somehow cool because you use a Flash intro on your site. Flash is fun to play with, but not necessarily the tool you want to use for heavy lifting.

That being said, jQuery Cycle Plugin is about the easiest thing you can use to add some pizzazz to your site. In about three easy steps:

Reference the jQuery library, and the Cycle Plugin in your header.
Create a
and list your within that div tag. Make sure to specify each images height and width, and include an alt value, not just to be xhtml compliant, but because you want to add extra, search-able text, to your site.
Set the height and width of your .pics class in your css. Make sure they are big enough to hold each image.
Add the following script to your file:

$(document).ready(function() {
$(‘.pics’).cycle({
fx: ‘fade’
});

The plugin’s demo site is super easy to follow for any beginner, and if you want to get fancier, you can change your transition type in your script. I will definitely be using this plugin for my own portfolio in the future!

View AlexandraTabas.com here!

The Heuristic Evaluation Project

Lindsay — Tue, 06 Oct 2009 22:13:08 +0000

The project detailed here was created and designed by me, Lindsay Tabas, in Fall 2008. It is based on Jakob Nielsen’s Heuristic Evaluation methodology that I learned while taking Marti Hearst’s class titled “User Interface Design & Development” in Spring 2006.

Summary

A Heuristic Evaluation is a usability inspection method performed systematically; it is traditionally part of an iterative UI development process and an alternative to user testing. For this project, an evaluation was performed with all employees within the company. We used the heuristics more loosely to guide discussion around the major functional areas of the product.

The goals of a heuristic evaluation are:

To find usability problems, both major and minor
To judge the software’s compliance with recognized usability principles

The discussion elicited many ideas and visions for how the product can accommodate its vast client needs. The largest benefit was the consensus building and idea trading taking place between colleagues from different departments within the company.

Why Perform a Heuristic Evaluation of Your Product?

A Heuristic Evaluation project is the first step in evaluating an existing product’s strengths and weaknesses, and will support brainstorming within a company on improvements for the next version. The primary outcome of the project is a compiled design evaluation that includes new feature proposals and high level design principles. The secondary outcomes of this type of project is to unite the different business units of the company, promote creativity and forward thinking, and build a shared sense of team and common goals. A tertiary benefit, which should be part of every company’s knowledge management efforts, includes hard-coding employee domain expertise so that in the event of anyone’s departure, this knowledge remains an asset to the company, and does not walk away with the employee. We may also include education as a benefit, in that more team members grasp basic usability principles that they can carry with them as they embark on features and bug fixes that don’t have time to be reviewed by a designer or analyst.

Background

In April 2008, I was the first trained “any role”* that sat between the client and the software development team. The product has sailed by for the previous 5 years because it was the only web-based SAAS product on the market in its industry. When you have that type of advantage, little effort is required to retain customers. That means that features were poorly implemented and based on only a few loud clients’ requests, the sales team was allowed to oversell the product, and the customer support team was left to handle dissatisfied users. All of this, after five years, left the majority of development resources stuck fighting fires, rather than building a world-class, scalable application. It was also clear that there was a breadth of domain expertise from all parts of the company, but little time to share that knowledge, nor build up from it.

After the first 6 months at work, I lobbied the CTO and the rest of the management team to allow me to collect our company’s knowledge by running a Heuristic Evaluation on our out-of-the-box product. Not only would I be able to hard-code this knowledge as a company asset, I would be able to learn more from my co-workers in order to build better features and modules, as well as work towards Product 2.0.

Heuristics

The ten usability heuristics are listed here:

Visibility of System Status
Match Between System and the Real World
User Control and Freedom
Consistency and Standards
Error Prevention
Recognition Rather than Recall
Flexibility and Efficiency of Use
Aesthetic and Minimalist Design
Help Users Recognize, Diagnose, and Recover from Errors
Help and Documentation

Methodology

Over a two week period, I held 8 team meetings. The company was divided into 4 groups for the first week, and a different 4 groups for the second week. Each group (for each week) was made up of participants that had varied roles and expertise within the organization. For example, one group had a junior and senior programmer, a customer support associate, a trainer, and a sales associate. The idea was to build groups with employees that may not normally trade ideas about the product.

During each 1 hour meeting, a different functional area was the focus. One group looked at scheduling, while another looked at invoicing, and so on. At the beginning of each meeting, we reviewed Jakob Nielsen’s 10 Usability Heuristics (listed below). We then went through 4-5 major user tasks within the assigned functional area; for example, Create a New Patient. Everyone would have a few minutes to perform the task and take notes, then I would choose one person, usually the one least likely to know how to perform the task, to guide us through the steps they took to complete the task.

As one teammate discussed their frustrations, another would offer tips, while another would chime in with why the feature was implemented in such a way. Teammates from customer support would let us know if this was particularly frustrating for the users that they spoke to on a daily basis, and new programmers would detail how they may have implemented such a feature. After frustrations were aired within the context of the heuristics, I would ask everyone to tell me how the feature would operate in a “perfect world” with “no strings attached” to lead into brainstorming.

Final Report

After the 2 weeks of meeting, I prepared a final report for the management team in two versions – one detailed report and one executive report. Here are some of the components of the detailed report:

Most often violated heuristics
General Pain Points (ex: button placement, help information, data pages and forms)
By Functional Area:
- Table of Pain Points with Examples and Design Opportunities
- Specific features with suggested design changes
- Customer Support Statistics (ex: 30-40% of our support issues deal with reports)
Business Goals (ex: Reduce the effort to train current users)
Design Goals
Design Ideas (high level)
Structural Guidelines (ex: maintain a multi-user system)
Special Considerations
Risks
Opportunities
Next Steps

* “Any Role” = Product Manager, UI Designer, User Experience Researcher, Requirements Analyst, etc. Any role that participates in translating customer needs to software requirements and functional specifications.

Custom Electronic Claims Processing Module

Lindsay — Wed, 30 Sep 2009 17:01:46 +0000

In my opinion, designing for the health care industry, particularly for the relationship between doctors and insurance companies, is one of the greatest design challenges of the 21st century. Here, I describe one project that sought to increase the clearance rate of electronic insurance claims for one organization in the audiology industry.

The client organization employed 8 Insurance Billing Specialists to bill thousands of insurance claims per month for over 200 clinics around the country. Their existing system of use included two different applications, 1 for the clinics and 1 for the billing office; this design caused many information gaps, overlaps and inefficiencies in their business processes.

The goals of the project were to:

Reduce the amount of time it takes to create, process and submit claims, electronically and by paper, to over 2000 Insurance Companies.
Design a Claims Console for the corporate office to review and process over 1000 claims per week.
Plug in the Claims Console to the Clinic Software so that the clinics can submit accurate claim information electronically to the billing department.
Update the existing software so that the clinic users can more accurately assess the status and track the claim through the course of the claims lifetime.
…all while meeting detailed accounting regulations.

As the lead (and only) business analyst, product manager and user interface designer, my responsibilities were to:

Identify the gaps and overlaps of information exchange between centralized billing and its
200+ clinics.
Document discovery and requirements, create UML deliverables, including user stories,
activity diagrams and use cases.
Design the user interface for both clinic, billing and administrative users.
Manage the multiple user objectives, and (often) conflicting business goals.
Work closely with the engineering team through development and testing, managing bugs, change orders and new requirements.

To read more about some of the design challenges I faced designing for these users, read Designing for 10-key Users.

Bad Usability Calendar 2009

Lindsay — Tue, 15 Sep 2009 00:13:42 +0000

I’ve had this calendar hanging in my office for the majority of this year. It has 48 “classic” design mistakes, and I find each one wildly entertaining. My favorite month is July because I like the idea of playing shoots and ladders with my days. Did you roll the die wrong today? Go back to last week!

Bad Usability Calendar 2009

Select the image to visit the source site.

The UI/UX Sandwich

Lindsay — Thu, 27 Aug 2009 17:04:07 +0000

Two or three years ago, it seemed that while universities were churning out students who had taken classes in Needs and Usability Assessment, User Interface Design and Development, and Social and Organizational Issues of Information, industry was still denying the benefits of such expertise on their products. These roles were confined to corporate research labs, and only the bleeding edge companies (at the time) like Google and Yahoo. In the past few years, more companies seem open to the idea of having designers on their development teams, but still not being able to quantify their benefit in terms of Return on Investment (ROI) figures, they are trying to sandwich User Interface Design and User Experience Research between other roles.

UI/UX != Graphic Design

Graphic Designers are artists and extremely creative. They have amazing visual talent, and most likely honed their art through other mediums, then realized years later that the foray into technology meant more money. User Interface and User Experience designers should have a technical background complimented with expertise or familiarity in psychology, sociology and cognitive science. It’s not necessary they have a degree in computer science and a degree in psychology, but one or the other, with familiarity in each is necessary. In simplest terms, Graphic Designers make things look cool, UI/UX designers make things functional and usable for the user.

Looks Cool, But Doesn't Work

I use this analogy to highlight my point: My mom is an interior decorator. She makes homes look beautiful for our family and all of her customers. She has a good eye for patterns, fabrics, and colors, and is familiar with feng shui for organization. While my mom understands the purpose of the room, and can arrange it to succeed the goals of the room (for cooking, for leisure, for games), she’s not designing the fabric patterns, the tchotchkes, and the furniture herself. There are experts for each of these things. My mom is a UI/UX designer for homes, the pattern experts are graphic designers for the things she puts in the homes.

To employers and product managers out there – hire a UI/UX person to work with the users to understand the problem and design the product to solve that problem. This person (if they are good at what they do) will build you excellent activity diagrams, interactions diagrams, wireframes, and, if they are awesome, the beginnings of data and functional specifications. They will understand the difference between radio buttons, checkboxes, and drop-downs, and be able to give you a 360 degree view of the application in its design phase. In the wireframes, they reserve space for content, forms, and graphics. They won’t design the graphics themselves because there are trained professionals (i.e. Graphic Designers) for this, and you can hire them on freelance and save yourselves (and your company) lots of money. Besides, you will want to free-up your UI/UX person to move to the next project, or to work with the software developers through implementation.

UI/UX != UI Engineer

When Software Developers are Left to Design Error Messages

In absence of a real UI/UX designer, the role of UI Engineer is perpetually confusing for me. I have to say first that UI Engineers are no different than other software engineers. Just because they know how to write JavaScript, PHP, HTML and CSS does not mean that they are better suited than other software engineers for working with the users to design a better solution. That being said, for years experts in the industry have been saying that software developers should not be handling user feedback. When software developers are left to their own devices without user interface designers to give them guidance, we get open source projects. Firefox aside (because they had UI/UX people come help), how many open source consumer applications are used by more than a few percentage points of the population? I myself forayed into Ubuntu and Mepis, backed out 4 months later, and ended up buying a Mac. OpenOffice maybe has 11 mm active users in the US, which would be roughly 4% of the population.The operating system and applications were not intuitive or easy to use, and when they crashed, they crashed so hard that I had to use the terminal to get anywhere (but usually ended up no where).

Rarely is an excellent software developer (front or back end) particularly good at connecting with, interpreting, and responding to other people, let alone are able to translate what those people’s goals are to usable interfaces. These are all traits demanded by a good UI/UX designer. Furthermore, those of us that take a UI Engineer position expect to have more input into the UI design while still contributing some code to the application. Often what happens is that the UI Engineer is stuck with a crappy design from a Project or Product Manager not trained in UI/UX or Usability, and is expected to do much more development than they ever planned. The company and application/product suffers from not first understanding what skills they needed, and, second, finding the right talent for the job.

All in all, I think any company is lucky to find someone that is really truly good at both graphic design and UI/UX, or UI/UX and UI engineering. Otherwise, you’re compromising your product, and sitting in disillusion thinking that you can sandwich these roles into something tasty, good, edible and marketable (where the user is engaged, likes the features of the product, and wants to use it).