I saw this post, by Erik Flowers while scrolling the LinkedIn feed which resonated with some thoughts that have been floating in my mind without anything to latch on to. But now those thought found something to root.
I am currently working as a "software engineer" (commonly also referred to as "frontend developer") and although I like to label myself more as an "interaction developer" my main domain consists of designing software architectures and writing code. My background has always involved some level of getting involved with the user experience (UX) aspect. And while that may seem something that sticks out, I feel it is both to build good software and unfortunately also something that is not commonplace.
From my educational background, I've followed a curriculum that used to dedicate equal amount of time into domains that can be summarised as software, design and communications. A perfect mix of complementary disciplines I think. From that background, and my experience as being part of different software building teams and organisations, gives me some credit in weighing in a bit.
So what's all this fuss about?
Well, as Erik points out, UX is not the same as designing a pleasant interface. It is, as the name implies, all about the user. And more specifically, about how the user experiences your product or service. With that emphasis, it is actually very strange that UX is so misinterpreted by so many. We've all seen profiles like "interface designer", "frontend engineer", "backend engineer", "quality assurance", "data analyst" arise, because these are important roles when you're building software from the development perspective.
But who are we building software for?
Exactly.
Focusing on the customer is focusing on where the money is. It is, from that context, very strange indeed that we even allow to hire UX positions and allowing them to do pixel pushing in creating visual designs!
So to my mind, and since it seems nothing is set in stone, we can start to "armchair imagineer" what a UX should contribute to software development. I am personally inclined to think the discipline spans everything dealing with users and should be an omni channel discipline. For the sake of this argument however, let's focus on creating software.
I actually have a lot to work with already, since Erik wrote up an excellent article on Medium where he lists some desired responsibilities:
- Field research
- Face to face interviewing
- Creation of user tests
- Gathering and organising statistics
- Creating personas
- Product design
- Feature writing
- Requirement writing
- Graphic arts
- Interaction design
- Information architecture
- Usability
- Prototyping
- Interface layout
- Interface design
- Visual design
- Taxonomy creation
- Terminology creation
- Copywriting
- Presenting and speaking
- Working tightly with programmers
- Brainstorm coordination
- Design culture evangelism
This is quite an extensive list, but I'd like to make it even longer, because I feel it is coloured by a traditional "design" background. I'd like to add the following, which has more of a technical background:
- Drafting performance budgets
- Security policies design
- Responsive design
- Support advocate
- A11y advocate
- Progressive Enhancement advisor
- Search Engine Optimiser
- Design / developer facilitator
- State architecture design
I have a feeling there's an even bigger extent, but these topics cover a lot of ground already and serve a secondary purpose. I can't speak for the responsibilities that Erik lists, but let me explain what I mean with my additions:
Drafting performance budgets
We know that performance is a driving factor in how a user perceives software and how it heavily affects their behaviour while using your product.
Security policies design
Nothing impacts the brand value more than a data leak or breach where users find out just how much of their personal data was handed over in good trust. Damaging this trust could potentially lead to devastating damage to your softwares and organisations reputation.
Responsive channels design
I'm not just talking about how a component or website scales in a web browser, but also how it scales across platforms. Are you exposing key features on web and also an app? Also for a smart watch? How about voice assistants? Responsiveness means being able to react to different platforms just as much as the size of the platform. This segues nicely into the next one:
Support advocate
If we support across apps, are you considering the different types of agents and devices using your software? A low end phone has less resources than latest flagship models. When serving web environments, what browser memory can you work with to have a decent experience?
A11y advocate
Bear in mind that 15% of the worlds population has some form of impairment. 3.44% Of the worlds' population has some form of visual impairment. That's 275 million people. Doing exclusively layouts and pixel pushing is a solid means of excluding users. That why accessibility matters and plays a vital part in your software. Generally, a11y scales well with UX.
Progressive Enhancement advisor
For all the bells and whistles in your software arsenal, you'd have you consider how you could improve a users' experience with embedded technologies, or how to fallback when some technology is not supported.
Search Engine Optimiser
One of the important entry points to any web application is organic search results. Therefore, one of the important users, albeit a non human visitor, are crawlers. How do crawlers perceive your software? Do they encounter errors? Duplicates? How do you deal with those?
Design / developer facilitator
Okay, here I might have some overlap with the "Working tightly with programmers" point, but I feel it's not just important that the UX person has a tight relation with programmers, I think it's just as important as designers (as well as any other discipline).
State architecture design
When you have multiple platforms in your domain, how do you deal with or handle the current state of what the user is doing? Do you have silos or are platforms able to take over the tasks of their counterparts? How is that managed and what part of the state is shared?
Support advocate
Who makes the decisions on what platforms and technologies to support? Are you doing native iOS but not Android? Does dat mean that Android users get a web app? Does a web app offer the same kind of user experience as an app?
The purpose
So, as I was teasing before this list, it's extensive for another reason: there's no way that a person can do all of these things. It doesn't mean that the list is too long. It means that user experience is embedded in basically everything that we do while building software.
I could even argue that the Developer Experience (DX) is also part of the UX responsibility (it's just another type of user, right?). Including the DX means writing docs, guidelines, linter rules, pipeline optimisation, git flows, automation, backup strategies. The list goes on (I can do this all day).
Now what?
So this is a problem. The field of UX can be defined as "everything", simply because everything we do has some form of effect on the user. Otherwise there's no point in doing it, right?
In my mind, the way that we could make this work is by adding a bit of UX awareness to every software building discipline that we have, where we assume that with some education and understanding, we can improve the UX while coupled to the teams' efforts in an iterative way. Step by step, building on the expertise of domain experts. There are gaps to fill obviously, since we'd need to educate those domain experts, and then still they will not have all of the resources or knowledge to say, conduct a face to face interview.
For me, this could lead to a UXer being a coach or mentor to a team. To help them guide the decision making process, facilitate communications and help with understanding the users' needs. On top of that role, there should still be room for doing the specialties, such as the face to face interviews, taking the lead in user tests etcetera.
The list of responsibilities is long. We could draft long lists of tasks for developers as well and we don't expect them to be experts in everything, because we expect different specialisation from developers.
Change the paradigm
I agree wholeheartedly with Erik that the "designer" moniker does not cover the responsibilities of a UXer at all. Get rid of it. Taking the list I see just as much tasks that tie to an architect, facilitator, manager, advocate or analyst moniker. The UX Designer concept has been rooted in our minds with the wrong meaning, so we should change.
All you UX "Designers", I challenge you to pick a new title. One that suits your specialty but please don't call yourselves designers anymore.
Top comments (0)