[I am not changing the original question as there are valuable answers here. but the research I was conducting is now finished and results are published here

and http://hci.me.uk/jqueryperformance/

Original Question:

I am trying to put together a paper about how to go about researching the levels of awareness about jQuery performance between Interaction designers. Performance is a vital part of user experience and jQuery is the most widely used tool for making web-based prototypes.

Prior to designing this survey completely I would like to ask 2 questions from practitioners who use jQuery in their work:

  1. In your opinion how much as an experience designer you need to know about web front-end technologies and jQuery?
  2. How important computational performance is to you compared to perceived performance?
  • 1
    For this to be a valid Stack* question you're going to have to ask a few specific questions. It's also hard to comment on your survey without seeing your survey. I'm also not entirely sure what your ultimate goal/objective is. – DA01 Apr 4 '11 at 14:47
  • Edited as you advised but I probably by far have asked the least interesting question in the history of stack exchange – Ali Habibzadeh Apr 4 '11 at 16:12
  • "This survey" link (jqueryquestionnaire.pdf) is broken (404). – Chris Morgan Aug 15 '11 at 12:47
  • Hi Chris, this was addressed for you – Ali Habibzadeh Aug 15 '11 at 13:04

It looks like you're mainly looking for opinions. Looking at the sample survey, I'd say you'll have some challenges. The first is that I don't see a lot of UX groups will well staffed front end developers. IMHO, that should be a requirement for a UX team, but, alas, I don't see it as much as I should.

Secondly, for rapid prototyping, people likely aren't unit testing at all, nor perhaps caring about fine tuning jQuery selectors. That usually falls onto the development side. Again, I think UX should be developing the front end code but usually that's not the case.

As for the sample questions, it appears that you are primarily looking to see if they are aware of basic jQuery optimization techniques (selector specificity, element caching, etc.). Good questions, for sure, but likely not a primary focus of UX (again, even though it should be).

Finally, there are aspects of front end development that may appear to be a performance hindrance for the end-user, but offer internal development performance increases, which, in turn, can be a benefit to the end-user. I suppose it could be called pragmatic performance tweaking.

For instance, I will often traverse up and down the DOM to build a jQuery interaction rather than using strict IDs for each element and passing it into the script to make it easier for our non front-end devs to implement and reuse. A slightly slower browser experience (though admittedly perhaps imperceptible) but a definite boost to internal development speed.


Xgreen, thanks for cleaning up the original question. To add some more specific answers:

Question 1: The individual designer perhaps does not need to be a front end developer, but front end development is a core component of the UX team's toolset. I've found that UX teams that do not do their own front end dev, or at least front-end prototyping, their solutions tend to be dated and not leveraging the full range of technologies and techniques available to them.

I also find that it's simply impossible to design every detail of every interaction on paper only. You really need to get into code to fully understand the entire user experience and adjust as needed. To fully design the user experience, you need to build it.

Question 2: This is a tougher question to answer. See my answer above. There's a lot of 'well, it depends' with this one. Both real and perceived performance issues are important to address within reason.

  • Thank you for your insightful answers. I also believe that realistic design decisions are not possible without fully apprehending the capabilities of the medium we are designing for. I will probably add a new question regarding whether practitioners think it is their area to know such things or not. perhaps it's some of them who voted me down! :) – Ali Habibzadeh Apr 4 '11 at 21:03
  • I'll give you a +1 to even things out. But yes, I think that last question is actually more interesting for this crowd: should UX people and/or teams be adept and front end development? – DA01 Apr 4 '11 at 21:05
  • I downvoted you because your question was vague, but I'm removing that downvote now that you made it more concrete. – Rahul Apr 4 '11 at 22:45

On the first question, knowledge of how html, css, jquery and even Sencha ExtJS (we use that here) works is key to havng a good relationship with the front end engineers. I also try to know how basic SQL and databases work. I sit in the middle of engineers. A good relationship with engineering is as important as that with product managers. The more we can talk the same language, the better.

Regarding performance, perceived performance is much more important than raw numbers. However, you need raw numbers to measure improvements .

  • Fascinating stuff! I guess based on your personal scenario as an interdisciplinary practitioner you are able to translate business objectives into design solutions but also those solutions well fit your development team as you know their technical capabilities and the technologies that they work with. Which is pretty much my argument in the paper and the reason for doing the survey, to find out how many people like you are other there and how many think otherwise. – Ali Habibzadeh Apr 5 '11 at 2:24
  • But as for the performance statement, I beg to disagree, as computational performance and perceived performance are both aspects of user efficiency and subsequently user experience. And although these two aspects of user experience are heavily intertwined, sadly the general misconception is that computational performance is the concern of front-end developers and perceived performance is what interaction designers should focus on. – Ali Habibzadeh Apr 5 '11 at 2:27
  • 1
    I tend to argue an interaction designer should be able to work as a front-end developer. Granted, one issue is the fuzzy job titles we use in this industry. I've always preferred 'a bunch of smart web people' being the UX team. Specific titles tend to silo people way too much. – DA01 Apr 5 '11 at 3:26
  • Unfortunately this separation sometimes is also heavily publicised by people who have a lot of influence in the field. I recall that in 2009 Mr Garrett gave a lecture on the state of user experience. In his lecture is said “If you're going to be a designer you have to define the medium within which you design. But as we look at the world of user experience this point of view starts to seem a little bit outdated. I call this approach "mediumism," and this is the way that a lot of design schools still teach design – medium by medium” – Ali Habibzadeh Apr 5 '11 at 14:28
  • Designing interactions is an endeavour by human to implant predetermined forms of engagement in an interactive system in order to support the tasks its anticipated users are expected to accomplish using that system. Similar to humans, the state of interactive systems is also dictated by the conditions of their existence. Subsequently designing interactions and experiences for an interactive system cannot derive from a realistic perception of that system unless the designer has an in depth understanding of the capabilities and attributes of that system. – Ali Habibzadeh Apr 5 '11 at 14:29

Concerning 2):

As a user, I don't care what the real performance is. As long as it feels reactive and fast, and it doesn't delay me in realizing my task, it may take as much CPU computation as necessary.


  • Word is giving the feedback: document is open, you can start working - yet, in the background, he may still fetch the pages 100-200.
  • iPhone shows an cached image of how the app will look like, when loaded, until this app has completely started - which doesn't take longer than the opening animation, most of the time
  • That's also why you use progress bars and the like: to give the user a sense of control and thus, the feeling that it takes less time (e.g. Gronier/Gomri 2008).

(I was saying, as a user, as the developer in me does worry of the computational performance, but rather to look ahead: how much more can I do with it so that it remains fast enough?)

Not the answer you're looking for? Browse other questions tagged or ask your own question.