• Wellness Class on M/W 10-11am
• Computer/Library Time on Tu 10-11
• Campus Exploration on Fri from 1-3pm
• Financial Litteracy on Thur from 11:30 till 12:10.

There are many reasons why you might want to start a podcast. Perhaps you have a product or service that you’d like to spread to new audiences. Maybe you do some client work and you’d like to get new referrals while simultaneously bolstering that income via podcast sponsorships. Or maybe, you just want to boost your profile in the web industry.

Sharing your knowledge in the form of a podcast can be a great way to drive any of these goals, but it can be daunting to get started and grow an audience. I’ve been a part of two video podcasts (The Treehouse Show and Doctype) and I’ve gained a lot of experience along the way. In this article, I will summarize the lessons I’ve learned so that you can get started faster.

If you’ve never seen an episode of The Treehouse Show, here’s the most recent episode:

Stick to One Subject

We live in a time of many voices. People can gather information from a huge number of sources, so rather than water down your signal with a bunch of noise, it’s almost always better to provide a concentrated shot of one thing. Give them the purest dose of exactly what they want and they’ll crave more. If it sounds like I’m talking about drugs, it’s because a good podcast should be highly addictive.

Know Your Audience

Related to picking a subject, it’s important to know your audience. What are they interested in? What types of questions and feedback do they give you? Listen to them carefully so that your personality and subject matter can adapt and feel relatable. For example, if you’re giving an analogy, some comparisons might work better than others. As you advance your understanding, you’ll even start to develop a sense of when it’s appropriate to crack jokes and when you should treat a subject with reverence and respect.

You may even want to invite questions and commentary. You could answer viewer questions during your show, or you could include a “question of the week” segment where you ask the audience something. The more you listen, the more you’ll understand exactly what they want. Then you can give it to them.

Audio and Video Setup

There are many successful audio podcasts, but I strongly recommend you create a video podcast instead. A smiling face and subtle body language creates a powerful psychological connection with your audience that audio alone cannot easily duplicate. Furthermore, this will make you very recognizable when you attend web conferences. This is especially great if you’re an introvert like I am. You won’t have to worry about starting conversations with people, because they’ll come up to you first.

Video and audio gear doesn’t factor into the success of a podcast as much as you might believe, but high quality video and audio can increase adoption of your show because it’s simply easier to watch; it demonstrates that care went into the end product. Money definitely makes it easier to achieve this, but the rapid consumerization of video kit has made it possible for one or two people to create something that still plays great. The two better known podcasts I’ve worked on have completely opposite budgets. For The Treehouse Show, our full time production crew paired with our world class studio produces a show that’s on par with cable television. Pair that with our design and dev teams working on our various web properties and you have what amounts to a multi-million dollar production. Compare this to Doctype was shot on consumer camcorders out of a spare bedroom. The Treehouse Show definitely looks and sounds better, but Doctype isn’t miles behind like it might seem. The big difference is that The Treehouse Show doesn’t consume massive amounts of my time because there’s lots of people that work on it. If you’re doing everything on your own, running a decent podcast takes a ton of work.

The top screen is The Treehouse Show and the bottom is Doctype. The Treehouse Show definitely looks better, but not by as much as you’d expect. You can get started with just a few hundred dollars and work upwards.

You could shoot video on a nice DSLR camera, but the cameras on most smart phones are so good now that a small tripod might be all you need. No matter what camera you use to capture video, you have to make sure you capture audio externally. This probably sounds obvious to many of you, but you’d be surprised how many video podcasts ignore this step and use the microphone that’s built into the camera. Lav mics are best for this, and while they can be fairly expensive for professional grade audio, a sub-$100 mic that plugs into a standard 1/8th audio jack should be all you need to get started. If your podcast grows and it makes sense to invest more money, you can purchase better gear.

Keep It Short

The Internet has dramatically constricted the average attention span, and platforms like Twitter, Vine, and Instagram have only fed into the mindset of instant gratification even further. Nobody has time for a rambling 3 hour podcast. They barely have time for a movie trailer.

If your podcast lasts for more than 10 or 15 minutes, you’re going to drastically reduce your chances of success. Keep it tight and stay on subject.

Be Consistent

Make a schedule and keep it. I recommend that you release a new episode every week at exactly the same time. Don’t mess around with this, especially once you have a captive audience.

Cable television is dying, but there’s a lot they get right. Imagine if you were hooked on a TV show and it came on at a different time every week. How would you know? If you were only half interested, would you go out of your way to find out? Probably not. Releasing at the same time every week allows you to build up the audience anticipation and then release that promotional energy in one burst. It’s a Pavlovian effect.

You should also never skip an episode. Again, drawing upon the television show analogy, imagine if the producers just didn’t feel like making an episode that week. You’d probably be pretty upset. So far The Treehouse Show has only had to skip one episode in a year of running, which is a pretty decent track record.

Syndication and Promotion

Once you’ve put all the work into creating a great new podcast episode, you should try to get as much mileage out of it as you can. You should definitely syndicate to YouTube, iTunes, Facebook, and Twitter. Beyond that, it depends on your audience. For example, if your podcast is about programming, you might want to consider posting to a few other places related to that topic. After a few days, post it again later in the week. Posts on social networks are fleeting and it’s easy for people to miss stuff amidst all the noise. Don’t be afraid to be a little bit self promotional. As long as you’re providing good information and you’re humble about it, people will generally appreciate your efforts. If anyone complains about your free podcast, offer them a refund!

All that said, don’t push to more places than you can manage, because it spreads your community thin. If you can’t keep up with the comments on 4 or 5 social networks, then keep it a little bit more exclusive to one or two places. For example, when I post a link to The Treehouse Show, I almost always post the link to our YouTube channel so that the conversation is focused there.

Monetize Your Content

You might just be spreading awareness about a product or service, as is the case with The Treehouse Show. However, you may want to monetize your podcast more directly. There are two good ways to do this, and you can even combine them if you choose to do so:

1. Sponsorships: Contact companies and services that might be willing to advertise to your audience. Then, you can create a customized mention on the show for them that will resonate well with viewers. Nobody knows your audience better than you, so most companies are happy to let you advertise their product in whatever way you think will work best. As long as you don’t bash people over the head with it, you should be OK.
2. Subscriptions: This isn’t as common, but you might even choose to charge a modest fee. You could do $1 per episode or charge some other price for a monthly subscription. A steady income for your efforts will help justify the time and expense that you invest. Over time, this could even turn into your full-time job.

Questions

Podcasts come in many flavors and varieties, so if you have any specific questions about your show idea, feel free to ask in the comments! I’d be happy to answer.

The post The Ultimate Guide to Creating Killer Video Podcasts appeared first on Treehouse Blog.

Join faculty, staff, and students in discussions related to this year's New Student Book, Enrique's Journey.

**Monday, August 25th from 3-4:15 p.m.**

See your Woolie (Welcome Week Leader) for locations or call 410-455-2300 for locations.

A web app by Julian Garnier for building and manipulating 3D shape creations in CSS. The interface is genius. One panel shows you the creation from an angle so you can see the 3D-ness of it and spin it around. The other three panes show you the creation from different straight on angles so you can drag them around in the relevant directions.

Check out a demo if you aren't impressed yet.

In the Preview Mode there is a button where you can one-click move it over to CodePen. How 'bout that?

Direct Link to Article — Permalink

Tridiv is a post from CSS-Tricks

Thanks to strong mobile Web adoption worldwide, we have seen the launch of even more responsive designs in 2012 and 2013. Most of these have been in the publishing category, but lately we are starting to see complex transactional websites, such as Currys UK, take a brave step into this new world.

For very well thought out reasons, Mojo Motors (a startup created in 2010 to provide shoppers with a better way to buy used cars) also just launched the first responsive website in the automotive market space.

When I joined Mojo Motors in May 2012 as head of UX, it had only a desktop website — but 21% of its total Web traffic was already coming from mobile devices. Of that number, 64% were from iOS devices and 34% from Android devices. It was quite clear to me that we had to think carefully about our mobile strategy when redesigning the new website. After carefully assessing the situation, we ended up adopting the responsive design approach, for the following reasons:

• We were planning to redesign the entire website from scratch.
• Our content lends itself well to this approach, and we did not have to deal with ads like our competitors.
• A large number of our users were already viewing, sharing and linking to retargeting emails on mobile devices.
• It was the fastest point of entry to mobile for us, and the cost of development, management and maintenance was lower compared to building separate websites and native mobile apps alongside a desktop website.
• Our UX and development teams are very small, agile and nimble — a key ingredient to helping a small startup such as ours get a minimum viable product to market quickly.

In this article, I’ll shed some light on the whole process and on how Adobe Fireworks fit into it.

Our Design Process And Adobe Fireworks

As any team that has taken on a responsive design project recently will tell you, the process is different and challenging, and it stretches the limits of what traditional Web design tools such as Photoshop, Fireworks and OmniGraffle are capable of accomplishing. So, to get things done, our design team adopted a hybrid approach of designing in visual tools and directly in the browser. For us, Adobe Fireworks became the workhorse visual tool that we depended on to get things done.

I’ll share the whole process that we used to craft our responsive website and the role that Adobe Fireworks played in it. To keep the content easy to digest while still providing enough detail, I will present it in two separate articles:

1. Part 1: UX and interaction design stage;
2. Part 2: Visual design and front-end development stage.

UX And Interaction Design

In this first article, I’ll share our interaction design process, the role of Adobe Fireworks and some of the other design tools that helped us bring our vision to life.

Research

Naturally, we began the process by doing user research to understand how people engaged with our non-responsive website. Armed with this information, we came up with design principles, product principles, personas, scenarios and so on to help us determine and prioritize the project’s requirements.

We came away from this process with a core set of features that would provide a consistent user experience across all platforms. The key for us was to quickly go through discovery so that we could move into the iterative design process.

Designing From the Content Out

We decided earlier in the project that we would adopt a content-first approach by allowing the website’s content to shape the grid’s structure and layouts.

Why? On a responsive website, you have very little control over content because it scales across varying device widths — and because users explicitly zoom the viewport. In addition, some content, such as images, video and ads, can wreak havoc on the layout and affect overall performance. Identifying the different types of content, their value to users and the constraints they present early on is important. It will help you to avoid headaches later on in the process.

The old Mojo Motors website, showing photo placement. (Large version)

In our project, the image dimensions, aspect ratios and placement drove the overall layout because these needed to be flexible. The reason is that, on most automotive marketplace websites such as ours, car photos are one of the primary drivers of the user’s initial engagement, next to the selling price. Furthermore, these photos are typically consumed from a feed in formats and sizes that are uploaded directly to the dealer’s system.

Another thing we decided up front was to use real content wherever we could and to avoid placeholder copy like “Lorem Ipsum” and image placeholders with unknown dimensions. We were able to rise to this challenge early on by engaging our copywriter as soon as we identified missing copy throughout the project.

Breakpoints and Grids

Before diving deep into design exploration, we knew that determining the screen widths we would support was important. For us, a healthy range between 320 and 1024 pixels was practical, based on our analytics data. We settled on three major breakpoints to support desktop and the most popular mobile and tablet device resolutions of current users. But this is not always optimal — why?

Because device specifications frequently change, as in the case of the recent taller iPhone 5 (which would be wider in landscape orientation). To mitigate this, we planned to introduce minor breakpoints and even adjust our three breakpoints as needed later during the HTML prototyping iteration stages.

Mojo Motors’ responsive grids, via the Gridset app. (Large version)

To aid in the creation of our grids, I played with a bunch of responsive grid systems from the endless choices of frameworks in the wild. We narrowed our choice to Gridset, by Mark Boulton’s team, and Gridpak, by the good folks at Erskine. Both of these apps provide a grid image file for designing in Fireworks (or Photoshop) and an HTML framework for prototyping.

One of the factors that influenced our choice of grids was the need to accommodate the “vehicle listing module” image across breakpoints. Because we had sketched out the mobile “vehicle listing module” first, we wanted to find opportunities for reuse as we scaled up to the desktop.

In the end, we went with a 12-column grid for the desktop, a 12-column grid for tablets, and a 6-column grid for mobile in portrait orientation, via Gridset. This grid choice enabled us to reuse the module from the mobile layout proportionally across the three main breakpoints. For instance, the mobile and desktop modules are exactly the same dimensions, except that we display three modules side by side for desktop.

Sketching Mobile First

I can’t stress enough how important it is to resist the urge to jump into your favorite visual tool during the initial phase of generating ideas! Trust me, this stuff is hard enough — the last thing you need to worry about at this point is setting up the technical layouts and pixel perfection. So, if you must, work in your favorite wireframing tool — just solve the problem at hand.

For me, making a few sketches of the website’s key pages at the three major breakpoints — starting with the mobile layouts and working my way up to the desktop version — and then iterating between them made sense. I personally found designing for mobile first to be an effective way to identify problems and resolve constraints presented by touch and small-screen devices.

Initial sketches for mobile screens.

To aid in creating your layouts, you might want to consider the Responsive Design Sketchbook by App Sketchbook, or the Dot Grid Book by Behance.

Creating Wireframes And Prototypes

Before discussing in more detail why we used Adobe Fireworks in our project, I’d like to be clear that I find the endless debates about which design tool is better and whether to just code the darn thing to be fruitless banter.

In the end, a good designer is a creative problem-solver, and the tools are just a means to an end. Remember that users and clients don’t really care what tool we’ve used to create the final product. With that out of the way, I will focus the rest of these articles on why Adobe Fireworks made sense for our project.

High-Fidelity Wireframes in Fireworks

The great thing about creating products at a startup is that you have no external client, so you can avoid artifacts that do nothing to move the ball forward. On the other hand, the clock is winding down as your competitor tries to get the next best thing out before you can launch yours. With this in the back of my mind, the choice of using Adobe Fireworks came down to speed, familiarity and capabilities.

High-fidelity home page wireframes for desktop, tablet and smartphones.

Because we needed to create a clickable prototype for user testing quickly, we decided to skip lo-fi wireframes and go straight from sketches to high-fidelity grayscale wireframes. Below are a few other reasons why we used Fireworks to create wireframes:

1. Compared to other tools I had considered, Fireworks has the best vector and bitmap features suitable for creating both low- and high-fidelity wireframes, detailed visual UI designs and clickable prototypes, without having to switch between multiple tools.
2. It offers a built-in set of symbol libraries, suitable for functionality that made our work quicker.
3. The native Fireworks PNG file format is at least three to five times smaller than a comparable Photoshop PSD file and is easily sharable with stakeholders without requiring any software other than a browser or simple image viewer.
4. The Pages and States features work really well for creating multi-screen layouts within a single file.
5. I was in the process of hiring the rest of my team when the design phase began, and I needed to work pretty quickly.

Multi-Page vs. Multi-Breakpoint File Set-Up

In the past, I would have advocated setting up a single file with multiple pages and a master page for this project. But due to the constraints of creating responsive layouts, I decided that using the Pages functionality for different breakpoints of the same page was more efficient. I found this to be the best way to quickly switch between breakpoints during the iterative process. This method also allowed us to keep the file sizes small and made it easy for my team to share files and work concurrently on different screens.

The Pages panel in Adobe Fireworks is used for different screen sizes of the same page.

The Layers panel in Adobe Fireworks is used to manage layout elements.

The States panel in Adobe Fireworks is used to show different states of the same screen.

The other benefit was that we could still use the States panel to document interaction states associated with each breakpoint independently. The final file structure consisted of a “Page” for each breakpoint, a Web layer, a grid layer and other layers for the website’s content. In our template file, the grid layer was placed between the content and Web layer, as shown.

Creating Reusable Modular Elements Using Symbols

In a design like this, thinking in terms of modular reusable components that can be converted to symbols is really helpful. Doing this saves a lot of time and makes it easy to update as you iterate.

One element that benefited from this approach was the car listing module. As illustrated below, it is composed of a few different elements, including a photo with a non-destructible saturation filter applied, heart and camera icons from the library, as well as styled text. Elements such as headers, branding, navigation and footers are good candidates for symbol conversion as well.

To create a symbol in Fireworks, all you have to do is select the objects and go to Modify → Symbol → Convert to Symbol, or just right-click on the selection and choose “Convert to Symbol.”

Car-listing module symbol.

Another neat thing about the symbols feature is its nesting capability. You can include symbols inside a module that you want to convert to a symbol using the same process as above. We took advantage of this feature to make it easy to vary the listing photo and flags during prototyping and in preparation for user testing.

Creating a unique module to show a different car or flag was as simple as swapping the embedded symbol within the new main symbol variation. To do this, follow these steps:

1. Select a copy of the main symbol and go to Modify → Symbol → Break Apart.
2. While it’s still selected, save it as a new symbol variation.
3. Double-click the new symbol to enter symbol-editing mode. Then, select the embedded symbol to update.
4. Go to Modify → Symbol → Swap Symbol in the menu bar, choose the replacement symbol from the “Swap symbol” dialogue box, and you are done.

Photo symbols embedded into car listing module symbol

Swapping embedded photo symbols to create other similar modules.

Visual Scaling During Design and Live View

Another thing that is quite disorienting when creating mobile screens is mapping resolutions as you lay things out on your large monitor. Without careful planning or knowledge of best practices for things like touch target sizes and legible text sizes, you could end up creating layouts that are hard to use.

One tool that I cannot live without and I highly recommend is the Live View App. It is available for the Mac, iPhone and iPad. All you have to do is place the app window over your Fireworks layout and it will let you see how things scale on a real device such as an iPhone or iPad.

Preparing and Sharing Wireframes for Design Review

Clear and frequent communication between stakeholders, developers and designers was essential to the successful completion of our project. It ensured that everyone understood the implications of design decisions and were able to ask questions.

To prepare screens for our design reviews, we just exported Fireworks PNG files directly from Fireworks into a folder. During the review, we simply dragged the PNGs into multiple tabs of the browser and discussed things. I personally prefer this method of testing desktop screens because the width of the wireframes is rendered closest to how a user would see them (compared to testing with PDF files).

“Export Responsive Prototype” Extension to the Rescue

While the method described above also worked for showing mobile and tablet screens, it was sometimes difficult for the team to visualize the scale, context and fixed viewport constraints of real devices. This is where the Export Responsive Prototype extension for Fireworks (by Matt Stow) came in handy.

Creating the quick prototype using the existing wireframe file was really easy. The first thing I needed to do was define which areas of the wireframe would be fixed width and which would be flexible widths using slices. By default, areas that have not been given slices are converted to percentage-based widths. To make a sliced area fixed width or absolutely positioned left, right or center, I assigned keywords in the “Target” attribute of the Property Inspector (PI) panel (or Properties panel). Note that slices without “Target” keyword assignments are also converted to percentage-based widths.

Visualizing responsive design wireframes using Fireworks extension.

Slices are assigned “Target” attributes in the PI panel.

Once I was done setting up the file, all I had to do was go to Commands → Prototype → Export Responsive Prototype and export as “HTML and Images” files using the default settings. These files were then uploaded to a Web sharing folder on my computer or a Web server where it could be hosted. Next, we shared the URL with everyone, and from there anyone could view the mockup on any desktop, smartphone or tablet browser. For more details on using the extension, watch the screencast on YouTube.

“HTML and Images” exported files.

Note: The prototype that is created is not a responsive HTML production framework. It is only illustrative and to be used during the wireframe review process.

To keep the distraction down in a larger group, you could also mirror your iPhone or iPad onto a projection screen using Reflector.

Projecting a mobile screen using the Reflector app.

Creating the Prototype for User Testing

Putting together a clickable prototype in Fireworks is easy and flexible because Fireworks will accept almost any graphic file format and all HTML embeds such as videos, maps and social plugins.

For us, the first step was to plan the scenarios and determine what screens would be needed to simulate the tasks that we are asking our users to perform. In our case, we used some of the wireframes that we created and modified existing screenshots for others.

To complete the prototype, each existing wireframe and screenshot was imported as a page into a new Fireworks file and given an appropriate page name. Making edits to screenshots was a snap with the help of the bitmap tools, the vector tools and the “Fill with background” command (by John Dunning). Using these, we removed elements before compositing to reflect our own data.

Once assembled, all we needed to do was add hotspots to each page and select a destination from the PI panel. On some pages, elements were added to the States panel to simulate things like hover states.

(You can check “Creating Interactive Prototypes With Adobe Fireworks” by André Reinegger and “Interaction Design and Rapid Prototyping With Fireworks” by David Hogue for more in-depth exploration of the prototyping features available in Fireworks.)

Finalizing the prototype just required exporting the file using the “HTML and Images” option, and the project was ready to be hosted on the testing machine.

Note: The purpose of the prototypes at this stage was to test the website’s flow and structure. As such, we opted for this method to export separate non-responsive prototypes for each breakpoint to get initial feedback quickly. You may also decide just to use an HTML prototype framework such as Bootstrap or Foundation if your timeline and resources allow it — we opted for the quickest way to maintain our project’s velocity.

In The Next Article

Well, that’s it for this article. I know that so many workflow options are out there, which you may want to consider when designing responsively. I hope some of the ideas and workflows discussed in this article will come in handy and inspire you to consider Adobe Fireworks for your next project.

In the next article in this series, I will share our transition from the UX and interaction design phase of the project to the visual design and front-end development iterative cycle. Stay tuned!

Note: Even with the recent announcement by Adobe that it no longer plans to add new features to Fireworks, the tool is still very powerful and offers some of the best UI design features. Also, since Adobe plans to continue to sell Fireworks (version CS6) and provide updates to support the next major releases of both Max OS X and Windows, it is still worthwhile considering Fireworks for your next project, because of its workflow efficiency, lightweight file size and many other advantages.

Further Reading and Resources

• “The Infinite Grid,” Chris Armstrong, A List Apart
• Content Strategy For Mobile, Karen McGrane, A Book Apart
• “Developing a Design Workflow in Adobe Fireworks“, Joshua Bullock, Smashing Magazine
• “Useful Fireworks Techniques and Features for Large Design Teams,” Kris Niles, Smashing Magazine
• “Using Pages, States, and Layers in Fireworks,” David Hogue, Adobe Developer Connection
• “Multi-Device Layout Patterns,” Luke Wroblewski
• “This Is Responsive,” Brad Frost
• “The Top Responsive Web Design Problems… And How to Avoid Them!,” James Young, .net

(mb al ea)

© Olawale Oladunni for Smashing Magazine, 2013.

A/B testing can help improve your web designs. Even a small tweak such as changing the location of your call-to-action button can increase sales by 35.6%. Performing A/B tests will let you verify that your design changes lead to better results.

As a web designer who strives to create high-performing websites, you probably already know about A/B testing. But in case this is the first time you have heard of A/B testing (which is also called split testing sometimes), read this introductory guide first: An Introduction to Website Split Testing.

Though A/B testing seems like a no-brainer — especially with the huge array of user-friendly tools out there like Optimizely, Google Analytics Content Experiments, and Visual Website Optimizer (the company I work for) — there are a few common mistakes that will lead you towards unreliable results.

These A/B testing mistakes could spell disaster for a website because they have the potential to lower a site’s conversion rates.

Making the A/B testing mistakes I’ll be talking about below would, at the very least, mean you’re not going to get the best data you can get for making informed design decisions.

Mistake #1: Using A/B Tests When You Really Shouldn’t

A/B testing is best used when you want to test different two versions of one variable.

For example, if you want to find out if your hyperlinks get clicked on more if they were underlined versus if they weren’t, you can create two versions of a web page: One version with links underlined (version A), and one version where links aren’t underlined (version B). The variable being tested is the hyperlink’s text decoration (underlined vs. not underlined).

In this case, you can effectively use A/B testing to see which version is better.

But for testing more than one variable, you should use multivariate tests (MVT).

Continuing on with our hyperlink example, you should use multivariate testing if you want to find the best combination for these 3 variables:

1. Text decoration: Underlined vs. Not Underlined
2. Text color: Blue vs. Orange vs. Green
3. Text style: Bold vs. Italics vs. Normal

In the case above, there are 18 (2x3x3) different versions you need to test in order for you to get the best results.

Why would you want to test 18 different versions? There could be an interaction between these 3 variables that could affect conversion performance.

For instance, green-colored hyperlinks may perform better than blue-colored hyperlinks only if the green hyperlinks were bolded and not underlined. But the green hyperlinks could perform worse than blue hyperlinks when the green hyperlinks are italicized and underlined.

However, multivariate testing requires site traffic to be divided among the different versions being tested, so I recommend using this testing method only when the web page you are testing already receives a good amount of traffic. Otherwise, the test will take too long to finish in order for you to get definitive results.

Websites with low traffic should choose A/B tests because it would be the most practical choice in the case of low site traffic.

Mistake #2: Ignoring the Sample Size

So you have just set up an A/B test on your website.

Two hours later, you get statistically confident results indicating that the web design version that has a blue call-to-action button is showing 300% improvement in sign-ups.

You jump with joy because of this newfound discovery, and now you will be committing the change site-wide.

Hold your horses!

Because the testing period seems too short, the scenario above is indicative of an A/B test that was administered on an insufficient sample size of visitors.

For those of us who aren’t stats junkies, sample size in this context is the amount of website visitors being tested.

An insufficient sample size means that the sample size is statistically too small to be an accurate representation of the entire population (entire population, in this context, means all website visitors).

When your site receives 50,000 visitors a month, a test that was run on a sample size of only 30 visitors (which is only 0.06% of the monthly site visits) won’t get you conclusive results.

The positive increase in performance in these scenarios might simply be due to chance/coincidence.

When you implement a change on your site based on an insufficient sample size, you might soon realize that your conversion rates aren’t increasing as you had expected.

Or worse: In some cases, it might even decrease. Why? If you have an insufficient sample size, the improvement you saw during the testing period might have only been by chance and there’s a possibility that, in reality, the version showing a positive improvement is actually worse when tested on an appropriate sample size.

To avoid this mistake, you will need to determine the appropriate sample size for your test. You can use Visual Website Optimizer’s free test duration calculator.

The tool will tell you how many days you need to run the test for so that you can receive reliable results. The calculation is based on the number of versions you’re going to test, your website traffic, your current conversion rate, etc.

Mistake #3: Focusing on Only One Website Metric

There are several conversion goals you can use as metrics for success, such as click-through rate, the number of sign-ups you get on your web app, shopping cart abandonment rate, and so forth.

You will often see that there is an interaction between your different website goals and metrics, and thus, using data you gather via A/B tests to improve only one of your metrics could negatively impact other important metrics.

For instance, using a design version that improves the click-through rate of your call-to-action button might consequentially affect the number of sign-ups you get.

Sometimes a change in the web design that decreases one metric is alright if it significantly improves a more important metric, such as a decrease in click-through rate is alright if you’re getting significantly more sign-ups.

You should have complete knowledge of every metric that’s being affected with your changes so that you can make an informed design decision based on your project’s priorities.

Mistake #4: Not Segmenting Your Tests

Over at Visual Website Optimizer, one of our customers ran a test to see if removing some navigation elements from their homepage could increase conversions.

The customer segmented the test in such a way that only new visitors on the site would be tested.

This made perfect sense because this was a video streaming website, much like Netflix. So, a good number of returning visitors on the site were people who were already their customers.

Since the site owner was most interested in seeing how to convert new site visitors to customers, it was a great idea to segment the A/B test.

Runing the test for all visitors on the site would have been a mistake; doing so would have skewed the results because testing all visitors would mean having a data sample that included visitors who have already gone through the conversion funnel and are already customers.

You can read the complete case study here.

Segment your A/B test if it can lead to better results for the particular test you’re running.

Mistake #5: Choosing Aesthetics Over Results

This is one of the biggest initial struggles I see designers face when they start A/B testing their work.

Here is a hypothetical scenario (exaggerated for discussion purposes): The designer believes the stock photo she picked looks beautiful with the design. She runs an A/B test to verify that it’s a good design choice.

She creates two versions to test: One with the stock photo (version A), and one without (version B).

The designer discovers that the web design gets more clicks on the "Buy Now" button on version B, the version without the stock photo.

However, version B looks "ugly" in the designer’s opinion.

What does she do now? Ignore the results and go with the flower photo, choose another stock photo, or make an informed design decision and revise the design so that it looks better without a stock photo?

Once you get into the groove of testing, you will get the hang of achieving a good balance between design aesthetics and test data.

Sometimes the site may not look as pretty as you want it to, but if it doesn’t look absolutely horrendous, choose the design that performs better.

After all, websites are tools. The purpose of a website is not to look pretty, but to achieve certain objectives like increasing online sales or getting more pageviews.

Regardless of how a web design looks, the design that is better at achieving the website’s goals should be the one that should be implemented.

Related Content

• Lessons We Learned from Our Biggest UX and Design Mistakes
• 10 Important UI Design Considerations for Web Apps
• Is It Time to Rethink Website Navigation?
• Related categories: Web Design and User Interface

About the Author

Smriti Chawla is a Content Marketer at Visual Website Optimizer, a popular A/B testing and heat-mapping tool. Read more articles on A/B testing and high-converting design ideas by visiting the Visual Website Optimizer Blog. Connect with Smriti on Twitter.

The post 5 Mistakes You Should Avoid When A/B Testing Your Designs appeared first on Six Revisions.

There’s a good chance you’re intimately acquainted with the work of Steve Matteson, it’s probably right in front of you for much of the day.

Arguably one of the most influential designers of the 21st century; his most famous achievement is the acclaimed Open Sans, originally designed as Google’s corporate face it’s now also the chosen typeface of the WordPress dashboard.

Graduating from the Rochester Institute of Technology in the late 80s Matteson moved on to Monotype via QMS, went on to found Ascender Corporation and then returned to Monotype in 2010 as Creative Type Director. Along the way he has designed dozens of brand-specific typefaces for clients such as Google Android, Microsoft Windows, Microsoft Xbox and Xbox 360, John Deere, and Hilton Brands.

Much in demand by companies and conferences worldwide, Steve was kind enough to take time out of his busy schedule to answer some questions for us:

WebdesignerDepot: You’re frequently described as an ‘American’ type designer. Do you feel there is a distinct ‘American style’ of type design? And if so, how would you characterize it?

Steve Matteson: My particular interest (historically) is in typefaces designed prior to WW II — the private press movement was a venerable heyday of beautifully rich typography. Perhaps my association with this period in time — and Goudy in particular — adds to my being categorized as ‘American’.

WD: You’ve spent a lot of time immersed in the work of Frederic Goudy, including reviving his Truesdell typeface back in the 90s. What’s the most challenging aspect of digitizing typefaces originally designed for printing?

SM: There are numerous challenges — not the least of which is the lack of ink squeeze in today’s reproduction processes. Also there is an unfortunate ‘one size fits all’ mentality of today’s graphic designers who assume a typeface will always look good at any size they choose. So many digital types look awkward or uncomfortable at sizes they weren’t intended to be used for. Some of the revivals I have done have included some ink squeeze so appear a bit ‘soft’ compared to digitizing actual drawings. The two different approaches will give very different results in the end.

Truesdell was digitized from kiss impression repro-proofs and looks very clumsy above 16pt. It needs a version adapted for large sizes that Goudy never imagined Truesdell might be used. Some day I hope to finally make this happen.

WD: Your team at Monotype recently released a series of eText fonts, bringing typefaces such as Sabon and Baskerville to the screen. Are there any other classic faces that your team hopes to revive?

SM: We’ve recently released Dante and ITC Galliard re-tooled for eText. We have new designs coming soon like one called Halesworth (by Carl Crossgrove) which is particularly nice for screen reading. We are committed to refining book types for reading devices in order to provide a more comfortable reading experience. It is truly remarkable how different typefaces look on various hardware devices — the variables of technology and resolution require a lot of careful fine tuning. Many great print typefaces simply don’t work at all.

WD: You graduated from RIT just as Macs were taking hold of the design industry, how influential was that wave of technology on your career to date?

SM: Well the timing couldn’t have been better. Every aspect of the digital typography business took off while the business of printing began to wane or change in unpredictable ways. Mastery of the Macintosh played an important role in my career but ultimately so did UNIX and Windows. I think the Macintosh offered a softer landing into working with computers full time. Prior to it I had a hard time warming up to code — I’ve forgotten probably more than I ever learned about Fortran, Basic and PostScript.

WD: You once said that Curlz wasn’t one of your most proud moments, but that it answered the client’s brief. How often have you had to compromise your creative sensibilities to satisfy a client?

SM: Well I’m not sure I’m alone in this matter. Designers often have to give in to what the clients want and I don’t think that’s necessarily always a bad thing. Sometimes there are instances where technological limitations (such as pre-defined vertical dimensions of a user interface) lead to unavoidable aesthetic compromises. Fitting Thai or Arabic scripts within a vertical space designed for Latin letterforms is a common example of this. There are also times when a client might have a certain style in mind and can’t let go of that aesthetic no matter how much you try to convince them otherwise. Type, being quite a subjective matter, will always be at risk for this kind of friction.

WD: Your client list is filled with household names: Google, Microsoft, Apple, Barnes and Noble. What is it about working with large corporations that inspires you, and do you ever work with small startups?

SM: I’ve done work for a really wide range of clients from underwear to software. The larger companies are particularly fun because there is usually a very important technological element to the project. Designing a typeface for a new screen is something I love to sink my teeth into. It means taking into account all the things I’ve learned about making type and putting it into practice for the benefit of the reader. More often than not these are the companies that really care about the reading experience and will work hard to get it right. That said, I recently received a hand made book from a private press set in my Bertham Pro typefaces. There’s a lot of reward in that tactile experience because usually I’m faced with pixels behind glass.

WD: Some of your best known work — I’m thinking specifically of Droid Sans and Segoe — has focussed on making corporate faces friendly. Is that a key request from corporations, to make them appear more human?

SM: I think the corporate world struggles with being more human now more than ever. There is an emphasis on getting away from requiring customers to talk to robots, corporations buy local goods and implement green policies. All these things add up to wanting to put a recognizably warmer face on the brand. Typefaces and typography are key to good messaging and should be a part of this shift. Of course the challenge is to not go too far and look so casual that elements like ‘trust’ or ‘commitment to excellence’ are lost in the brand promise.

WD: Corporate work has meant you’ve designed for a number of non-latin alphabets including Cyrillic and Greek. How do you judge legibility when you’re working with letterforms that aren’t native to you?

SM: Working with non-native letterforms requires a great deal of study, familiarization and sensitivity to type trends in the region you are designing for. I’m lucky to have worked with linguists from around the world to help tune the right letterform structures and proportions for scripts beyond Latin.

WD: You’ve said one of the ways you blow off steam is by carving letters into stone. Does this process inform the way you construct letterforms when you’re back at your desk?

SM: I don’t think it does. The tools are so different and I’m not accomplished enough with carving to really draw upon those skills back in the office. I think the visual perception of letterforms is enhanced when working in stone (just as it is with calligraphy or hand lettering). The nice thing about stone is you can run your finger around a curve and get a sense of whether it’s awkward or not. I think most of my designs have had capitals with classic titling proportions. I tend to more rounded O’s and narrower E, F, L for instance, rather than homogenized widths.

WD: Droid Sans had a lengthy consultation process. During the early meetings were you ever tempted to wave your hand in the air and say “These aren’t the droids you’re looking for”?

SM: Ha! Actually not at all. In fact the process was fairly typical of productive design collaborations. I had very quick feedback from Android designers as they tried various versions of the typefaces in pre-alpha products. The only hard part was waiting for a commercial device to be released to the public so long after the designs were complete.

WD: Open Sans is very similar to Droid Sans, why did Google ask for a whole new typeface rather than a ‘Droid Sans Extended’?

SM: Typeface naming is never a very pretty process. In this case I’d have to defer to the branding team at Google for this answer. Chrome branding vs. Android branding etc. Droid was intentionally narrow for mobile screens but it didn’t have ‘narrow’ in the name. Open Sans isn’t really ‘extended’ so that wasn’t really an option either. A new family name is the direction they chose.

Droid Sans (left) and Open Sans (right).

WD: Does Open Sans have a sweet spot? Are there sizes outside of which it doesn’t work?

SM: I’ve seen a lot of blog templates using the Light weight at too small a point size. I think it’s tempting to make type small and leave a lot of white space but there is a balance that isn’t always kept between usability/readability and white space.

WD: Droid Sans has an accompanying serif, and even a mono-spaced variation. Why isn’t there an Open Serif?

SM: Droid Serif was deemed adequate to accompany Open Sans. I would like to make a variant for print at some point that has a smaller xheight.

WD: Are there any existing typefaces, serif or otherwise, that you like to see paired with Open Sans?

SM: Open Sans is a rather contemporary humanist design with upright stress. As such it works well with sturdy serif designs like Georgia, Ysobel and PMN Caecilia. I personally haven’t experimented much with it but I would like to see how it behaves with Old Style book faces like Dante or even Sabon. I know it contrasts nicely with Bertham Pro because I set them together a long time ago.

WD: Web designers often use media queries to refine designs for different devices, for example you might use Open Sans for desktops and switch to Droid Sans for mobile experiences. Could this herald a return to single-size fonts, or do you think scaleability is essential?

SM: There is a lot of work going on in this area and I absolutely think it is essential. Any device over 240 dpi causes designs originally intended for print to look anemic in text. Those same typefaces might look relatively decent on the desktop. The techniques for adjusting types for optical sizing should be practiced either through adjustments in the rasterizers or in new outline designs. The hardest part is educating a design community that these kinds of nuanced things are important for the reader.

WD: As well as designing type, you’ve also designed websites. How does your experience of building type influence your website designs?

SM: My web design is probably not worth discussing — I’ve only learned how to do it to understand how type works in this medium.

WD: You’ve been involved in legibility testing for both automotive and aviation industries. Is more legible type potentially life-saving? Conversely, does bad type kill?

SM: Through our research with MIT we’ve concluded that legible typefaces decrease glance time and therefore help reduce driver distraction. But we know that so many factors come into play with regard to safety — typographic layout, color, contrast, glare, brightness to name a few. We certainly hope that we can contribute to driving safety by making information more clear to the driver.

WD: Your type designs are normally a response to a technical, or branding problem. More recently you designed Massif, reportedly not as a specific design solution but rather, inspired by your love of the Sierra Nevada. How has that process differed from your usual practice and is it a path you intend to follow in the future?

SM: Inspiration comes from many sources and Massif just happened to be an itch I had to scratch. No customer. No brief. The revivals I’ve done have been for the same reason — just wanting to see if something works. It’s very different from having a customer with a brief in mind. It’s kind of like a studio musician playing a certain style or dynamic for a guest performer — then wanting to explore his or her own sources of inspiration and expression when they’re not on the clock.

WD: As technology moves on, the demands on type will inevitably change. Do you think we’ll see a young designer reviving any of your designs in 2093?

SM: That’s such a great question I’ve never thought about. Certainly I think many types we see today are going to have to be revisited throughout changes in technology and fashion. New weights, additional languages and OpenType features could certainly be among many treatments given to my existing work. Heck I’d like to retouch everything I’ve done thus far. But if reviving any of my work becomes necessary when I’m dead and gone I hope my designs provide a good foundation for further exploration.

We’d like to thank Steve for taking the time to answer our questions.

Featured image/thumbnail, uses Steve Matteson image via Doug Haslam

Bundled Set of Web Services Contracts – only $24!