Re: [IxDA] Direct to Code Wireframing

15 Sep 2010 - 12:40am
5 years ago
1 reply
862 reads

3. I have worked in shops in which designers threw Photoshop files, JPGs, or something similar over the wall to developers.  Because of the differences in emphases and priorities between interaction designers and developers, the results were generally disastrous.  Of course, this is the extreme end of the spectrum, but hopefully, you get the point.

4. All that said, I strongly recommend the interaction designer create the HTML and CSS.  I know for some IxDs, this might smell and taste like coding, but in my experience, without the IxD doing so, the user loses -- in some cases, a lot -- and that's what we're here for:  to advocate for the user.

5. Some tools might create a good start to HTML and CSS, but I would never leave to the tool to do so.  I'd always check its work.

6. I have even created unobtrusive JavaScript widgets myself, not leaving that to developers either.  I know I'm a picky SOB, but again, developers general won't think to or won't know how to make sure the interactions are free from problems.  And it can easily be argued that it's not their job.  For example, I created my own suggestion box (auto-completion widget) years ago.  You've probably seen many examples in which this type of widget had major usability issues.  Even the one in iTunes (the song information editor) has problems, because it forces letter casing, despite what the user types.  By creating my own, I was able to test it and discovered problems I coded.  It was a very iterative process before the user even saw it.  As another example, consider an icon list that is supposed to act like your normal "select" HTML list.  Would a developer think to make sure Alt-down-arrow pops up the list for personas who use the keyboard extensively?  Not likely.  And I know this is <em>way</em> too close to coding for some.

7. My bottom line is this:  If you have it in you, and it's practical in your organization, create as much as you can for the user, because it's in your best interests, and yours are the user's interests.  I like dom.latham's suggestion of partnering with developers if this is not possible or practical.

Am I understanding you right that you mean it's better for interaction designers (and maybe ux designers) to have a technical background, or at least deep technical knowledge about how his/her interaction patters are implemented in code?  

You don't fear that this can hurt the design, in the way that the you know too much about the implementation model?
Me, I started in the engineering department and I often wonder if my deep knowledge about technical stuff will stop me from becoming a great interaction and ux designer.  If it will stop me from thinking outside of the box.


15 Sep 2010 - 9:57am
Paul Pinkney

Good questions.

First, what I'm referring to is limited to the front-end design.  For example, most developers -- at least most of the ones I've encountered -- wouldn't take the time to make sure all of the accessibility bits are in place, or make sure the tab ordering makes sense, or adds sensible keyboard shortcuts, or makes sure the layout is as liquid as possible, or that the interaction with a custom widget doesn't have the usability flaws that an interaction designer would painstakingly sort through and test, and the list goes on.

Even developers that take an interest and even pride in understanding these issues generally -- and again, I'm generalizing -- don't have the background to make sure all of these things are covered.  They generally want to make sure the application works and performs well.  That's what is in their self-interest, generally, and rightly so.  In many organizations, that's what a developer is "graded" on.  Further, it's often a matter of allotted time, and schedules are getting tighter and tighter these days.  If developers have a choice between getting a bug fixed, optimizing performance, or any other technical issue and getting the usability details in place, the technical issues will take precedence.

So I'm not referring to the complete implementation model, but you have a good point about that, in that it can limit your thinking if you're not careful.  What I'm talking about is HTML, CSS, and JavaScript as a means of the user experience designer or interaction designer creating the best possible web-based customer experience (assuming, of course, those are the technologies you are working with).  In fact, I often feel liberated -- like I can think more outside the box -- because if I come up with a widget or other design element that would probably be considered difficult to implement, I can just create it and test it.  I've created quite a few design elements that the powers-that-be would likely have shot down due to time constraints, but because I have a passion for such things, I just made it happen.  (Admittedly, I've also done a fair amount of overtime, thanks to my passions for such things.)

Also, the devil is often in the details, and the likes of us are the only ones who are going to make sure those details are discovered and implemented for the sake of our users.  (Plus, when you throw HTML, CSS, and JavaScript over the wall to a developer instead of a JPG or a spec, he or she will love you.  ;-)

I admit that this is where the line gets very blurry though, and each organization needs to decide how they want to do this hand-off between design and development.  And it depends heavily on the skills and passions of everyone involved.  However, I've looked at a lot of web applications (my particular specialty) and web sites, and you can see quite often where the design was there, but the implementation made it difficult to use or just plain clunky.  I personally believe that the more designers have a hand in the front-end design, the better the experience is going to be for the user.  Well, I have to caveat that statement:  Just like all things, you need to have a predilection and passion for it.  If you don't, sadly, you might make things worse.

Syndicate content Get the feed