Coding Best Practices as UX?

Question

I've been stating in most of my recent contracts that meeting HTML coding Best Practices (what's outputted to the browser) is an important part of UX.

This would include things like Semantics (using headings, paragraph tags, captions, etc.), meeting all accessibility standards (alt tags, labels, table headings and for advanced ones scope..., etc.) and valid HTML/XHTML.

I've been getting push back that these things aren't UX, that they're code practices and unrelated. That when I do QA reviews I should be concentrating on usability and consistency of design and not worry about coding practices.

So, am I out of line here and misinterpreting scope?

Answer 1

"and unrelated"

EVERYTHING that goes into building a successful web site that meets the needs of the users is related.

There's a tradition, it seems, that anything seen as 'code' is immediately given to IT. That separation is rather silly and, IMHO, a remnant of antiquated waterfall development practices.

The way forward that I feel is the most agile and appropriate is that UX (as a team) would be responsible for everything including the presentation layer code (CSS, JS and HTML). They'd then work extremely closely with the back end IT teams going forward.

Politically, that's going to be a fight in a lot of organizations.

(related to this is Marketing, when they think they own the content outside of any UX involvement)

Answer 2

I'm on your side here.

The items you mentioned are coding practices that directly affect the user experience. If you don't stick up for standards no one will.

Other coding practices relate to maintainability and stability etc and that's something the development team can look after on their own.

At our place, the UX folk sit with the front end developers, which is highly recommendable in my opinion. Not only can we easily review code with them, but they can also show us the latest technological developments to keep us up to speed.

Answer 3

I believe the same thing you do; that proper semantic markup improves the UX of the website.

Nevertheless, to directly answer your question: I do believe you are misunderstanding (or probably more properly miscommunicating) the scope defined between you and the client.

So if I might take the liberty of doing my best to answer the question I believe you’re actually asking ("how do I communicate the UX benefits of semantic markup?"):

Since markup seems to many customers as "code" (a necessary evil, not the thing they're paying for), you need to focus on the way those semantic markup principles and accessibility improvements can affect the user's actual experience. You might, for example, like to get a copy of JAWS (on Windows) or set up VoiceOver (on Mac) and demonstrate how applying a strong page hierarchy using headings allows for much simpler page navigation for the blind, and how alt tags make content images meaningful for them.

When I'm communicating the benefits of microformats to customers, I like to use an extension to demonstrate how search engines, future browsers and other content consumers can benefit from proper markup of things like hCards and hCalendar.

You can also demonstrate the document outline using extensions to show how the user's actual interaction with the page can be improved using proper outlining semantics.

The last suggestion I have is related to link types such as link rel="next": there's a Firefox extension called Link Widgets that provides in-chrome navigation of pages in a site. You can also mention with these that browsers can improve the UX through prefetching when you include these links.

Answer 4

Why stop with HTML coding best practices?

Back-end scripts need to be readable and immediately accessible to their users (i.e. everyone in the development department - especially the developers who may not have written them but will end up supporting them).

Nothing screams "unmaintainable" more than uncommented scripts full of classes, functions, and variables with names like "z" and "foo".

Answer 5

Anyone who pushes back and says these things arent UX doesnt understand UX.

Managing a good UX goes beyond HTML and CSS coding standards, it extends to scripts, to connections with back end system, to quality of images, downloadable files.

As an example. I worked on a project where the front UI was technically accessible and the visual design had tested well in usability. When the site was connected to its back end database the performance was so bad, all the front end benefits didn't matter anymore, the overall UX was a disaster. If I was to ask the database administrator they would say their database is fine, the network engineer would claim their was nothing wrong with the infrastructure, the hardware guys wouldn't accept that the servers might have something to do with.

No one part was actually to blame, but instead of looking at the individual components, stepping back to the overall experience that was expected gave everyone an ability to work on improving just their little bit of the picture.

If you're getting push back, push back harder.

Answer 6

Usability does not stop with the user experience. Extending usability to our code can provide a number of benefits. higher code readability, quicker changes, and simplifying the process of ensuring user usability.

Useful read: http://www.terradoncommunications.com/shared/content/whitepapers/TCG%20-%20Usability%20Best%20Practices.pdf

Exploring Usability Enhancements in W3C Process http://www.w3.org/2002/09/usabilityws.html

Usability, Accessibility and Markup http://www.w3.org/2005/Talks/11-steven-usability-accessibility/

Answer 7

Here's an article that might give you some inspiration to keep up the fight

http://www.inspireux.com/2010/07/05/challenging-conventional-assumptions-about-user-experience-design/

Answer 8

I'm front-end developer and it really gets on my nerves when people without technical knowledge say that something has to be like they want, because UX requires it. What usually happens -- every page is different, therefor the CSS file if bloated with modifications of excisting elements, JavaScript file is bigger than CSS and HTML combined and HTML is illogically structured. The reason for this is simple, UX designers do not understand what is HTML, CSS or what are JavaScript possibilities, the outcome is buggy, slow and bloated site. If UX people would understand why keeping code minimal, re-using CSS and JavaScript is good, they would change their "beliefs" -- it is possible to to make correct, easy, comfy websites using best practises of back-end, front-end coding and UX.

UX designers, you have to know this kinda things, otherways you end up just like internet marketers -- the enemies of all-end coders :)

Answer 9

Are you misinterpreting the scope? It depends on what your job description really is.

Are you out of line when it comes to making the UX better? No, as long as you don't fail to pay attention to other tasks as well, like usability and consistency of design that you mentioned. With those, you've covered accessibility and usability so don't forget about stuff like IA and IxD, if that's a part of your job, of course.

Answer 10

There are obvious advantages to ensuring that code and mark-up quality is high, and all organisations should do their very best to ensure that their internal cultures promote good practice. However, having said this I'm afraid I disagree with your central premise.

There's a reason we have roles in any organisation - it's unproductive to say that markup quality is the responsibility of the UX team.

From the user's point of view - semantic mark-up drive the technologies that the user has exposure to. That is the extent of the user's exposure to mark-up.

There are layers between the user and mark-up, which are part of the remit of the UX team.

Think in terms of the affordance sematic markup provides designers. If the things you require from a website require semantic mark-up or use of microformats, then state those requirements (e.g. consistency of design can be met through use of semantic markup), but in my opinion you should not put the horse before the cart.