The iPad GUI PSD has been very helpful for designers / developers in mocking up their apps, although in some cases it’s proved a little too high-fidelity. For rapid prototyping we found we needed a more malleable approach. This is when we turn to the iPad Sketch Elements AI. This collection of common iPad elements in a sketch – like style allows us to easily and quickly mock up flows of custom wireframe screens.

Below is a full shot of all assets included in this release.

If you like it or use it, help us out by retweeting it.

Download The iPad Sketch Elements AI Here

Looking for an iPhone version of this file? View iPhone Sketch Elements AI

(Font Requirement: To fully achieve the sketch style, you’ll need Tekton Bold — Found here)

Last year, I gave a presentation at MeshU that took a behind the scenes look at how we arrive at design decisions. We’ve since taken clients through variations of this presentation, which is always evolving because it corresponds to such a perennial and fundamental question in our field.

I’ve always appreciated it when fellow UXD practitioners talk candidly about what works and doesn’t work for them. Insights and methods pioneered by others have helped us improve our process here at T+L a lot. Maybe our spin on things will be helpful to you and your team.

Here’s the presentation

During a recent pitch, one of our clients asked us to come back and explain how we “bridge art and science” when making design decisions. I think this is an intriguing way to pose the question (and it speaks to how clients are becoming more engaged and sophisticated in what they’re looking for from a design shop).

Let’s start by defining our terms (Slides 1 through 20). Here are a few conventional ways to differentiate between art and science when it comes to user experience design (please note that I’m speaking in stereotypical terms here): In terms of focus, an artistic process is concerned with issues of look-and-feel, whereas a scientific approach focuses on deeper, more systematic issues like underlying architecture. In terms of methodology, art relies on intuition and experience, whereas science depends on rigorous investigation and analysis. In terms of validation, an art-led process often rests on subjective or personal evaluation, whereas a process that’s grounded in science relies on rigorous testing using quantitative metrics.

Although perhaps a helpful starting point, this model doesn’t tell the whole story. In fact, we can flip things around (Slide 8) and take a look at the other side of the coin: over the last 6 years, some of the most influential academic research in HCI has demonstrated the importance of emotional, relational and aesthetic affordances in design; when you factor-in experience, intuition is often an important check on incomplete or distorted data that might otherwise mislead; and there is certainly an “art” to testing in appropriate and productive ways.

In other words, rather than this binary opposition of art vs. science, a better model is perhaps something more like a continuum. There are two extremes we want to avoid. At one end, we have deterministic design—the idea that we can be entirely predictive, almost in a Newtonian physics kind of sense, mapping out causality for everything, no matter how complex or layered. At the other end we have open-ended design—where decisions are more or less arbitrary. The first alternative has turned out to be pretty unrealistic; the second is just a cop-out. We’ve tried to strike a balance between these two extremes and have gravitated towards evidence-based design as our happy medium.

Evidence-based design (EBD) is a term that comes from the medical world. Evidence-based medicine is the “conscientious, explicit and judicious use of current best evidence in making decisions about the care of individual patients.” Transposed into our context, we like the idea of EBD because it acknowledges the fundamental reality that design is about making choices, and that the goal is to do this on an informed basis. We don’t have to maintain the pretence of a magical process that guarantees optimal results, but neither are we given free license to design whatever we want: our decisions become accountable to the best available evidence whenever possible.

EBD is not just about gathering up data at the beginning of a project: it’s about infusing design decisions with data-driven insights throughout the entire process. Slides 16-20 visualize this goal in terms of a typical agency process (actually, our process). In practice, there’s typically a gap between the define (or research or discovery or whatever you want to call it) and design stages. This is a fundamental challenge—you can have the best researchers on the planet, but if their observations and insights don’t carry over to impact and influence design decisions they’ll do you little good.

So how do we bridge the gap? For us, the secret has been to build our process around a rhythm of open exploration and refinement. Slides 22-28 visualize this approach (thanks to Brendan Schauer et al. from Adaptive Path for the inspiration). We oscillate between a ‘go wide’ mode where we investigate, explore and experiment, and a ‘refine down’ mode where we focus and prioritize. When this happens over and over again, we get these critical points of inflection that keep us grounded (evidence-based) and moving forward (design).

OK, let’s take a look at a real life example. Slides 29-48 provide a glimpse behind the scenes of our work on thestar.com redesign. We start by going wide and essentially scavenge for as many design inputs as possible. These vary project by project, but at a minimum we’ll need to get a handle on demographics, psychographics, behavioural profiles for target users; a concrete understanding of what is and isn’t working on the current site; business goals, needs & requirements; and a comprehensive competitive analysis.

All we have at this point is raw data—we need to turn this stuff into evidence and insights we can actually use. Borrowing from Subject to Change, we believe that inputs become evidence when they are durable (you can kick them around and mash them up), actionable (there are clear implications for design), and impactful (they actually start to change the way designers think about the problem itself). So how do you get there? This is where the art part comes in…

In the beginning, we aggregate stuff in one place, organize loosely and share it among the team. Tools like wikis are good for this exercise. Next we start to look for patterns and find corroborating data—multiple pieces that tell a coherent story. We then construct and test narratives for things we heard from stakeholders. These narratives help us get at the context behind the requirements. We then create focusers—models (visual, conceptual, personal etc.) that help us focus and filter. Two focusers that we often use are personas (architypal users) and design principles (mini mission statements). Focusers are important because they allow us to find the signal in the noise, develop a common language and conceptual framework, and make our assumptions explicit. Because they’re so elemental, they can inform design decisions on a case-by-case basis throughout the entire process.

Sketching has always been central to our process, but we’re starting to formalize this step and make it more collaborative and inclusive. In the case of The Star, we generated about 150 initial sketches (going wide) for 10 key templates (which we refined down in detailed IA). Prototyping is another technique that allows us to explore and test ideas and assumptions. Critical and complex elements in the UI make great candidates here.

Finally, we need to develop a plan of attack for knowledge gaps or areas of uncertainty. For example, with The Star we noticed some anomalies in the analytics data. When we took a look at the competitive set (with a little help from Image Spark), we didn’t see very much alignment in how other media outlets were using certain areas on the page. So, we developed a fairly wide-range of alternative modules for split/multivariate testing.

So there you have it: a relatively geeky look at the case for, and our approach to, evidence-based design. I hope that some of these ideas and examples ring true with you. What do you think? I’d love to hear what others are doing in their design practices and processes.

Last year, when Brandon essayed about Sketchboards on the Adaptive Path blog, Derek and I became instant fans.  Since then we’ve played around with variations of the method at T+L—sort of hedging it with our existing process—so I was really looking forward to this session.

First we talked about the sketch part in 2 stages:

1. Exploratory sketches: quickly saturate the design space by generating a number of rough options. Use word-play, inspiration libraries (hurry-up, imgspark!), conceptual models to drive this process.
2. Refinement sketches: take the most promising ideas and add a more detail and weighting through different types of marks, labeling, etc.

 
Then we talked about the board part:

1. Get a large sheet of paper or whatever you’re going to use to lay things out on and give it some structure: for example, use stages in a user flow.
2. Add referential inputs like personas, scenarios, requirements, design criteria, inspiration, etc.
3. Lay-out sketches, review, annotate, iterate and decide what you’re going to prioritize in wireframes.

A few personal reactions:

• Although things can go at a fairly fast pace, you’re definitely trading scope for time.  Brandon proposed a 5 day sprint that would maybe output 3 or 4 wireframe-able templates.
• I was impressed with how natural and intuitive the whole process felt. Sketching happens on an informal basis anyway—this just put’s some structure around it and invites dialog.
• The main thing I love about Sketchboards is that they encourage and facilitate conceptual externalization. They force you to get your ideas out and onto the page, making them tangible, accessible to all and amenable to critique (before you fall in love with them!).