What you need to know, to be a UI Designer

Clearly, it is holiday time

Clearly, it is holiday time as I write this.

Not too long ago, jiatelin5 asked in a comment what books and lessons I recommend for brand new UI designers.  Since I get this question a lot, I thought I’d make it a post.

Becoming a UI designer is a lifelong process.  I’ve been doing it for 16 years and I’m still learning.  You need to have some soft skills, which I’ve described in a previous post.  In addition to these, you need to be very good at communicating, and you also need to have some technical and artistic skills.

The very minimum

  1. Learn HTML & CSS.  If you don’t understand how web pages work and how they are built, you can’t possibly hope to design them.  My very favorite resource for this is Code Academy, but there are also good books out there – don’t be afraid to buy the latest edition of HTML for Dummies.
  2. Learn Photoshop.  There are plenty of design applications out there, but if you only ever learn one, learn this one.  The reason: once you can use Photoshop, you can use any of them.  The bonus reason:  employers will search for this skill in your resume, and if they don’t see that you know Photoshop, they might not even consider you regardless of what you do know.  All the photoshop books and tutorials have their benefits, but feel free to check out Photoshop for Dummies – pick the edition that matches whatever version of Photoshop you can get your hands on.
    There is a great forum on the adobe website set up just for Photoshop newbie questions – check it out.
  3. Learn basic typography.  There are a lot of great articles for this, and some of my favorites are from Design FestivalSmashing Magazine, PSD Tuts and 24 Ways,   There are a lot of great books out there for typography too – start with The Elements of Typographic Style and move on to whatever holds your interest from there.
    The 24 Ways link above is particularly important because you need to understand vertical rhythm in order to design sites that make users comfortable.
  4. Learn basic color theory.  Unless you intend to be designing in black and white forever, you’ll need to understand when and why to use color.  Check out these articles: Color Theory For Web Designers,  Basic Color Theory.  Ignore anything you see about what colors mean because they will differ for each culture and demographic.  Red means one thing to the chinese, another entirely to americans.  It means one thing to older americans and another to teenaged americans.  So just forget all that temporarily.  Read The Principals of Beautiful Web Design.
  5. Learn about layout.  This is something you’re probably going to get instinctively, or never really get at all – but there are a lot of articles and books about it so even if you get it instinctively you need to read them to be able to explain yourself and make wise choices.  Start by researching Responsive Web Design and follow it wherever you want.  As long as you start understanding layouts from the responsive web design standpoint, you’ll be fine. Interactive Media Center has a pretty good approach to layout, although the site is a little dated.
  6. Get a feeling for producing UX deliverables.  At the very minimum, every UI designer needs to know how to make good wireframes, low-fidelity mockups and high-fidelity mockups.  Depending on where you go to work, you might also have to write styleguides or work from them, write specs or PRDs, or build prototypes.  Don’t just follow my links – google all these terms and read everything you can.  You’ll develop your own style and that’s just fine.  It’s awesome, actually.
  7. Learn about usability evaluation methods.  Even if you work in an organization where someone else does the research, you need to understand methodologies, when to use which one, and how to understand whether you’re making good designs.  It’s good to do customer requirement gathering before you start your design, and then evaluate your design afterwards – even if you’re just using budget, quick or halfhearted methods.  You can’t design in a vacuum unless you’re designing something only you will use.  Read Don’t Make Me Think and Website Usability: A Designer’s Guide and then keep reading other books that those books recommend.
  8. Learn the best practices for web design. Again there are hundreds of good resources, but my favorites are Smashing Magazine,  Jakob Nielsen (even though he’s controversial),  Bruce Tognazinni,  and Designmodo.  Subscribe to blogs and read them every single day.  Best practices evolve, so you need to keep up with the latest research.
  9. Understand the difference between designing web sites, web applications, mobile applications, desktop applications and experiences.  This could be a whole blog post of its own, so my recommendation to you is to google all of the above and come to deeply grok the differences.

Please keep in mind that this is just your basic “get an internship” level of learning.  You need to register for conferences, and get out there working and learn more.  If you can find an undergraduate program at a college, go for it.  Otherwise, look into cognitive psychology, computer science, and design courses.  If you have your baccalaureate already, see if your local college has an HCI or CHI or UCD program.

Good luck to you.  It’s a tough profession, but the world needs more of us.

Today’s Interesting Link:

weenudge.com – I heart this page so much.  It’s MOST useful for the freelance or agency designer, but everything in here is helpful for in-house designers too.  It’s essentially a collection of things you need to explain to your clients, and ideas for how to explain them in friendly, clear ways.   It hasn’t been updated since May 2011 (sad face) but it’s still super awesome.

Today’s Usability Quote:

“Ideas are not so compelling that they just jump off a page.  You have to sell your story.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

I’m so embarrassed to say this: All of the Twilight movie Soundtracks.  Ok, stop laughing and listen – the movies are awful but the soundtracks are fantastic.  You get everyone from Florence  + the Machine to Bat for Lashes to The Bravery.  The tempo is just right and the songs are just innocuous enough to let you throw your own meanings onto them.  The best one is Eclipse, which I think was the third movie.

Let Your Styleguide Live!

Me in my garden

In my garden on world usability day.

Recently, Nishant Kothary tweeted that styleguides “are the most useless design deliverables in existence.” Geri Coady responded with a nicely written blog post defending styleguides and their use, but pointing out the drawbacks to their usage, plus some good examples.

The thing is, there’s a BETTER way.

First, let’s take a quick gander at what a styleguide is, traditionally. This is a document, usually a PDF, ranging in length from one to hundreds of pages. It lists everything from what fonts are allowed on your website or marketing materials, to where the logo can be placed, what colors are kosher, and more. It’s the brand bible, and it’s often the product of months of work by a team of very smart people.

The styleguide’s most valuable purpose, and most undeniable impact, is to create consistency. My UX teams know that consistency, consistency, consistency is my mantra. If a website or application is consistent, then even if it’s hard to learn or understand at first it’ll build a sense of safety, confidence and speed in the user. The user will learn that they look for X to do task 1, and that task 2 is always in place Y. It’s proven that consistency builds trust in users, and that companies with consistent branding, user experience elements and interactions are perceived as more professional.

However, the styleguide usually gets emailed out to everyone, then put up on an intranet, where it instantly begins to get stale and moldy. Those people who got the email either delete it without reading it, or stick it in a folder to be forgotten about. It benefits no one other than the designer who needs to use it to cover his butt or the product manager who wants to use it to convince a reluctant designer to do something a certain way. In other words, it’s an instantly dusty, bully pulpit.

Designers complain that styleguides stifle creativity, and developers complain that styleguides are unusable documents that change too often to be tracked properly. I suspect these are the bases for Nishant’s frustrated declaration – and who can blame him?

But what if it wasn’t this way? What if the styleguide was effortlessly up-to-date, relevant and useful to everyone involved in the design and development process, and accessible directly within everyone’s workflow? What if the styleguide wasn’t a drab, outmoded tome, but rather a LIVING thing made of code and recursively following its own rules?

Living styleguides aren’t a new idea. However, when my architect came to me and said “hey Krys, you know that styleguide you’ve been working on? How about we build it in code, and instead of just being a document, the very styleguide itself is the CSS that people will use? Separate presentation from everything else and let people just write code without having to think about how it looks.” my head nearly exploded.

It took me a while to get the concept, truly. It’s possible that I didn’t completely grasp it until we built it. But build it, we did. It took us a couple of months, and goodness knows there’s a lot more we want to do – but our styleguide lives and breathes.

From a practical, design-oriented viewpoint, here’s what it is:

  • An architecture that completely separates presentation from code, segmented into typography, colors, containers, backgrounds, foregrounds, interactions and widgets.
  • A set of supporting Sass and Compass files (I’m sure you could do this with other technologies too, but we’re a Sass/Compass shop)
  • A few haml pages that use the styleguide to demonstrate the styleguide, in case anyone needs to reference it
  • A matching and corresponding UI Design Library psd file, which is the only part that is manually maintained (and when I figure out how to have a PSD auto-generate from a CSS file, I’m totally going to be rich)

When a designer is creating a new feature, it’s quick and easy to use styleguide elements because each element is named according to its purpose and intent, not its appearance. The process looks a lot like this:

  1. I need to give the user this information without distracting them from the primary task here.
  2. I guess that would go in a low-priority container, then.
  3. But since it’s in a green page, it needs the green page foreground colors
  4. and standard typography
  5. and that looks a little awkward so I’ll vertically separate it.
  6. Ah, that was easy. Now on to something that challenges my giant brain.

Then the designer hands it off to the developer, saying, “It’s a low priority container in the right column, 4 grid columns wide. Standard typography, green foreground, vertically separated”

And the developer just creates a div with these classes: low-priority-container, g-4, reading-text, green-foreground, vertically-separated

And you know what? it’s instantly pixel-perfect.

Look how easy that was for everyone involved.

If the designer is working on a feature, and the styleguide isn’t quite sufficient, all she needs to do is design something new (here, there’s some discipline needed. I go into detail in my Adopting Sass talk), add the appropriate code to the Sass files, test it in the haml, and deliver it to the developer with corresponding class names. Simple, clean – and because she designed it actually in the code of the styleguide, she saved the developer a lot of time and trouble.

I’m not saying living styleguides are easy to implement. I did a lot of hand-waving over the really brilliant, hard work that my architect did actually building all the backend stuff. There are some wonderful frameworks already out there. There was also a steep learning curve for some of the engineers, while they adjusted to a new way of working. However, I’ve since heard engineers say things like “The styleguide makes building new pages so much easier” and “It’s so much easier to communicate when you just tell me what class that is”.

Plus, a super awesome bonus: you get your UI cross-browser testing for free with a living styleguide. You cross-browser test it when you build it the first time, and every time it gets reused you’re using already-tested code. Don’t get lazy with your QA – just focus it where it’s needed most. :>

When it comes to moldy PDFs, I’m with Nishant. They’re nearly useless. But as a workflow and communication tool, and to ensure consistency and brand fidelity, a LIVING styleguide provides an amazing scaffold on which your team can grow and thrive.


Today’s Interesting Link:

foundation.zurb.com – Foundation, by the good folks at Zurb, is a decent place to start if you’d like to build a living styleguide.  It provides you with a basis from which you can build all kinds of amazing things.  And it’s responsive, which in this day and age, is a MUST.

Today’s Usability Quote:

“To innovate, you must first be inspired.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

The Tron:Legacy Soundtrack is energetic and relaxing at the same time.  It’s so well crafted that you almost feel the transitions from song to song.  It instantly inspires me to make new things, and it seems to be completely independent of style.  I love to listen to this while I’m sewing or making props too – it’s just CREATIVE music.