The Rise of the UX Developer

Oct
16
2011

Various Red coloured fancy dress hats from UX Australia 2011 Day 1

As with any young industry we tend to endlessly debate the labels we should be placing on the User Experience based roles that we are conducting.

Along with this debate on the labels, we seem to be now in a blame game on who really is responsible as an industry (which I had no idea we where) for the on going career development of  junior,  mid level and senior UX people. Maybe better to just fix it folks.

As these elements of navel gazing have been going on quietly in the background the game has been changing.   Maybe For the better.

With any new discipline, well new to the main stream, it will influence other roles as elements of its workflow and techniques become widely known.

Over the last three or so years I have been noticing that there has been a  dramatic tendency to move away from the UX professional to favouring o role more like that of a senior developer or sometimes a BA with UX skills. Not that BA′s doing UX is that new, we all moonlight as BA′s when we can’t find UX work.

Let′s call them a UX developer.

It is not all that bad.

Now I know a lot of you will be a gast at this.  But just think for a moment.

To often as UX professionals we are asked to do the impossible, to be the super UX hero and save the day.

You know the scenario well.  You get a phone call asking for help with a project that is in its final stages.  All they need is a little UX magic to make the project shine.  Familiar?

Now you know it’s way to late in the project for you to have any major influence on any of the underlying flaws in the UX. But you take the gig anyway.

You do it in the  vain hope that you can at least make a little difference and hopefully the project management will learn that the time to get the UX professional involved is at day one, not before launch.

You do the best you can, but you know it’s not going to be good enough.

The watching, learning, mentoring.

Now the senior developer or BA watches and learns from you, maybe you inspire them to go and do a little professional development on UX.  Overall they pick up a few core UX skills.   Which is good.

On the next project these forward thinking devs or BA start to apply these learnt skills early in the process, so at least in part there is some element of UCD with a UX component considered.  Which again is good.

After all they are already a part of team framework – project manager, BA, dev. With someone in this team championing the UX component there is no need to inject a UX consultant into the mix, who is just going to disrupt things anyway.

Now from a project management view the injection of the UX professional just didn’t work out that well anyway. At least now the team internally now has the UX skills to move forward.

Developers control the game anyway.

Yes the UX developer does have at Cooper puts it “skin in the game”.  Yes they are concerned with optionisation of the system, to focus on the best business outcome.

However the UX consultant isn’t the only one that can deliver a non biased view that supports the user cases.   A good BA or UX developer can wear this hat as well. They can be objective they can change hats mid stream.

I have seen this more and more with recent projects.

Afterall we as UX professionals don’t control the projects, the devs do.   Now maybe we should be training and mentoring developers in the UX cause not designers. Which is opposed somewhat to what Nat Boehm has to say.

So overtime maybe the UX consultant will be as dead as the webmaster, a thing of the past.

In the future maybe consideration of the UX will be just a mainstream inclusive activity of the development team.

Things are not Dead Here

Oct
8
2011

coffee at Cafe54

You may have noticed that the output from this blog has slowed over the last ten or so months from at least a post a week to if you’re lucky one post a month. Sorry about that.

I can’t really put my finger on why my blogging output has decreased.

I still like writing, I mayn’t be any good at it, but I do enjoy the process. Writing in this type of format is liberating and can be very creative. Very different from corporate report speak of business .

Still there must be some reasons for this decrease in output:

Increased Workload

Yes it does sometimes get busy, especially on the home (non business) front. Still even business wise I have crazy periods and slow ones. Sometimes for the first time in ages it’s been at a complete dead stop. So I don’t think it’s an overload of work. I always seem to have the capacity for more.

Less Quiet Time to Reflect

The lack of time to stop reflect, to have that down time or moments between, may be a contributing factor. Often during these times I will mentally formulate and draft design ideas and posts. So this reduction of this time would be a factor.

Volunteer Work

The other day I worked out how much time I dedicate to general volunteer work. From organisating two meetups, mentoring people, the occasional presentation and organising the Australian Web Awards. This does take up a lot of time. Often leaving me will little personal time. It’s this personal time I used for blogging.

Lack of Ideas for Articles

Well not really. I have at least three to four ideas for posts every day, most I forget to document, especially when I haven’t had the time to act on them.

Twitter

Well my twitter and other social media output has dropped as well. So that’s not it.

Overall

So it comes down to time and lack of it – doesn’t it always. Seems I’m filling my life too much with volunteer work for others and not enough for me.

Now to do something about that.

The Core UX Reading List

Aug
2
2011

CBD Perth Graf

I get asked this a lot. “What are the best UX books to read?”

In true UX tradition my answer is depends.

It depends on your experience as a UX practitioner, your experience with scientific research methods, psychology, interaction design, user interface design, product or visual design and your level of communication skills.

Still having a list of starter books would be handy.

Yeah sure others have their lists from the likes of Will Evans, Paul Seys and Nick Finck however some of the books on these are either too complex (for someone new to UX) or take way to long to get to the point. Bit like this post.

So here is a list of books I would pick as the must read UX books.

The UX Book List

More Specific Methods and Techniques Tuning

Let’s Get a Lot Deeper and Serious

So what are your killer must have UX books, I’m sure they are few that are different to the list above.

Why Use PDF over HTML

May
30
2011

Stack of 100 year old 1890's books with chess set in the background

As a web professional and an avocate for inclusive design (web accessibility) I have often wondered why organisations are so obsessed with using PDF documents on web sites as opposed to HTML based documents.

After all PDF documents don’t do accessibility as well as HTML pages do.

Given the ease of use of most modern CMS you would consider web page creation and editing would be as easy as authoring a word document.

Now I have a good idea why my clients use PDFs over HTML, especially government agencies, but I don’t have the community wide picture.

So I asked Twitter – “Why do you use PDF over HTML?”

I got a bit of a response.  Now this survey and its (200) responses aren’t that scientific, they are multiple tiered and are as expected, full of statistical analysis holes. Still the results do give us a glimpse as to why people use PDFs.

Now there is no primary reason as to why, but more a mesh of several supporting rationals.  They are in order of preference:

  1. Preserving the Print Format

    The requirement to have the onscreen visuals appear the same as the print version was clearly the leading reason. Out stripping others by two to one.

    This is really understandable when you are dealing with documents having a complex print layout. It seems CSS print styles just don’t cut it. To the point that sometimes having a different style layout for print, for a web page, can be a bit of negative user experience (however that’s another topic).

    Documents that have been through a visual design process of a print production team seem prone to this requirement. Yes the content is the primary focus here,  but sometimes the way it’s presented can be just as important in communicating the message.

  2. Encapsulated Format

    Being able to save and transfer a document across platforms was important as well.

    People are looking for a medium that doesn’t require complex software, that will maintain the layout, images, typeface and all the content as one encapsulated package.

    Try saving a web page for use later, it just fails in so many ways, and a MS-Word document – well that needs MS-Office for the most part.

    PDF is the only one left standing as an encapsulated package, it’s also cheap to read and produce as well.  Issue is it’s not that portable in reality – take the issues displaying or saving a PDF viewed on the web using a mobile device.

  3. Easier to Publish

    Easy of publication is another core reason. To creative a PDF is often just a simple process of saving a document.

    This is easy and within an existing business workflow.  So it’s understandable that it appeals to the vast majority of people.

    To publish it to a web site you just create the link in the CMS, and upload the document. Set and forget, no need to worry about the layout working or not.

    Contrast this with the list of issues using a CMS editor to create a web page.

    You usually create the document in MS-Word and have to cut and paste it into the CMS editor, this causes layout issues. Or you have to use some weird keyboard/process gymnastics to get the layout reproduced right or worse have all the formatting disappear and have to reapply the lot.

    Then you have to put the images in separately, scaled down for the web, and allow for those accessibility tags.  After all this there still maybe layout issues with the page design.    It’s just a nightmare.

    Clearly the web publishing process has a long way to go.   Maybe this is an area some of my fellow UX colleagues could look into?

  4. Existing Hardcopy Documents

    Duplication of existing hardcopy documents is also another core reason.

    When you have an existing hardcopy document, you really are only duplicating the distribution and availability of the document to a web medium.  You are just presenting the document to a wider audience that those that can collect it from your offices.

    The use of PDF with its layout preservation and encapsulated package is the perfect solution for hardcopy duplication.

    In this case people also stated that they tended to only used PDF for duplication exisiting hardcopy documents.

  5. Other Reasons

    The following are minor reasons people stated for use of PDF documents over web pages.

    • Duplicate HTML Content

      A low percentage of people indicated they presented everything as web pages, but also allowed for user driven server side generation of PDF documents as required. Or they just  duplicated all the static PDF information available as web pages. Use of both formats was equally weighted in this case.

    • Providing More Detail

      Others, using the semantic structure of the web, presented summary information on topics at the high level of a site as web pages moving down to specific summaries on mid level web pages and PDFs as the final low level detailed pages.  This is a very typical government model of information communication.

      I suspect while  this may not be prefect, it harks back to having a secondary reasoning for the ease of publication of the detailed information.

    • Interactive Forms

      Despite Adobe pushing PDF forms only a very small number of people even referenced using PDF forms. Sure normal hardcopy form duplication was mentioned. But the use of interactive PDF forms was left to a minority.

    • Low Usage Document

      Just like the use of PDFs for detail pages, documents with a low usage also where seen as more cost effective delivered as PDFs.

    • Web pages not a formal document

      This was a very interesting comment.

      It seems that the very volatile nature of the web page doesn’t make it a highly considered  paper replacement.

      Where as PDF’s, which are just as volatile, maybe because they come from a process close to the formal document are seen as more formal, stable.

      Interesting perception.

    • DRM / Security

      Contray to what publishers and the legal department may tell you;  the use of PDFs to enforce DRM or any type of security is very low on the reasons to use PDFs.   In fact I would presume the usage of security features of  PDF documents is generally low . Which in a way is a good thing – accessibility wise.

This rounds off the reasons to use PDFs over web pages for content delivery.  Still I hope that this continued PDF madness does ease up a little.

However I fear we will not be seeing this real soon, until web publication and print styles become as easy and effective as PDFs.