Ditch ‘UX’, it’s time for Product Experiences.
UX is dead, and that’s great news! 🔥
Picture this: You’ve nailed the user experience in testing, only to face chaos a month after launch. Finger-pointing between front-end and design teams ensues. The result? A messy UX, mired in miscommunication.
Sounds familiar? Let’s dig in!
So, who was at fault there?
Honestly, that doesn’t matter! The end users using your product couldn’t care less about the cross-team collaboration miscommunications. For them, it’s just a product that doesn’t work!
Understanding and acknowledging this is the cornerstone of creating good product experiences.
Okay, so what is product experience? Is it just another filler word in the long postmodernist discourse? (Google it.) We’ll get into that in a moment. First, let’s try to explain it so that we have some context going forward.
Product experience in tech involves assessing a user’s interaction with a product, focusing on functionality, interface, and performance alignment with expectations. It’s a holistic evaluation of technical aspects influencing user engagement.
Long story short, Product Experience encompasses everything! UX is just a subset, albeit a very important one. This becomes clear when taking a closer look at its components:
- Accessibility & Usability
- Information Architecture
- Functionality
- Interface Design
- Platform & Tech Stack
- Reliability & Performance
While the first four components break down the general UX process and structure, clarity regarding the last two points is notably lacking among designers. Just ask your design team about their knowledge of the platform technicalities they are designing for; most of them might have a murky picture at best.
Designers easily get frustrated with developers. Maybe they can’t achieve the responsiveness needed for a proper data table, or that critical feature you identified as necessary for the product to function is buried deep in the development backlog. The reality is that developers get frustrated with us too. In all honesty, it’s simply because we don’t understand each other’s world. It’s high time we start trying!
Make sure your designs are executable
As a product designer, you need to keep two things in mind: business and tech accordance.
Suppose you’re building an in-house code deployment portal for your company. If you don’t know what a Repo is or how Release checks play a role, your designs are more likely to be a mindless rip-off of similar competing products. If you propose a solution that might be very hard to execute (if not impossible) with the current capability of your dev team, there’s a high chance they might completely scrap your prototypes and build something on their own, focusing exclusively on functionality.
To counter this and reduce friction with your dev team, set up a liaison with the team, follow agile methods, and have regular conversations and scope checks while designing. With that being said, most designs are executable; you just need to understand the platform and its limitations on which this said product is built. Otherwise, your designs are but a moot point.
Performance-Centric Design Patterns
Performance optimization is the key to UX, and contrary to popular notions, it’s a collaborative effort between the design and dev teams.
If you’re building a data-heavy mobile app without proper knowledge of concepts like database structure and API integrations, it might prove difficult to provide users with solutions for quick data retrieval and related functionalities, adversely impacting performance and leading to slower response times and inefficient data processing. The core idea here is to provide a seamless user experience even in cases of slower network connections.
While tools like Page Speed Insights offer excellent optimization suggestions for image compression and cache management, for more complex and platform-specific considerations, consider using Google Lighthouse, Robotium, or XCUItest.
Functionalities: Small is Big
The Design and Dev teams generally adhere to a CRUD (Create, Read, Update, and Delete) structure for data management in products. However, the reality is different for developers. While changing the design might take an hour in Figma for you as a designer, a developer might need to create new operation sets and build new feature structures, potentially extending the timeline by one or two sprint days.
It’s crucial to recognize that every functionality, no matter how small, can snowball into significant scope creeps. You might identify a need for a crucial product update based on user feedback, and that’s perfectly acceptable. However, it’s essential to ensure the development team is involved from the outset.
Consider how data is stored and fetched and try to gain a basic understanding of how API calls are executed. This provides designers with a clearer picture of the database constraints. Collaborating with developers is key to understanding and creating an approachable solution in an agile manner.
Read more on Database management & CRUD here ~ https://www.educative.io/blog/crud-operations
Fundamentals of Data Modeling ~ https://agiledata.org/essays/dataModeling101.html
‘Understand’ the Language
A common misconception about developers is that their value is tied to language mastery. In truth, it’s about logical thinking and problem-solving. Languages are tools that evolve, much like a designer shifting from Adobe XD to Figma. Developers prioritize adaptability and system design over adhering to a specific language. (It’s not a one-to-one comparison, but it’s a good approximation).
Designers need not be hardcore developers, but possessing a fundamental understanding of web/mobile infrastructure and basic markup is crucial.
Begin by grasping the fundamentals of CSS and Javascript libraries; frameworks like React, Vue, and Angular rely on JS for development. Developers utilize these tools to create highly scalable and modular products. Acquiring a foundational knowledge of these concepts not only paves the way to becoming exceptional design leaders but also provides insight into the practical implementation of your designs.
Additionally, few other things to consider while updating yourself as a designer ~
- Accessibility ~ Designers talk about user accessibility a lot, and, to my surprise, without knowing the technicalities! It’s time you familiarize yourself with WCAG guidelines, Semantic HTML, and the basics of ARIA specifications.
Bolster the fundamentals of Accessibility (it’s free!) ~ https://www.w3.org/WAI/courses/foundations-course/
- Reusable Components & Design Systems ~ There’s a high chance that at some point in your career, you’ll collaborate with a design system team, establishing usage guidelines for components. Understand how these components are translated into Storybook (or other platforms) and how developers reuse component structures to build UI. This will almost certainly help you enhance your annotation skills and help you understand when to trade off between custom and reusable solutions.
See how code and design interplay with Atlassian’s Design system ~ https://atlassian.design/components
- Keep your self Platform Agnostic ~ Large MNCs often build (or white-label) tools for their internal works, with many starting as a low-code solution (not every team in the org. will have dedicated tech support, so they need an easy, approachable solution to build). Designers should understand the structure and limitations of these platforms (e.g., PowerApps won’t handle complex design patterns) to remain platform-agnostic.
Collab, Collab, Collab
Developers, it’s crucial to recognize that not all designers grasp the intricacies of the technology you use. Your main focus is functionality, (which occasionally sidelines the user perspective). That’s not healthy either! It’s not your job to keep up with UX, but understanding the domain and knowing the designers’ justification will help you make better decisions.
Designers, your role extends beyond Figma and dev handoffs. Start understanding the greater context of how things work in reality; develop a curious mind for the implementation aspect! Also, keep in mind that while your design may propose the best solution, sometimes it’s about having the most ‘feasible’ solution rather than the ideal one. It’s all about scope!
Start your collaboration early! Have open discussions, clearly define the scope, and demo the work in progress so everybody is in the loop. Commonly overlooked, the lack of this disrupts the product development process, even in large MNCs. Siloed work, sparse communication, and ambiguous annotations create a rift between designers and developers, helping no one.
As you navigate this new dynamic, have patience and mutual respect. It won’t be easy right off the bat, but as both teams mature, this not only facilitates smoother and more successful product releases but also propels you to become a more well-rounded, T-shaped professional.
TL;DR
This article is already long enough, and I believe I’ve made my point. All of this might seem overwhelming at times. Then, there’s the age-old infamous question: ‘Should designers learn to code?’, well as Krisztina Szerovay brilliantly puts it,
“ I believe that this is not a good question. Here are some better ones:
Should designers understand the costs, risks, trade-offs of a design decision?
Should designers know how developers work, what challenges they face, what their main tasks are? ”
The answer is ~ Absolutely! Start looking beyond the UX realm, the path is bright!
See you, Space Cowboy!
Read Krisztina’s Article on Development Fundamentals for Designers ~ https://uxdesign.cc/development-fundamentals-for-ux-designers-caf759724874
