A designer can never have too many tools and methods for creating their designs. Many times conveying interactions in a static wireframe is difficult. So designers have turned to HTML and CSS to create wireframes and prototypes to provide a richer interaction. JQuery can also be thrown into the mix to further this process along.

Richard Rutter and the Clearleft team discovered that JQuery is a great tool for wireframing. Richard says it gives them the flexibility to work out ideas very quickly. One of the reasons he feels JQuery is such a good tool is the documentation it provides. The amount of tutorials and documentation mixed with its ability to work quickly allows “so you don’t have to spend your time and your ‘thinking energy’ coding. You can spend that vital ‘thinking energy’ designing instead.”

Richard’s virtual seminar, JQuery for UX Designers, generated a bunch of great questions from the audience. In this podcast, Richard joins Adam Churchill to address the questions that weren’t addressed in the live seminar.

Here’s an excerpt from the podcast.

“…what JQuery does, by its very nature because your coding with it, it gives you ultimate flexibility about what you want to do with your designs. Things you want to try out. Effects that you might want to do. Bespoke interactions that you want to map out. Even the most simplest sounding things, like say, adding a tag. That’s actually got a bunch of states in there, which you may or may not want to specify in some detail…”

Tune in to the podcast to hear Richard answer these questions:

• Why should you use JQuery instead of interactive wireframe tools like iRise, Axure, or Balsamiq?
• Is there a reason to use the hover jQuery function rather than the hover CSS pseudo-class?
• How do you avoid having a developer look at a sophisticated-looking interaction and re-using it in production code?
• In your experience, do UX designers find using PolyPage easier to understand?
• Do changes set using jQuery persist upon a page reload?

Do you use JQuery in your wireframing? Share your thoughts with us in our comments section.

Recorded: December, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello everyone. Welcome to another episode of the SpoolCast. Earlier this fall Richard Rutter joined us for a virtual seminar titled, “JQuery for UX Designers.” There were lots of good questions and comments. And we decided to have a followup conversation that we could make available as a podcast for you. Richard’s seminar spoke to how JQuery facilitates the vital steps of designing and testing interactive wireframes. Specifically, the complex interactions of today’s modern websites and web applications.

In the seminar Richard got folks started with JQuery. He offered lots of examples, hints and tricks. And he’s graciously offered to come back and tackle some of the questions that we didn’t get to address in the seminar. Now, if you didn’t get the chance to listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library. There’s presently 80 seminars there that have wonderful topic experts just like Richard giving you the tips and techniques that you need to create great design. Hello Richard, welcome back.

Richard Rutter: Thank you. Thanks for inviting me back. Hello.

Adam: Happy to have you. For the folks that couldn’t join us for that seminar, could you give us an overview of what you talked about?

Richard: Sure. What I wanted to do in this seminar was really give a very practical introduction to UX designers about what JQuery is and how to get started using it. Right from the very beginning assuming kind of no knowledge. Because, really that was a seminar that I could have done with when I first started using JQuery as a UX designer to help me design. That was the real focus I wanted to get over, that JQuery can be a design tool. If you’re using HTML and CSS as your method of defining wireframes. And helping design more rich kind of interactions that most websites have now a days. Most things go a bit beyond just being texts and links and images. There’s Ajax and all sorts of stuff that starts to get in the way. Which is pretty difficult to design with static wireframes in things like Viseo.

We find at Clearleft that JQuery is a really good tool for helping us do that. We like to hand code our wireframes. JQuery fits into that nicely. It gives us, as designers, the flexibility to really work out some ideas very, very quickly. Which is the whole sort of idea of JQuery. So in the seminar, yeah, it went from sort of first principles, how to get JQuery working, and then showing some more detailed examples about faking Ajax interactions. Simple show and hide. How to get plugins working so you can straight away get things like popup calendars and light boxes. And all these other tools that you might want to include in your designs. It makes it easier to get that stuff together quickly so you don’t have to spend your time and your thinking energy coding. You can spend that vital thinking energy designing instead. Which is really important.

Crucially, actually, I finished off with a bunch of the best documentation and tutorials and places online where you can go and get more information. One of the great things about JQuery is that it’s hugely well documented. There’s lots and lots of people all over the place have written tutorials and so on. So that in itself makes it a good tool. If getting your hands dirty with code is not too scary for you. For me, I quite like doing that as part of my designing. It helps, I think, to get your hands dirty in the medium for which you’re designing. I think that’s quite important. That’s why I put this together.

Adam: Cool. Well, let’s get back to some of those questions. So the folks at Lokion Interactive wonder, why use JQuery and the tools that you offered up versus interactive wireframe tools like iRise, Axure or Balsamiq.

Richard: Mm-hmm. What JQuery does, by its very nature because your coding with it, it gives you, sort of, ultimate flexibility about what you want to do with your designs. Things you want to try out. Effects that you might want to do. Bespoke interactions that you want to map out. Because even the most simplest sounding things, like say, adding a tag. That’s actually got a bunch of states in there, which you may or may not want to specify in some detail.

That said, I think the other aspect to those other pieces of software is that like any piece of software, there’s a certain amount of time ramping up learning how to use it. Learning how to use it well. And, if you already know how to code a little bit… Now remember, we’re not producing production quality code, just enough stuff to get your ideas over, then adding JQuery on top of that tool set you already know, perhaps, is no more onerous, for example, then learning how to use Balsamiq or any of the others.

But obviously, if you already know those pieces of software well, then sticking with that might be to your advantage. Although you are hamstrung to a degree by what the software can do. And there is occasionally a danger that the software can drive the interactions that you specify rather than the other way around.

Plus, to Clearleft, we do have the advantage of being a relatively small company. Which means that the UX designers that we have are surrounded by visual designers and, crucially, the front end developers as well. Who are more than happy to chip in and give us a hand every now and then if we want to, you know, have to do something a little bit tricky. We can just go to them and say, “hey, Andy. Can you help me with this bit.” And they’ll be more than happy to do so.

So, it works well in our environment now which is very open and collaborative. Like I said, that suits us well. And so JQuery just fits into our work flow nicely.

Adam: Phil asks if there is a particular reason to use the Hover JQuery function rather than the Hover CSS pseudo-class.

Richard: There isn’t really. It might depend slightly on what you’re doing with that hover state. If that hover state is merely changing the style of something then it’s fine to just do CSS instead. Assuming that you haven’t got any kind of cross browser issues. I mean, when we put wireframes together, they’re designed to show to the clients, obviously. And because they’re just wireFrames, we can say to the client, “you’ll need the latest version of to just do CSS instead, assuming that you haven’t got any kind of cross-browser issues.

When we’ve got wireframes together, they’re designed to show to the clients, obviously, and because they’re just wireframes we can say to the client, “You’ll need the latest version of Firefox or Chrome or Safari or something other than Internet Explorer 6,” essentially. Then you’re OK with things like hover state in CSS for something other than just links.

But if you’re trying to do something more complicated then you want a JavaScript event to do something with, then that’s where you’ll be finding jQuery, in this instance, as the thing to go with anyway.

Adam: So Richard, we need to address this. Phil also took a poke at you in Twitter. There was an example in your presentation that talked about Phantom Menace as a favorite film. And there was something about a loss of respect for the presenter. I know you wanted to address that.

Richard: Yes, Phil was under the misapprehension that the fictional user we were showing in our wireframe, a user called Amidactio, was me. Our user Amidactio was down as having Phantom Menace as his favorite film, but also such musicians as Bon Jovi as a favorite musician.

Now, I’m not saying there’s anything necessarily wrong with Bon Jovi, although Phantom Menace, that’s a different question. So it wasn’t me who has Phantom Menace as a favorite film. It was our fictional user. So I need to make that clear. Thanks for giving me the opportunity.

Adam: Absolutely. Understood. We talked a bit about production code and folks were wondering about that transition from these kind of interactive wireframes that you were showing them how to make and how they may or may not end up as production code.

The folks at Expeditors International wanted to follow up on that and they want to know, “How do you avoid having a developer look at a rather sophisticated looking interaction and then just saying, “Well, this works. Why wouldn’t we just reuse the code?”"

Richard: The flippant answer is, “Hire good developers.” That’s kind of the only answer in a way. I mean, the code that you as a UX designer put together using JQuery might be suitable for production or it might not. It shouldn’t be our job to make that decision. It’s just our job to get the design working or tested with users.

If that ends up in production code, as far as I’m concerned that’s kind of none of our business in a way, apart from our job as a user experience designer to have some say in the user experience. There is some degree of, I think, responsibility a UX designer might have as wanting the performance to be good, certainly wanting it to be good in terms of actually making the performance good. That goes to people who are experts at that.

So really the answer is that a good front-end developer should be able to make that decision as to whether the code is suitable or not. It is, of course, easier, in some cases, just to nick a function and use that in the production code. But the chances of it really being bulletproof, I would say, unless you’re a particularly good coder in the first place, are fairly slim, certainly in my case.

Adam: So there was a question about PolyPage, wondering if, in your experience, UX designers typically find that easier to use than jQuery templates or just vanilla, if else, in JavaScript.

Richard: In our experience yes, people who use PolyPage – and that includes us at Clearleft – find it easier because you can just put a piece of logic in there by simply adding a class. It strikes me as being a lot easier to just add a class to a DIV and have the logic just work for you.

So the typical example that we’re talking about there is – the way PolyPage works is if you add a class of “pp_notes” then you get a toggle magically appear at the top of the page called Notes and you can use that to show and hide anything which has that class. Basically, in this case, you’re probably showing and hiding notes. Or just simply by adding one class to each DIV or paragraph or whatever you want to call your notes.

So it makes it very easy for us, rather than writing functions, to do that. It’s already been done for you.

Adam: OK. Cristobelle asks a question. She wants to know if changes set by a jQuery, if they persist upon page reload.

Richard: The simple answer is no. If jQuery has added or changed the state of something it’s shown when previous it was hidden or it has paragraphs or lists or changed the mark up in any way and then you hit reload, it goes back to whatever the state was before. Unless that piece of jQuery is also doing things like setting a cookie for that state at the time, in which case you’re introducing state by jQuery. But it doesn’t happen automatically, you have to get it to do that.

It leads me onto a point that I wanted to make. In the seminar I was keeping things nice and simple when I was talking about event handlers, adding a click event handlers to, say, a link so that when that link is clicked you can get it to do something other than go to a new page. You can get it to hijack that link and get it to fake a piece of Ajax.

If, for some reason, you’re getting jQuery to add in more links automatically, then those new links that you’re adding, they won’t actually get that click event handler click on its own. The click method just applies to everything that’s there already on page load.

However, there’s, with jQuery 1.7 – didn’t really intend to go in lots of code in this podcast, but it’s quite an important thing. So jQuery 1.7 introduces the on method, which is basically the new way of doing all event handlers. So it would be along the lines of instead of click open set brackets, you got on open brackets with click inside saying that’s the event I want to use.

It’s all there in the documentation on jquery.com and jqapi.com which is an alternative source of the documentation. But it’s the on method that you want to look for then. And you can just replace where you had click before. It’s just something they introduced fairly recently to deal with that situation where event handlers can be added on the fly rather than just on page load, which was the situation that used to be.

Adam: Well, OK Richard, thanks for circling back with us, certainly appreciate it.

Richard: You’re welcome.

Adam: And to our listeners, thanks for joining us. Goodbye for now.

In the next UIE Virtual Seminar, Rich Rutter gets you started with JQuery—assuming no prior knowledge—and shows you lots of examples, hints, and tricks. Just 5 minutes into this seminar, you’ll see JQuery in action and have something you can use in your own wireframes.

Employ Simple Show and Hide Techniques

The essence of JQuery is to find something and do something to it. This technique easily shows different page states so your team and test participants can “do things” to your design.

• See, step-by-step, how to put this simple, yet useful example of JQuery in action
• Use modules and plug-ins to make your design to do simple things, without worrying about the performance of production code

Toggle Wireframe Annotations

Add notes to your interactive design.

• Turn your comments on or off depending on who’s viewing your design
• Add lists, comments, or direction for developers and others who need to work with your design

Fake Simple Ajax Interactions

Without creating production level code, get your design to quickly and easily do its thing—click something and change occurs—for your developer or client.

• Replicate what happens when you click something like a “favorite button”
• Fill in all the steps of an Ajax interaction such as a slight delay or adding different page states on a single page

Get Started with JQuery UI Widgets

Rich will introduce a library with options and widgets that you can easily put in place. In many cases you’ll see how to simulate what the full interaction could be.

• Explore modal dialogues, an intrusive piece of interaction and a good example of something you want to test: Do I really need a modal, or is a link better?
• Get more examples: Prototyping calendars, lightboxes, and more.

Rich will show you the power of combining discreet interactions together with a complex interaction.

Regardless of your JavaScript experience, this seminar will be a great way to start using JQuery and take your interactive skills to the next level. JQuery gives us a clean, interactive feel, and can be the difference between a slick design and something annoying or disruptive. It brings rich interactivity to your HTML and CSS3.

Rich will incorporate complex interaction examples along with providing excellent sources of documentation and tutorials for your toolbox. The seminar will keep theory to the bare minimum and focus on getting you started with practical takeaways you can use straight away.

The real power in what you’ll learn is getting very close to a final look and feel of your intended design with just a bit of effort and without having to build the whole application. Get over the initial hurdle of the JQuery learning curve and gain momentum in your design process. Join us for JQuery for UX Designers.

If you didn’t attend the User Interface Conference this year, you may have missed the buzz over Leah Buley’s session entitled “How to be a User Experience Team of One”. Attendees loved it. Leah gave them tips and techniques used by top user experience teams that any UXer can use in a small team or an unsupportive environment.

Below are some notes I took during Leah’s session and slides from this portion of the talk. The slides here are shrunk to fit our blog, but the materials on the disc are full-sized PDFs suitable for printing.

Leah began with telling the story of her transition to a new job at Adaptive Path. Up until then, she had been a UX team of one at a financial firm. Her time was mostly spent walled up in a cubicle, headphones on, sketching and otherwise prepping wireframes on the computer, based on up-front meetings determining business requirements. After a few weeks she would emerge from her design cocoon with designs ready to be shown in a dog-and-pony show-style.

Her first day at Adaptive Path was radically different. She was handed paper and a Sharpie and, along with a couple of other designers, was asked to tackle a problem by generating several solutions, collaboratively, on the spot. She was initially flush with panic. They didn’t teach this at library school!

After a short while she warmed up to the process. To get to the quality ideas, you first must generate a lot of ideas, and be OK with many of them being subpar and others simply being tossed aside.

Now instead of jumping to the finish, as she had at her previous job, she was exploring more ideas more efficiently with techniques you can use with or without collaborating designers.

Leah used the idea of redesigning the eVite.com digital invitation and RSVP service to demonstrate some of the techniques she learned after joining Adaptive Path. (For the purposes of this blog post, we’ll be covering just the first part of the brainstorming process)

She avoided the computer. Computers can lock you into only one idea and you often get sucked down by minutia you shouldn’t be addressing at this stage.

She started with a “6-up” – a single sheet of paper with six, smallish, blank browser viewports and a pen. This allowed for 6 different ideas of how to solve one problem, say the eVite landing page. One or two ideas came easily. How do you push through to the next ideas?

[Download a PDF file of Leah's 6-up template]

Leah uses a couple of so-called “lightweight conceptual frameworks” to help push more ideas out of her head. A “Spectrum” is one such framework. A spectrum is a range from two opposing points. For example, what would the landing page at eVite.com look like if it was intended solely for a first-timer? What would it look like if it was solely for a long-time user of the service? What would pages on the spectrum in between those to points look like? What characteristic would they exhibit?

None of the sketches you make on the spectrum may be the right solution. But that’s OK, because we’re not drawing solutions. We’re drawing ideas. This framework gets you to try ideas you might have avoided before. Now you have a pile of ideas to pick from. Perhaps the best design features aspects from several of these thumbnail sketches.

You can hear the rest of Leah’s talk plus the other seven speakers and Jared Spool’s keynote presentation on the UI14 proceedings disc. The disc is loaded with over 12 hours of audio recordings, all the handouts from the Featured Talks and the presentation slides from the 8 full-day workshops. Order the proceedings disc by November 20, 2009 to guarantee your set and get the lowest price.

Subscribe to our podcast via

I had the pleasure of chatting with Leah Buley recently, in advance of her appearance at our User Interface Conference. She’ll be speaking about getting to a Good Design Faster with new techniques to getting at your creative ideas. She’s done some wonderful research on early-project design stages that you really need to hear. There’s a ton of great content in this podcast, and I can only share so much with you here, so please tune in for more of her insights.

When Leah told me that wireframes are really holding back the design process, she grabbed my attention. Designers sit down with some rough ideas and start trying to fit them into one or two pages. Next they start sliding design elements around until things feel good, and then they show it to someone for feedback. That someone or group then sees a design that’s pretty far along, and looks pretty concrete. If some of the ideas in the wireframe are not developed as much as they should be, it’s difficult to stop the forward momentum and reassess.

How can we explore a range of solutions before diving into a single solution? Wireframes are very useful to the process, but instead, we should consider delaying them. Before wireframes, Leah suggests a very open, cross-team exploratory stage. Invite people from across your organization and even collaborate with those who might not normally be within the core design group.

Leah suggests a week-long ‘design sprint’ that begins with a group brainstorming meeting in the morning with lots of people… and everyone’s opinions count. Then that afternoon, the group sketches out a large number of low-fidelity sketches further exploring the experience they’re looking to design, based on the morning’s activities. Sketching many iterations based on different perspectives like, ‘how would we optimize this for a first-time user?’ ‘how about for a power-user?’ ‘how about for this demographic?’

Then the week-long process continues. Grouping the different approaches together, sort the best from the bunch, mixing and matching the best ideas and build upon them (Leah calls this ‘sketch-boarding’). Next, take the sketches and flows with the most potential, and make those the first round of wireframes, which you present to a group critique. At the end of the week, take the feedback from the group critique to improve the wireframes.

The end result is a wireframe that has a tremendous amount of collaborative thought behind it. Instead of surprising many stakeholders at this point, their good ideas are already baked inside. You can now share these fire-tested ideas with the next groups that need to see them. This is clearly different from the way many groups and designers are using wireframes today, and I think it’s a really powerful proposition.

Leah and I also talked about ways to become an effective sketcher, how to run productive group critique sessions and much more. You really need to listen in, this could really help your teams process. After our conversation, I’m even more excited to see her full-day workshop on this topic this November at UI14 in Boston. I hope to see you there, as well.

Till then, what are your experiences with the early rounds of design? What are you doing in advance of your wireframing? Can you see implementing this process in your organization? Let us know in the comments!

Subscribe to our podcast via

Without planning, web apps have no where to go. Planning documents for web app projects are often overlooked, despite their importance in the success of the product. As a designer, no matter how great your research is, or how amazing your programmers are, if your planning documents do not develop well, your project will fail.

One of the great user experience success stories in the U.K. is the Brighton-based agency Clearleft. They’ve developed successful, sophisticated methods of planning for their projects. I was able to get a hold of two of their talented crew to discuss those methods in this episode of the SpoolCast.

James Box (UX) and Richard Rutter (Co-founder and Production Director) have been working on ways to plan highly interactive web apps that make the process more efficient. And that’s exactly what we spoke about during the podcast.

James and Richard first told me that they hold back from traditional deliverables, and show clients what they call ‘design tools.’ Some clients prefer tidy deliverables, but many clients like these rougher documents. The advantage to these is that they stress design as a process, rather than set in stone. Sometimes overly polished documents can make a solution appear complete, without the client being able to change its course.

This method aids the flow of dialog between the designers and the client. Rough prototypes help your client stay focused on the core issues you’re demonstrating, like interactions, while avoiding getting caught up on visual elements that aren’t important at this very moment. As an example, when possible, they leave color out altogether.

A key element to the success of their design tools is that prototypes are interactive. They make many prototypes with HTML and enough jQuery to demonstrate the interaction. They don’t feel this process takes any longer than using relatively static tools like Visio or OmniGraffle, and offers more utility. They’re always looking for ways to improve the process with reusable pattern and code libraries.

There were more quality nuggets in the conversation too, so please tune in for more on peer reviewing, prioritizing usability testing and real code production.

James and Richard will be joining us in California this April for our Web App Summit, where they will be conducting a full-day workshop on “Wireframing and Prototyping for Highly Interactive Web Apps.” If you enjoyed this conversation, please join us to learn how their techniques can help in your organization.

Have you moved to interactive prototyping for expressing complex situations? Let us know in the comments.

Over at Semantic Foundry, designer extraordinaire, Will Evans, has a wonderful essay explaining how he uses wireframing as both a problem setting and a problem solving approach.

I pick my primary audience and the one activity which allows them to solve one goal quickly, effortlessly, elegantly. In this case, the primary audience wants to easily find the best cruise, at the right time, for the right price. I don’t even look at the requirements document or competitive analysis until after I have sketched a couple of ideas either on paper or using Omnigraffle, which explores the primary goal. I’m not looking for solutions at this point because the first round of wireframes provide a space to engage in a dialogue with other designers, stakeholders, and the wireframes themselves.

It’s a great description of how Will tackles a design and he’s provided his work products for you to download.

Read Will’s essay: Shades of Gray: Wireframes as Thinking Device