There seems to exist a stark distinction between developers and UXers nowadays: you are either a developer or a UX practitioner, right? Well, as usually happens, times they are a-changin’.
And that’s why you’ll probably need the Developer’s UX Checklist.
User Experience is Now Paramount
It’s been more than a decade since a single device effectively redefined what software user experience should be. The iPhone proved that software should provide a seamless experience, as can be seen in the billions of pockets that now carry the device or one that is similar, in both form and function. In essence, it changed the perception of what software should be and user expectations changed… forever. We can either be talking about a mobile app or some sort of enterprise system, but every piece of technology needs to comply to the usability standards the iPhone inaugurated. If not, it risks falling into obsolescence.
This kind of software user experience is not easy to create. It takes a concerted effort of several professionals to achieve that experience, particularly UX practitioners. The bad news is that there are not enough UXers to go around. So, while the demand is higher than ever, the supply struggles to keep up. If the software being created now needs UX direction, that is a problem because supply must meet demand.
IT Skills Shortage and the rise of Low-Code Platforms
It’s not only UXers who are hard to find. The increasing use of technology and enterprise digital transformation efforts have created a need for more IT professionals. Due to this lack of skill set, low-code platforms, like OutSystems or Salesforce, have been gaining momentum.
These low-code platforms abstract technological intricacy, leaving developers more focused on solving the problem than on taming the technology required to accomplish it. The platform is there to make them more productive.
Due to the speed at which developers are now enabled to work, if they don’t think UX and take part ownership of its definition right from the start, it might just fall behind. If usability is nothing but a second thought, you need to be afraid: very afraid.
Developers as Aspiring UXers
When developers work without detailed direction on an application’s User Interface, they need to consider a different perspective: It’s not about “getting that new select box in the page, answering to the business requirement, or running without errors”. It’s about “not ruining the experience for those 1,000 people that use the form 100 times each day”.
This is easier said than done. Developers were not trained in this aspect. Usually they don’t quite know where to start.
Adopting a New Perspective
Working with developers in this regard, I’ve found that there are a set of questions which can lead them in getting a new perspective and, eventually, in creating a quite acceptable experience. These are entry points to a whole new way of thinking about software, at the development task level.
The questions are posed at 3 different moments: as they start a development task, as the task being developed and after it has been completed.
Before starting a development task
Why do users come to this page?
First, developers need to learn why users come to the page. That will give them context to support the user in attaining the page’s goal – while not making their life altogether impossible. This deceptively simple question is usually met with oblivious faces. More often than not, developers will start the development on a page, without ever picturing what that page is for. In doing so, it is a matter of luck whether that page is rendered usable or not.
For example:
When deciding on the 10(!) fields that go into the list on a page, out of the 100 database columns, it will be critical to learn why do users go through that list. What are they looking for? What aids their decision process on the record to drill down on?
What are the users trying to accomplish?
Users don’t wander through screens aimlessly. There is a trigger in their world that eventually leads them to a particular screen. What that trigger is, and what data it carries, can make a world of difference in how it responds to the user needs.
For example:
If the action that pushes the user to use this application feature is an email with a product code, maybe it would make sense to allow them to search for product by, say, the product code, instead of searching for name.
How often do the users do this?
If the users will be performing an action every day, several times each day, then they are frequent users. We need to aim for efficiency, as they’ll learn how the application works, through repeated use. We need to reduce any point of friction, support keyboard shortcuts or even bulk operations.
If the users will mostly be first-time users or sporadic users, aim for simplicity and intuitiveness. Put less on the screen and provide more direction and supporting content.
Example:
If this is an ecommerce app and the user is filling the details for an order, ask for each thing in its own step and provide enough assistance for the user to make progress with confidence.
If the order, however, is being made by a broker, inputting dozens of items, dozens of times a day, you probably should consider putting it into a single page with bulk operations. Excel upload, maybe?!
As It’s Being Developed
Are you being tidy?
An interface which is incoherent and poorly laid out, with misaligned elements, affects the users’ trust in the application. This results in the loss of perceived quality, independent of the magic you’ve done under the hood.
Example:
Would you make a purchase in a website which has a broken layout and is full of confusing information? Probably not! If this supplier is not worried about having the basics set, we can only wonder what else is not there.
Are you being consistent?
Validate if you can use an existing application pattern. Make sure you call the same things by the same names. Make sure you put the same type of actions in the same places.
Rationale:
Humans are great with patterns. They allow us to process the huge amounts of information thrown at us at every moment. That information fits patterns for which we already (unconsciously) have an understanding for. If the information follows inconsistent patterns it will force us to rationalize every piece, making it overwhelming. An overwhelmed user is a frustrated and tired user. This is the kind of user that doesn’t usually evolve to becoming a customer.
Are you populating fields with realistic data?
If you’re unsure what the fields will display in the end, you won’t know how the app will work. Make sure your displayed data is clean and easily readable.
Example:
All of us have come across imaginative data on the development and quality environments, like “test1”, “test2”, “aaaaaa” or even “David’s paying lunch…”. The danger of not using realistic data is that the layout will be pushed around with the real data, moving and hiding elements which might prove important to the end experience.
Wrapping Up the Development Task
Is this a main use case?
If this is a critical function of your app, then take a few steps back from your workstation and bring in someone else to run through it. That will reveal very important and detailed insights, which could prove critical to the application’s success.
Ideally, you should be performing some usability tests. Learn more about them, and give them a shot.
Example:
When additional context is absent, we tend to develop things for ourselves. And we are usually far from the end user’s typical profile. Just having someone else trying to use our masterpiece, with minimum background, can bring a huge amount of insight and can lead to a paradigm-shifting experience.
Is it not a main use case?
Just do a quick walkthrough with a colleague, then. It will surprise you how much you’ll get out of it.
Example:
Do you know the rubber duck technique? This is similar. As you explain your brand new interface to someone else, necessarily creating a new perspective over it, you’ll see new things.
Are you proud of what you did?
Would you take credit for it in a meeting? Would you stand by it under criticism? If you don’t care about the end result of what you’re doing, then the UX is most probably lost.
Example:
From experience, there are developers who don’t really care how things come up in the screen, no matter how much we talk to them or show the lacking end result. In our experience, the best option is to move them down in the stack, getting them the further away from the users as possible.
These simple questions and directions can drive developers to a new path, having found new meaning in their work. The developers that truly embrace the UX perspective will be the new rockstars of tomorrow.
The increasing use of technology and enterprise digital transformation efforts have created a need for more IT professionals with UX skills. This is the place to start.
You can find a printable version of The Developer’s UX Checklist
