Meeting Real–World Needs with Pixel-Scale Systems

18 Sep 2013 - 9:53am
1944 reads
shoobe01
2007

Aside from random rantings about philosophy, I have been making some articles on tactics. Lately, I've started a sort of series on tools. The overview: http://uxmatters.com/mt/archives/2013/06/tools-for-mobile-ux-design.php with all the usual suspects like whiteboards, Post-Its, paper and html. 

But today Brian Rieger and I had a Twitter conversation that reminded me it might be good to not just talk about tools but principles of tools. First, here's a recent article on how I use InDesign as my design/specification tool: http://uxmatters.com/mt/archives/2013/09/tools-for-mobile-ux-design-adobe-indesign.php

One thing I sort of skipped over in this is the discussion of scale and units for design and specification. I keep talking about that in pieces. Above, how I design to physical units (because people are in the real world, so touch targets and type sizes and so on need to be designed in real units) but then I never tied it to the rest of the process. So, my general process: 

  1. Design to human scale. Using a scaleable, vector design tool, draw or place wires/screens/comps scaled to full size (1 mm = 1 mm) so there's no conversion, and when you print stuff out it's the right size. 
  2. Make sure everything can scale. Design to a few viewport sizes, at least for one view to make sure if everything just stretches and squishes, then the fixed size items (buttons, type...) work within the fluid components. (Yes, sometimes you have to design multiple sizes, like handset and tablet). 
  3. Validate. Put at least a few of these designs on screens and make sure they work. Whether comp or prototype, check it out at least, test if possible. 
  4. Convert to implementation units. Typographers points (what I mostly work in) need to be converted to pixels, ems, sp/dp, "points," or whatever is used by the developers for that platform. 
  5. Specify. Really, I've been typing this all along, but now put the converted sizes into the annotations, and include references to already-provided images and widget methods (for apps, or frameworks).  
  6. Export production images. Mostly as rasters, and almost always to multiple sizes. Whether for RWD or the 5+ Android sizes, don't let images just squish but load them optimized to look good, and reduce transfer.  

This is mobile centric, but the same is done for desktop webdesign. What am I missing, doing wrong, or how does YOUR process solve the issues of meeting human (real world scale) needs with technical (pixel scale) systems? 

Syndicate content Get the feed