#working with developers

[designaday]

Avoiding UX Debt: Modularity, Part 1

There was a trivial bug logged in JIRA—yes, it was a minor detail—that had been assigned to me to fix. The bug affected several different buttons appearing on different screens of the application. The fix required a small change to the HTML, and that meant I had to alter the JavaScript that was generating the buttons. It was simple enough that, with my limited understanding of JavaScript, I was able to implement the fix without assistance from a developer. Having fixed the button on one screen, I assumed I would be able to pretty much copy and paste the fix into the other screens. However, upon viewing the code, I realized that the code generating the second button was written differently from the code generating the first, even though the resulting HTML was identical.

The two screens had been implemented by different developers at different points in time. Rather than reusing code that already existed in the product, the second developer implemented the screen in his own way. As a result, the codebase became more difficult to maintain. Months down the road, it took twice as long to implement a simple bug fix as it would have if code had been shared.

A well designed user interface, by its very nature, is consistent. A button is represented in a very specific way, consistently throughout the entire application. There may be variations, but the user will always recognize it as a button. As such, a user interface, by its very nature, should be modular. Like a set of Legos, each component should be reusable in different contexts.

This modularity should apply not just to the appearance and behavior of the UI components, but to the code that generates them. If every button in the application is composed of an icon and label contained within a pill-shaped box, there should be a chunk of code that can generate every button in the application when passed the text for the label and the ID of the icon. That way, when the team decides that they want to change the button, they don’t have to implement the change in 100 different places throughout the application. The change is made once within that single chunk of code, and every button in the application automatically exhibits the change.

I complained to the lead developer about the way the buttons had been implemented. During the next iteration, she wrote a function that would generate the HTML to display a button given a few variables, and then it was employed throughout the application. This was when I first started imagining what I would eventually come to call a design system.

[designaday]

There’s Work to be Done

It’s Q4 of 2024, 26 years since Alan Cooper wrote The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, and yet…

I still work with product teams that don’t have UX designers.

I still work with teams that have UX designers in which developers decide what gets delivered to customers.

I still work with product managers who think that they’re the only ones that need to talk to customers.

I still work with teams that don’t understand the difference between customers and users.

I still work with leaders that believe it takes too long, and costs too much, to conduct usability research with actual users.

I still work with teams that consider their designers to be UI producers rather than shepherds of product vision.

I still work with managers that view a designer as interchangeable headcount, rather than a strategic partner in understanding their customer needs and business opportunities.

Maturity is not evenly distributed in industry. We still have a lot of work to do.

[designaday]

What’s Replacing Who Now?

With the abundance of low-code/no-code development platforms and generative AI capable of understanding and writing code, are we entering an age in which designers will dominate the software industry, rather than developers? Let’s ask ChatGPT.

The rise of low-code/no-code platforms and generative AI certainly democratizes software development by allowing people with less technical expertise to create applications. However, it's unlikely that designers will entirely dominate the software industry at the expense of developers. While these tools empower designers to create functional prototypes and even basic applications, there are still significant complexities involved in software development that require deep technical knowledge and problem-solving skills. Developers are needed to build and maintain robust, scalable, and efficient software systems, especially for complex and mission-critical applications. Moreover, design and development are complementary disciplines. Good design enhances user experience and usability, but it needs to be implemented effectively through code. Developers play a crucial role in translating design concepts into functional software, ensuring that it meets performance, security, and scalability requirements. Instead of viewing this shift as a displacement of developers by designers, it's more accurate to see it as an evolution of the software development landscape. These tools empower cross-functional collaboration between designers and developers, enabling them to work together more efficiently to create better software solutions. In this evolving landscape, both designers and developers bring unique skills and perspectives to the table, contributing to the success of software projects.

I like that answer. There’s so much more to the development process than just writing code, and it takes a diverse team to solve the problems that the software is intended to address. Drag & drop app building won’t make developers any less relevant than design systems make designers. As has always been the case, we must learn to effectively use the tools and technology available to remain relevant.

[designaday]

Advice from a UX Manager: Build Bridges

In 2014, I published a book titled Bridging UX & Web Development. It focused on the working relationship between designers and developers. If I were to write that book today, it would include a lot more about product managers, product owners, scrum masters, chief architects, sales reps, marketing, managers, and executives. There's a perspective shift that comes with the move from individual contributor to manager.

Designers are in a unique position to build bridges between all of these people. We have tools and methods that can align everyone to a common vision while at the same time giving everyone a shared sense of ownership of that vision. When people are left out, or worse, blocked from contributing, the road becomes rough. When one person attempts to control everything, that's where the cracks begin to form within the team.

Build bridges between the various roles that make up your team. Empower everyone in your team by providing them with the opportunity to contribute. This can be done through critiques and reviews. It can be done in one-on-ones and quick tag-ups. With the collaborative tools we have today, it can be done with a simple invitation to comment. Be proactively inclusive, even when there's someone you would prefer not to deal with.

Building bridges is better than mending fences.

[designaday]

Design Principle #4

I’m guilty of not realizing this principle in the past. It’s easy to take the attitude that technical issues are outside the realm of UX and not really our concern, but I have news for you.

Software performance is an important component of the user experience.

And while we, as designers, can’t usually solve performance issues, we have to think about performance in the way we design the software. Certainly, if your UI is causing a performance issue, you need to fix it. That’s easy. If there is a performance issue that your team can’t solve, you may have to rework your ingenious UI to avoid the issue. You don’t have to like it, but if your users refuse to use your application because it’s too slow, your ingenious UI isn’t helping anybody.

Don’t get me wrong, it’s often the case that your architect and development team need to do their job and make things performant. But there are all kinds of reasons why that may not be feasible, and compromises must be made. Trust me, performance isn’t a hill you want to die on.

[designaday]

Reminder

A piece of advice I have given before, yet must still remind myself of on occasion: Don’t scorn someone for asking you to provide your expertise too late in the process. It’s not their fault. They're asking, and that’s a good place to start.

[designaday]

Once the “coding phase” starts

A junior designer asked me, “How do you work with developers once the coding phase starts?” Well, I wrote an entire book about that. But I want to point out a flaw in the question: you don’t just start working with a developer once the “coding phase” starts. You work with the developer from the get go. As soon as there’s a problem to be solved or an opportunity to be realized, you should be working with the developer. You should be working with the developer right out of the gate to make sure you have a shared understanding of the problem, its context, the requirements, and the constraints. Because if you’re making a bunch of decisions without the developer involved, you’re in for a world of hurt when you hit that “coding phase”.

But let’s get another thing straight. Whether you’re Lean, or Agile, or some other hip methodology, there isn’t really a “coding phase” any more than there is an “empathy phase” or a “testing phase”. These should all be happening in concert.

You should be working with the developer all the time. Even when you’re not working. You’re on the same team. You have the same ultimate goal.

As for the how, read this.