UX design in the SDLC

For a few years now I’ve found myself reinforcing my position as the ‘designer in the dev team’ — UX designer by title, but very much working within teams of software engineers.

The more time I spend in this capacity, the more ways I find to influence the engineering side of things with my different outlook/perspective, but I also see more and more engineering skills/approaches that could be brought back into design.

It has become an ongoing desire of mine to better establish the role of UX Engineer.

Here are some of the ways that I’ve found this role to be valuable on projects.

Note — I use the terms engineer/engineering & developer/development interchangeable — it’s not the best habit I have, but it tends to be how these subjects are talked about depending on the audience.

Bridging teams for better comms

This is one the easier aspects to consider, and it’s also one that makes it easier for others to use when describing the value of the UX Engineer.

By having a foot in both camps (design & engineering) but with a focus on the overall user experience that is to be delivered, the UX Engineer can work towards better understanding between the 2 teams — at the very least by translating the concerns from each of them to the other.

This could be ensuring that there are more organic conversations happening between designers and developers, having them actually talk to each other more regularly in order to establish some rapport, but also to get an appreciation for each others roles in the final outcome.

When I’ve been able to talk through a design with the developer I get to show them the visuals and set my expectations for interactions. This is a common approach, but less common (in my experience) is for the developer to playback their efforts to the designer.

When I’ve been able to go through this, it’s always led to a better, more robust outcome. Yes, in some cases there is the need for compromises — but in the way, we talk about them and can agree on the approach together, rather than having one team dictate to the other. That’s not fun for anyone.

Do you remember who we are building this for?

The ‘User’ part of the UX title is one that often needs to be highlighted again and again.

I know that it’s easy to get drawn into the functionality that’s being created, that’s the creative and fun part of the process for the developer, but it can’t be to the detriment of the user. They’ll be the one that will be using this after we are done — and in some cases, this might be the only tool they can use to perform their task/job.

By taking a user-centred view during the different stages of the software development lifecycle, UX Engineers can surface opportunities for making the engineering work more user-centred.

URLs, file/folder structure and names, error messages, responsive design and more are all areas that can benefit from some user consideration, yet these are often the realm of developers. By feeding into these aspects, we can help to establish some of the foundations and structures to work within, freeing up others to put their efforts into their area of expertise — I’m sure we all know how much fun it is trying to come up with the names for things as your working on them!

The UX perspective can offer up a more holistic view here and keep the codebase more tightly coupled with the users world, rather than that of the engineers working on it.

Let’s not forget that the developers are users too! By taking this into consideration, we can also aim to keep things understandable from the beginning. This effort works to help keep things easier to maintain in the future, or easier for new joiners to get up to speed and understand how things work on the project.

Crafting the final piece of development is vital, but we can all benefit from taking some consideration of the various users of it along the way.

Designers can learn something too

Having spent a lot of time writing code, and enjoying doing so, I’ve picked up lots of little tips & tricks along the way that allow me to be as pragmatic as I often am when it comes to design. I have an appreciation of how things are done which I’m able to factor into my design work/thinking, leading to more realistic and practical ideas being explored.

Should all designers learn to code?

No! Absolutely not!

However, those like myself that are doing Interaction Design and especially those that make use of tools like the GOVUK Prototyping Kit will find that they can bring so much more value to their teams by getting a firmer grasp of some of the concepts and approaches that are applicable.

Being able to craft intelligent prototypes that lean into the engineering methodologies and implement components and dynamic content/data to allow for a wider range of outcomes is the sort of thing that makes it easy to:

• Demonstrate functionality to stakeholders (not just developers)
• Provide realistic experiences for user testing
• Allow others to easily re-use pieces of your work to help speed up design & development more broadly

The tools & techniques are there, but they aren’t obvious to most of us — and when they are obvious they often appear to be much more intimidating than they need to be.

Dev skills for designers! I wan’t to see more of that, and I’ll be seeking it out myself — not only the skills to be fostered, but also how to present those skills back to other designers so that they too can embrace them and level up their own capabilities.

Unicorn mythology

Combining these skills inevitably conjures thoughts/ideas about the UX Unicorn, able to design & build products and just deliver everything themselves.

No one can do this — at least not at the same time, and probably not even on the same project, moving from one phase to the other rather than iterating into the next within a single discipline.

It would be foolish to think that no UX Designer that learns some solid software engineering skills could potentially switch careers and focus on engineering instead. That’s potentially a risk for those that empower their designers to get these skills, but the potential rewards are just as potent — if not more so.

UX Engineers (by my definition) aren’t software engineers. They/we might use some of the same tools and processes, but the outcome that is being delivered is different for both roles. Both are valid and they can thrive when enabled to work together, but I believe that there should be a distinct UX Engineer role to be able to keep things user-centred.

Originally published at https://lifeinux.com on February 12, 2024.