Posts About University
Posts About University
At the summer Olympics of 2004 in Athens, Greece, Hossein Rezazadeh raised 263.5 kilograms (nearly 581 pounds) over his head and broke the world record. Olympic power lifters are able to accomplish these incredible feats because they stick to a well practiced technique. In product design, a well executed technique or process can help us accomplish incredible things as well. So what are you using to do the heavy lifting?
Think of it like powerlifting. When you step up to that big project, where does sketching come into play for you? When we've run Interface Design Sketching classes in the past, many have told us that they actually don't use sketching to do much heavy lifting. Many people use sketching to do some quick "hand chalking". They do all the heavy lifting with more time intensive brute force. This usually involves a cycle of presenting to stakeholders, going back to Photoshop to refine, presenting again, and so forth.
- Good = Use Sketching as hand chalk.
- Better = Use Sketching to get the bar off the ground.
- Best = Use a Sketching System to clean the bar halfway to the finish.
What we've done at ZURB is develop a sketching system that we use in all of our projects. The system is a series of sketch types that thrust projects from early ideas through to lo-fi wireframes. Sketches are a fast and low-cost means of making ideas tangible, adding fidelity to them, and putting them together into layouts and clickable prototypes'the key points being fast and low-cost. Why are 'fast and low-cost' important to being able to lift the immense weight of a project? Have you ever seen Olympic powerlifters clean the bar slowly and deliberately? No, for powerlifters, speed and technique are more important than brute strength. It's all about speed and economy of movement in building inertia to thrust the bar up. It's the same idea with product design projects.
The fast and low-cost nature of sketching is the economy of movement and speed in how we powerlift projects. Our system consists of Opportunity Sketches, Ideation Sketches, Lo-Fi Wireframes, and sketch-based Clickable Prototypes.
We start with Opportunity Sketches to quickly make ideas tangible enough to move forward. Then we translate Opportunity Sketches into multiple possibilities through Ideation Sketches. We then work with stakeholders to move the right Ideation Sketches forward together into Lo-Fi Wireframes that show how those ideas work together in layouts. Next we put those Lo-Fi Wireframe Sketches into Clickable Prototypes in Notable. In the video excerpt from our Interface Design Sketching Class below, we discuss how the sketches fit together.
After getting through to sketch-based clickable prototypes there's still a lot more work involved, but with our sketching system we build a whole lot of inertia to get the project poised in a good place for a successful finish. Analyzing the process, we use sketching to do almost 1 / 2 of the heavy lifting needed to bring the product to life!
Do you sometimes struggle getting projects those first few inches off the ground; find it hard to keep a solid grip; or have difficulty building inertia up to the place where you can move toward the finish? If so, take a closer look at your speed and economy of movement, and consider instituting a sketching system to do the heavy lifting.
Tavern began with this goal: challenge our fellow designers to define the broader, fuzzier concepts or product design. We'd do this by debating a single question a day, exchanging ideas on what it means to be a product designer. A question that had to be asked and answered in the ticking clock of 24 hours. More than a 100 days later and after some 5,000 contributions, our comrades in design ran with the challenge.
Some articulate and outstanding designers, such as Ren Walker, Bryce Howiston, and Antonin Januska, are questioning and challenge ideas, which is the core of being a product designer. And that's exactly what Tavern is about. The community is shaping up to be the place, as well as the structured environment, that is giving extreme focus on aspects of product design that aren't always easy to articulate, for everyone building product — from designers to managers to marketers.
A Product Design Question a Day
Of all the folks we've let into Tavern, not all are designers. There are folks who are involved in every aspect of building product. There are CTOs, design managers, creative directors, engineers, developers, CEOs, marketers, and business developers. With all those folks, centering Tavern around a single product design question a day allowed us to focus ourselves — and the community — around an answer we could frame.
The new format has provided an arena for some truly thought-provoking answers that go beyond the rah-rah comments typically found on portfolio sharing sites. Not that there's anything wrong with those sites, but they can't easily showcase the way you think about the design problems.
The frame of one question in 24 hours has given us and others a space to quickly give insight into how they thought about design in shorter bursts. There have been specific questions to more abstract ideas, such "Is Design Art?" and we've tried to balance with specific, technical questions, such as:
What is your preferred CMS?
Tavern-goer Jan wanted to know what CMS people preferred to work with and why. We had 66 answers and comments. Some preferred WordPress while others took the stance that it was project dependent. But what we learned the most is that everyone has a preference that's almost like why some people prefer Coke to Pepsi.
Do tools like Macaw, Reflow, Webflow have a place in a designer's tool kit?
Another Jan on Tavern (yep, there are two of them!) asked about whether his fellow Tavern-goers used those specific tools in their workflow. Some thought they did. Others not so much, finding that they weren't an adequate replacement for Photoshop.
And a few of our broader questions:
What's your job title?
What's in a title, a job by any other name. Kidding aside, one of our most prolific Tavern-goers Ren asked folks to tell her their job title and whether it accurately covered what they actually did. It was one of our most popular questions with 154 answers and comments! But the biggest takeaway — there wasn't one job title to rule them all!
How do you overcome your fear of asking questions and looking like you're inexperienced?
Rhia wanted some advice on how to ask questions without looking like a n00b. Alicia had the top answer that day with the advice: "The discomfort of asking a question can last a few seconds. The discomfort of not knowing the answer can last a lifetime."
There's been a deluge of submitted questions with over a month queue in the backlog, all of them generated by the community, which is shaping up to be much much more than just a group of folks answering design questions.
The What-You-Know Design Network
Tavern isn't just about answering a question. It's also about showcasing what you know. Because, let's face it, we all like to show off just a little. However, it's much deeper than that. Through their answers, designers are giving proof that they know what they are talking about. And they can get validation of their ideas from the community.
Each person has a single point total based on the upvotes of contributors. Designers in Tavern are building or reinforcing their reputation as experts in their given field, through writing and debating. Right now, profiles are private as we work to build the site. However, we intend to help designers establish their know-how among their peers.
From more than 16 years of practice, we've found that it's not enough to talk about ideas and concepts. You have to commit to writing them down. Tavern is the place where designers can practice that. And many of them are already doing just that.
Bryce had the top answer not to long ago on our question on whether design requires a degree. Here's what he had to say:
Does a design degree equal ability to do a job? I'd say that's a resounding no! We've all meet people with degrees in various things who aren't fit to be hired.
Bryce added that he thought there is value to getting a degree, and listed in detail his reasons for thinking so.
Laura, one of our prolific Tavern-goers, had a very good response to a question on handling public criticism on open-source projects. While her answer wasn't voted the top answer that day, what she had to say was really valuable:
No matter the openness of the project, one should always embrace critique because a fresh set of eyes helps identify issues (most of the times). As people we always believe our input is the best, most insightful and utterly helpful to the recipient ... but as feedback-givers we should also know how to phrase that critique to say exactly what we want to say without being a bully.
Building the Future of Tavern
We're innovating as we go and that's exciting! And we're learning a lot about what makes a great arena for designers to debate.
We're learning more about the types of questions that apply to people. Broader questions covering the life of being a designer are crowd-pleasers and send engagement through the roof. Specific questions ask how you do your job tend to get fewer answers, but the depth of the questions are some of the best we've seen online. Eventually this will be an incredible resource for people who are learning product design as we add search.
There have been insights in how people engage with the question of the day. Mondays are big days for contributions as people come off the weekend. If there's a seemingly good answer, or a "right" one, others feel that there isn't anything left to say. So they sit back and lurk, or merely comment on someone's answer. However, product design rarely afford the best answer right off the bat and some ideas are fuzzier than others. And questions can be hard for some to answer. We had a question on what would make designers leave a job and one person said he didn't want to answer because their co-workers might catch a glimpse of his answer.
We're taking these lessons as we continue to work with designers in Tavern to grow the concept. Our goal is to give product designers a voice in the direction of the site. We've brainstormed a lot internally on the next features and common elements, including making Tavern more searchable. We've also considered how to bring more depth to the discussion without having to increase the overall commitment each day.
We're letting designers into Tavern each week. If you're interested in sharing your experience and learning from others, request an invitation to join Tavern!
Cyndi Lauper was wrong when she said money changes everything. Well, wrong when it comes to designers. Of course, she probably wasn't talking about designers, but that's another story. When we surveyed designers on the reason they'd leave a job, we expected that money would be the number one answer. It wasn't.
Designers said they'd bolt if there was no advancement. But what the heck did they mean by advancement? We did a follow up survey of 100 designers. Once again money took a backseat. The top answer was new skills training.
Money came in number two, followed by more responsibilities. These three things seem to be the trifecta of advancement — and what really motivates a designer.
Money Isn't Everything
About 50% of designers are under 30, which puts them firmly in the often-used label of Millennials, so you'll pardon us for using the term here. Not surprising since, according to The White House, Millennials want to be successful and value jobs that stretch their creativity. While a majority of Millennials want competitive pay, it's not as huge a factor among designers according to our results. And quite frankly, it's also the case among those Millennials that are ambitious — and designers are a very ambitious lot. One study found that 38% of those surveyed would bolt if there was no professional advancement, where they their skills weren't developed or there was a lack of growth.
Which is exactly what those we surveyed said.
Learning as much as you can and not being able to try out or utilize new skills can be very frustrating. I would look for a new job which would allow new opportunities and challenges which would mean that I am less likely to get bored and move on again :)
What Designers Really Want Out of A Job
Working on one thing — say a button — might sound appealing, but it results in boredom. Once you master a skill, you won't find satisfaction in practicing it over and over again if you aren't learning anything. Designers need constant challenges or they'll stagnate.
I would like to be doing new things, at a higher level.
No matter the title or the people you manage, what best defines advancement is the chance to face new challenges on your work. A salary increase could mean you are still doing the same tasks, and training doesn't always relate to ACTUALLY doing what you are training for.
For me, advancement is solving new problems, learning new skills, get new projects that are better and more challenging than previous, and learn, learn, learn.
Though I love doing the actual design, I also want to be planning/coordinating efforts that are bigger than just me and my work.
Designers want to make a difference. They don't want to just push pixels. They don't want to be stuck.
Ability to make decisions on projects that are respected and directly affect the outcome. in short, I want to make a difference.
As a young designer I was terrified of becoming stuck in one singular role that could be easily replaced. I didn't want to be a pixel jockey for the entirety of my career.
Standing still is similar to going backwards. Standing still quickly becomes dull. People prefer being useful.
A Raise Without New Responsibilities Isn't Advancement
You can't have new skills training and new responsibilities without the money. Designers aren't always looking for more money as a means of advancement, and that it's tied to both new training and having more responsibilities.
I would say more responsibilities is key element, closely followed by learning new skills. With more responsibilities salary should also increase.
That's not to say that money isn't a factor for some. But we found that money isn't the only factor for most. It still boils down to moving up, gaining new skills and responsibilities. Advancement means solving more complex problems, which means learning new skills to solve those problems. And, eventually, there will be a payoff.
Money is the ultimate motivator.
Goes hand in hand with salary. As many other designers by choice or circumstance have stayed in the field forever. senior positions are common, and in my experience kind of boring. Better routes to Product Management or cross functional roles have been difficult to find. Really wish there was a better route to that kind of switch.
I chose 'a salary increase' because probably, as I learn these new skills and solve more problems, my value to my company as a consultant will increase.
When money is tied to both new skills and more responsibilities, then a designer will be even more satisfied.
Gaining Insights Into Designers
We've been hiring designers for nearly 16 years now, and we're constantly learning more about what drives designers. We've spent the last year or so conducting surveys in order to gain even more insights so that we and others looking for design talent can better hire designers.
Let's face it: Building CSS grids can get complicated fast. Even using Foundation 5 — or what we call Foundation for Sites — sometimes finding that one stray
</div> tag can be tricky.
Today, we're launching a new way to build, share and store Foundation layouts: Morse Code, a shorthand lingo for Foundation grids. Here's an example:
That's a row with four large columns, eight large columns, and another row of six and six large columns. As one of our designers pointed out, an entire page can become a tweet.
At first glance it looks like gibberish. It's writable once you learn the system, which we describe on its Playground page. But to help speed things along, we also wrote two plugins for our favorite code editors, Coda 2 and Sublime 3 — just in time for the impending launch of Coda 2.5. These plugins encode Foundation grids into the Morse Code syntax, and turn that code back into Foundation grids. Easy peasy. As a bonus, the Coda plugin comes with Markdown link-aware commands to build common Foundation patterns like buttons, off-canvas navigation, pagination and modal windows.
There are a few caveats.
- Both plugins require complete, well-formed HTML.
- Both plugins require valid Foundation grids. No columns directly inside columns, for example.
- The Coda version skips elements without grids — say,
- And while the Coda version treats each line of Morse Code as a new row, the Sublime version requires everything to be on one line.
But the decoders result in valid HTML.
Encoding grids to Morse Code was easy compared to going the other way. We spent a few weeks getting the decoders to work properly, fine-tuning our syntax in the process. And while it's not a perfect system — indenting more than two levels of nested rows and columns can get a little odd — we think it's a great way to hash out prototype grids faster than ever. Check it out on its official Playground page:
It's hard to accept you might be wrong and don't know what you're talking about. That's because we're socially ingrained to think that questions are a burden, that we need to have the right answers all the time. And if you don't you could be seen as an impostor.
We learn that it's wrong to ask people questions, such as "why did you paint your house that color" or "why are you still dating that person." You can be seen as offensive for asking why. Why? (See what we did there.) Because it implies that someone made the wrong decision. But that doesn't necessarily have to be the case, and it certainly doesn't mean the questioner is being confrontational. Really, in most cases, the asker wants to understand the thinking behind a decision.
Why is a powerful thing to ask if you really want to get to the bottom of something. Journalists ask lots of questions to get the scoop, and often they start with the "why" of the five w's and h. And you have to keep asking why. It's not enough to ask it once, or twice. How many? Five times to be exact.
Why, Why, Why, Why, Why
High-performing Product Designers are obsessed with the rush they get when they crack a problem. They can't stop until they achieve it. Doing something for the sake of just doing it is not enough. They need a higher purpose — they need to know why!
We found that asking why five times helps us when asking big questions on our quest for answers. It prevents us from being superficial and merely covering up problems with a bandaid. We can get to the root of a problem. More importantly, it allows us to challenge assumptions. And as we all know, when you assume you make a donkey out of you and me.
Asking why is what led us to figure out why Forrst as a community wasn't thriving. We started with the question, "why isn't Forrst working?" We then dug deeper, asking why people weren't engaged and why folks weren't asking for critical feedback. Those questions led us to see the dribbblification of design on Forrrst.
We got to the root of the problem. We learned that getting critical feedback requires a strong presentation that upfronts context and asks for feedback in the right way. So why weren't people doing it? Because it takes a lot more work than just posting pretty pixels. And when the presentation is lacking, so is the feedback. Part of the problem was that folks weren't asking why — "why was a button in that particular spot" or "why is the call to action buried."
You'll Never be a Great Designer, Unless You Get Over Being Afraid
We're obsessed with asking questions, which is why we took Forrst and turned it upside down into Tavern, a Product Design community where people answer one question a day. Questions are important, and people didn't want to answer every question on Forrst.
With Tavern, the questions are curated, so you don't have to waste time finding the ones you want to answer. We've already had a lot of interesting questions so far, including one that asks:
Which really goes back to our point about asking questions, where you can feel like you need to have all the answers. Tavern-goer Gabriel Friedman had an excellent answer:
Put another way: 'impostor syndrome' may just be another way to describe the anxiety that can accompany the need to constantly learn. Not necessarily a bad thing, if it spurs learning, but it's still anxiety.
Don't be afraid to ask questions and don't be afraid of being wrong. That's how you get to the right answers, elevate any anxiety and become a great product designer. And always start with why.
If you're interested in asking questions, join us on Tavern.
We're counting down the hours to tomorrow's ZURBwired event, our yearly design sprint to help a nonprofit through a marketing campaign. And we couldn't be more excited to work with Sacred Heart, this year's nonprofit! We want to thank all the nonprofits who sent in so many excellent proposals!
The timing couldn't be more right for Sacred Heart. This year, they're celebrating 50 years of their mission — to help struggling families get food and gifts for their children they need during the holidays.
Not only did the folks at Sacred Heart have a strong mission, but their team had the magic mix of energy and clear goals we look for in a nonprofit. And they're willing to lose an entire night's sleep to get things done.
We're impressed with Sacred Heart's overall mission: end poverty in the community they serve. They help more than 75,000 people and families that struggle to make ends meet. They have a small staff and an army of volunteers, so they know how to work together to get results. And they're ready to get to work on this year's Wired:
We are psyched and ready to work with ZURB for Wired this year. Thousands of families will turn to Sacred Heart Community Service this year in order to celebrate the holidays with food and toys. Redesigning our holiday campaign will mean we can reach throughout Silicon Valley and engage the community in this effort.
—Jay Pecot, Director of Development and Communications
We'll help them with the marketing campaign for their holiday push and 50th anniversary. We'll work on a brand strategy and designs for their holiday campaign, including a website, brochures, posters and other goodies.
All of this will be done in a tight 24-hour timebox using our our design process and goal-oriented teamwork. Our goal with Wired is to educate nonprofits to do more with less resources. And we'll work closely with Sacred Heart so that they can continue building great things for years to come long after Wired is done.
Wired gets underway tomorrow, Sept. 18 at 8 AM and goes until Sept. 19 at 8 AM.
Tell us if this has happened to you. You've had a brilliant idea while collaborating with a teammate and sketched it out on the whiteboard. You don't want to lose your idea, so you snap a photo of it. Then you get back to your desk 15 minutes later. Voila! It looks awful. There's a glare from the lighting and you can't make out what you've sketched.
It's happened to us. You'd think that recording a collaborative whiteboard sketch would be easy — grab a smartphone, tap a button, and you've got a pic. In reality, we've had to squint our eyes and say, "Here's a layout. If you squint at this part ... ". Not ideal. And communicating our ideas is important, so we came up with a little photo trick.
For this trick to work, we did a few experiments until we got it right. Exploring the right angles. Climbing over chairs. Editing photos on the fly. But it works. We've written a ZURB University lesson on how you can snap photos without the obnoxious glare.
Those who believe that great design speaks for itself are likely not in the problem solving business, and that results in dumb design. Product design problems are messy and twisted, and the only way to get them untangled is to talk them out and get teams aligned on the path forward. Designers, often eager to fight for their seat at the so-called table, underestimate the training it takes to win over the Devil's Advocate in a work session or presentation.
Design work needs to be strategically presented, and conversation delicately controlled. Beside being data analysts, interaction gurus and code junkies, every product designer needs to have a bit of a salesman in him. Not the slimy let-me-tell-you-what-you-need type, but more of a smart conversationalist, who plays to his strengths and knows how to shut down doubts in his audience.
These skills can be developed through deliberate practice, much like any other facet of product design. A smart presenter knows when to push back, when to give in a little, when to go for the close and when to crack a joke.
Prepare for the Inquisition
Preparing for battle is where it all starts. We know, there are no wrong answers in design. Just don't say it to the naysayer. A blurted-out euphemism can open up a designer to an onslaught of skepticism.
Assuming a designer can charm his way past the Devil's Advocate is a rookie mistake. Being prepared for the worst, every single time, is how designers win meetings. He has to know without a shadow of a doubt why he's placed that button on the left and not right, or why he's laid out products in a grid instead of a carousel that a manager suggested. Coach designers to speak with decisive conviction, like the expert they are. But more on conviction later.
To know their stuff, designers have to learn the stuff. And not just designers, but design managers as well. Being hungry for design information sets designers (and managers) up with a comforting knowledge base, so they're able to pull out a poignant proof point at a drop of 'Are you sure..?'
We call it being design literate and make a daily ritual of hunting for great work and research, documenting it across our library of resources, including Design Quips for data and Design Triggers for behavioral patterns. Sharing these resources with each other and the design community, we want to make sure no designer goes into presentation without hard evidence to back them up.
Attack is the Best Form of Defense
When a designer is well versed and design literate, the power of knowledge is on her side. She should use it, like a sword! Don't make the mistake of assuming an audience knows why something is designed the way it is. A well-timed 'because' statement clearly explains the decision, preempts scrutiny and positions her as thoughtful. For example:
We'll provide a detailed confirmation page at the end of checkout, because customers like having a sense of closure.
The designer should never try to wing the presentation. Not many of us can come into a meeting and speak lucidly off the cuff — and we've met them both. Instead, she needs to do her homework. What does the design do for the business? Did she hear something in user interviews that supports her decision? Is there research she can cite? All the materials should be prepared ahead of time, and key points that need to be made, should be written down.
Then, anticipating a roadblock is better than reacting to one. Has the stakeholder asked about a certain feature (say, checkout flow) in the previous presentation? It's best to address that elephant right away. Setting up the call with 'Today we're discussing the product presentation and will be tackling checkout flow in the next round' gives them assurance that their request has been heard.
Survey the Landscape
Being ready with solid reasoning and articulate presentation is an awesome plan. But people are unpredictable. Maybe they feel their job is on the line. Or maybe they're having a personal crisis. Or maybe their child is running a fever. A designer can't prepare for it all, but he can watch and listen for cues in tone, expression, posture, and steer the conversation accordingly:
- Is your point of contact hesitant to give feedback? They might be doubting the designer or themselves. Have the designer double down on the proof points and ask specific questions, like 'Do these dropdown options make sense?' or 'Does this contact form give you the information you need?'
- Someone getting aggressive or confrontational? The designer should stay calm and positive, and ask them about their concerns. She shouldn't push back. Just listen. These concerns will need to be addressed later, definitely, so make sure he's made a note and preempts the attack next time 'round.
- Did the phone go completely silent? The team probably put you on mute and are having a side chat. This is the time for the designer to ask more questions to understand where the hiccup happened. The team might have misheard or misunderstood something. Or maybe the designer misspoke. Tackle it head on and course-correct. There doesn't need to be an answer right away. It's OK to say, 'Great question. Let us look into some research on the subject.' As long as the team feels heard and reassured that an answer is coming, everyone is moving in the right direction.
- Is someone leaning back or checking their phone? Their body language says they've disengaged or lost interest in what the designer is saying. She can bring them into the conversation with a specific question. Call on them by name. 'Bill, do you think this headline is accurate?'
- Emotions taking over and running high all of a sudden? A designer can bring them back down by making himself the butt of a joke. We've seen our chief instigator Bryan run around the room flailing his arms to break up the tension and get everyone laughing.
Build Confidence Along the Way
And now back to conviction. Great presentation starts with confidence. And if the designer is already confident in her work, then she should work on showing confidence in her voice. There are a few tricks here, too:
- Talk lower. If her pitch is naturally on the higher side (like mine), the designer can practice talking at a lower one. She'll instantly sound more confident, like magic.
- Talk slower. It's easy trip on words when the brain can't keep up with the mouth. Slow down, pause between points. It'll make the designer sound more thoughtful.
- Don't end statements on high note, like a question. It's a super common mistake, and an easy one to curb by paying attention to the voice.
- Don't fill time by repeating a point twice. Instead of building confidence, it actually does the opposite. Repeating a statement makes the designer sound unsure, like she's trying to convince everyone, including herself. It's another mistake we often see (and personally struggle with). It takes a conscious effort to break this habit.
Don't forget that a presentation is also a conversation. Designers should engage their audience. Encourage contribution. She should get off the high horse and build up the team. She should validate their suggestions and avoid a hard 'no.' Instead of 'Yeah, we thought of that too,' encourage them with 'That's a cool idea,' or hear them out and offer to look into data that resolves the question.
Designers shouldn't worry about not being the holder of all awesome ideas. Inviting collaboration brings the designer and the audience to the same side — if anyone is taking sides here — and works to the designer's advantage in the long run.
The Moment of Victory
Knowing when to put on the boxing gloves and when to take them off is how a designer learns to move work forward. By being prepared and versed in design, he shows commitment to his craft. Then, being an aware presenter helps him get naysayers on his side.
As designers practice these skills, listening and speaking with purpose, they'll find the right mix of tactics for every presentation. Being attentive and articulate. Repeating how design addresses particular goals of the project, how it solves particularly tricky user problems. When they hear the audience repeat their words, you know you've trained them well to win against the big boys.
There's more where this came from!
We have 4 hours of tips and methods it takes to win meetings and move design work forward. Sign up below to be the first to know when the next Mastering Design Feedback class is scheduled.
Hey Mad Men, advertising on the web hasn't totally kept up with the web's shift to responsive design. A campaign may include a handful of ads that work on set screen sizes (phone, tablet, desktop), but they aren't truly fluid and responsive. Additionally, if a designer needs to edit the content of an ad, it has to be changed on each ad size being delivered. Today on Playground we're launching a proof-of-concept for responsive HTML ads. Our demo ads deliver as a single, compressed HTML file, and sit well within the IAB's standards for file size. A single file means less hassle for ad designers'edit the content in one place, and your ad is ready for the gamut of screen sizes.
For this demo we took a handful of core sizes for web advertisements— the rectangle, leaderboard, skyscraper and billboard'and gave them a responsive twist. Our biggest trick is taking a leaderboard and converting it to a skyscraper on large screens, all with the same markup. We also built a nifty Sass tool to quickly string together a series of CSS-powered animations, to make those responsive ads even more slick.
There were a few technical hurdles to overcome, which you can read all about on the Playground. We had a surprising amount of difficulty with Mobile Safari on iOS 7, specifically with iframes and CSS animations. So don't be surprised if the ads look a little funky on your iPhone for now.
We found the Tavern through the Forrst
When we decided to turn Forrst upside-down, we knew that we could no longer keep calling it Forrst. This new iteration would be a place where designers could discuss and debate product design questions to improve their product design skills. We needed a new name, something that reflected this purpose and still fit within the theme of Forrst.
With that in mind, we decided on Tavern — a place where designers could come, stay and deliberate a particular question of the day. After a month of successfully testing the site with a small group, we're letting in 50 people into Tavern today.
Focusing on a Daily Single Question
With Forrst, we realized that getting critical feedback required strong presentation and not merely posting a Dribbble-like screenshot. And that was one of the reasons the community didn't thrive after Kyle was no longer part of it.
Tavern focuses on a single question each day, such as "Are designers too isolated from the consequences of their work?" There's a time limit to answer: 24 hours. The timer introduces a constraint, and designers tend to do their best work under a constraint. It also helps focus the discussion around the question of the day.
Eventually, the previous questions will be kept as a knowledge base for product designers, so they can refer to them as they do their design work. Questions will come from members of the design community, like Joe Gebbia.
This allows us to curate the question and ensure the presentation properly explains its goals. By focusing on a single question, we'll be able to create focus around the current question rather than wading through an overwhelming amount of content.
Opening up the Tavern
We've let 100 people into Tavern, and we'll add more each week. Also, we wanted the work of the community to live on — which it will now at zurb.com/forrst — and it'll be an official part of our University Library.
- Page 1 of 6
- Older Posts »