Another commonly confused pair is UX and CX - user and customer experiences. In some cases, there is an overlap between the meanings of these two terms. In other cases, they are not only miles apart from each other but even contrast. Even with contrastive usage, domain specialists have a hard time during conversations. But it surprised me when I asked a UX Guru on Twitter how he handled this challenge, and he responded, “I don't understand. Aren't they the same?"” Well, no, they are not the same.

Users and Customers are not the same. Even when a visitor on a website or a web application is both a user and a customer, she still carries different expectations while (1) using and (2) paying and beyond. More importantly, although not consciously, she will derive different experiences. The result from using the site/application will almost be instantaneous - for example, in the case of online shopping, how quickly the desired items could be found, effectively compared against each other, and sufficient information provided to make a final decision confidently - that will dictate the User Experience. The Customer Experience, on the other hand, will take much longer to take shape. Did she receive a loyalty discount while checking out? Was there a prompt order confirmation over email with a precise delivery date? Were the shipping updates sent frequently and accurately? Did the order arrive on the expected time and in good shape? How was the packaging? What did her family and friends say about the purchase? How was the first week of use? Any one of them can be a spoiler. And many other things that are entirely out of control for the product owner, product designer, and the customer herself. For example, the day after purchase, a much better option for the product was launched by another company than the one she just bought from, for almost the same price. Everything is ruined now!

In the case of an enterprise application, the customers and users are distinguishable. It is the company owner or somebody from the finance department paying for the Project Management tool, but the company staff actually uses it. Those who pay don't use the product, at least not as heavily and regularly as the primary users. The buying decision considers a lot more and beyond the user's experience. The affordability of the organization in the current situation, the bias of the staff lobby trusted by the finance head, the bias of the finance head herself, the level of industry standards and security compliance required by the customer organization versus the adherence provided by the product, are some factors that will drive the buying decision for the customers which has less or almost no direct involvement of actual users. The sad reality of the enterprise world is the customers (who pay) don't care about the pains of the actual users (their staff), at least not until it starts taking a 'visible' toll on the revenue earning.

Hopefully, by now, I have made it evident enough for you to see that UX and CX differ. The scope of work and the skillsets required for a User Experience Designer are very different from those of a Customer Experience Designer if any such a role exists. You must have seen the 'UX/CX Designer' job posts. The company and the people making that job post don't realize the difference and use these terms interchangeably. You may say these are just words, and they don't matter much, even while replacing each other. You won't be wrong. But it matters to me as a designer. A designer must know the difference because if you don't understand it, you might be inefficient in delivering a good solution.

• Website - No customers; all visitors are users.

• E-commerce Website - Customers and users are the same but have different expectations.

• Social Media Website - Most visitors are users; advertisers (and paid users) are customers.

• Consumer (B2C) Web Application - Customers and users are the same.

• Enterprise (B2B) Web Application - Organization financial heads are customers; their staff are users.

• B2B+B2C Web Applications - All the best! :D

I've mostly worked on designing Enterprise Web Applications, and a maximum visual design workforce is also employed in B2B development. Most design decisions on an Enterprise Web Application Product Development Team care for and favor customers. You (the designers) are the ones who will be responsible for finding a delicate balance between the interests of users and customers and delivering the best possible compromise. It is hard to get hold of end-users in the enterprise world. I have yet to see a design team that successfully contacted and recruited end-users (customer staff members) in their enterprise application design research. But I try my best to utilize end-user representatives (customer support staff, professional services staff, etc.) during my design research and Usability Tests - basically, people who directly listen to end-user complaints.

Marketing and sales departments deal with customers; it is very much possible that your Product Management Team, as well. So, please be aware of the risks to those you are listening to. Not that you shouldn't take their feedback and suggestions, but they worry more about product customers rather than the actual end-users. Know which one of the two worlds your stakeholder cares and represents. Almost none of your stakeholders will likely worry about end-user pains if you are on an enterprise product-building team. (In an ironic but accidental way, the 'UX/CX Designer' job post heading suddenly seems meaningful.) How does it feel now to carry the ethical burden of being a 'User Experience Designer'? Are we able to provide the proper justice to our job title and our actual end-users?

I have closely seen various roles in the Design Industry: Graphics Designer (Print Media), Visual Designer (Software), Motion Graphics Designer (Animation), Brand Designer, Typography Designer, etc. Also, while working in Software Development teams, I pith Product Managers, Frontend and Backend Engineers, Content Writers, Security Engineers, Quality Assurance Engineers, and DevOps Engineers. Although I haven’t played all these roles first-hand, I was fortunate enough to work with and watch them closely to understand the genuine challenges of each. As a Visual Design Engineer, I highly respect the problem-solving skills needed in each role, but I find unparalleled excitement and satisfaction in my professional challenges. I keenly mention the word ‘Engineer’ in my role title. My understanding and self-definition of the “Visual Design Engineer” role is:

Crafting visual design solution proposals for web and/or mobile applications by applying Design Science, collaborating with other stakeholders to conclude the most feasible design solutions, delivering those on time, and seamlessly integrating this visual design process with the Software Engineering process.

Their responsibilities in detail are:

• Understanding requirements in terms of their impact on customers, user personas, and the business by working closely with product management.

• Creating a Design Strategy.

• Collaborating with all stakeholders to finalize user scenarios, tasks, information architecture, and navigation.

• Facilitating high-level solution ideation with the key stakeholders.

• Owning the iterations for wireframes and mockups.

• Participating in all types of usability testing and proactively communicating final design decisions with appropriate reasoning to respective stakeholders.

• Applying design science to define crisp and thorough visual designs, interaction designs, and related specifications to the software development team.

• Utilizing the best of the industry standard visual design tools and workflows that integrate well with other software development tools and workflows.

• Consistently ensuring that the visual design process is well embedded and in sync with the software development lifecycle, especially methodologies like Scrum.

• Validating the quality of development implementation against the provided design inputs during the Development Sprint.

• Actively participating in production monitoring and analyzing usage statistics.

Although the software product development lifecycle involves various stages, engineering teams worldwide have adopted ‘iterative progression with continuous feedback’ through methodologies like Scrum as a standard. This lifecycle contains Product Requirement Gathering and Analysis, Solution Ideation, Incremental Development and Testing, Continuous Delivery, and Monitoring. Two-week Sprints are a de-facto standard for incremental release cycles. Ideally, Scrum recommends maximum parallel execution from each skill function in the team. However, two weeks is short for a meaningful product increment to deliver with the utmost quality and confidence.

(To be replaced with a finer illustration and accurate version later.)

To make a Sprint successful, the team must understand that a change in the product code is the most expensive part of the development cycle, and it better be supplied with superb clarity from the Product Management and the UX Team. A ‘Coupled Sprint’ pattern works best toward this aim, where the UX Sprint precedes every Development Sprint to provide the software developers with crisp change requirements, visual design, and interaction specifications. This does not isolate Visual Designs from Developers but instead expects them to be involved in each others' Sprints by closely watching decision-making and progress to provide timely inputs and validations.

I understand the term ‘Engineering’ as ‘following a highly reusable process that applies particular sciences and technologies to deliver supreme-quality produce every time consistently’. So ideally, when an engineer is asked to create a perfect metal sphere, she won’t just create one sphere but rather create a process and machinery that will deliver the same quality sphere every time it will be required in the future.

A Visual Designer who uses design science and technologies in such a way is a Visual Design Engineer.

As a result, engineers require less and less time for repetitive challenges, and they can focus on innovation and ingenuity during their next problem-solving.

My role expects me to work closely with product owners, other design team members, developers, and primarily customers. It is not that the other product development team members don’t need to do this, but I have to own the implementation design direction. Not only do I have to use my creative skills, but I also need to be effective with people interactions, conducting interviews, analyzing, negotiating hard while justifying design decisions, collaborating, and facilitating discussions. I feel immensely passionate about this role and the responsibilities it offers.

I plan to experiment with each of the roles a software development team offers. With a high-ownership attitude, every role will surely provide great satisfaction. However, my role still appeals best ‘to me’ due to my passion for the particular skills required here - through creativity and a disciplined approach, achieving a perfect balance between the two worlds a product serves - business and customers. At least, I can confidently say that it offers me a unique thrill.