Home » Blog » Archive

Archive for March, 2012


Interview with Brad Frost

Posted by Jacob Creech on March 28th, 2012

Does your site look great on mobile devices? Is it usable on mobile? Increasingly mobile devices are replacing our computers for daily tasks, and because of this web design and development is evolving further.

Since Ethan Marcotte published his article in 2011 about responsive web design, we’ve entered a new phase in web design for mobile. Some might see responsive web design as just another trend, but here at IntuitionHQ we believe it’s more than just a trend, we believe responsive web design might just become one of the most important changes to web design in 2012.

But what does responsive web design really mean?  Time to ask an expert in this field – Brad Frost.  We first spoke with Brad a few months ago after reading his posts about responsive design and usability on his blog.

Brad’s a very busy guy, aside from writing for A List Apart and his blog, doing interviews with IntuitionHQ and thenextweb, he’s also one of the speakers at the upcoming Mobilism conference on May 10th in Amsterdam!

We think his views on responsive web design offer great insight on this new trend.  So let’s talk responsive web design.

The interview

Could you give a brief introduction about you?
I’m a mobile web strategist and front-end designer at R/GA in New York. I’ve been focusing on creating mobile-optimized websites for a few years now and spend a great deal of time learning and talking about what goes into good mobile web experiences. I made a website that tries to make sense of this stuff. I’m also a musician (primarily a bass player) and an artist. I live in Brooklyn with my wonderful wife. She’s just as busy as I am.

What is the biggest usability challenge for the mobile web?
I think the biggest challenge for the mobile web is achieving content parity. For a long time the default mentality was that mobile users don’t want everything desktop users want. As a result, important content would get arbitrarily lopped off and mobile users were penalized for how they happened to be accessing the web. The biggest challenge then becomes to deliver a full experience while being mindful of the many constraints the mobile environment creates.

Can you tell us a bit more about responsive web design?
Ethan Marcotte coined the term “responsive web design” and he broke it down to three components: fluid grids, flexible media and media queries.  However it’s evolved into something much bigger than that. It’s become a language with which to talk about designing beyond a singular screen size and context.

Before the term “responsive web design” was around, my colleague Jack Bishop and I were using the term “adaptive web design” as a way to talk about how an experience adapts to device features and browser capabilities. As it turns out, at the same time Aaron Gustafson was writing a book titled Adaptive Web Design, which dives deep into the concepts of progressive enhancement. And that’s what a lot of this is about, just applying those concepts to more contexts.

What does responsive design mean for the future web?
It’s becoming increasingly challenging to create and maintain separate experiences for different contexts. You turn your head for a second and BOOM—there’s fifteen new mobile devices announced—all with different screen sizes, form factors, browsers and more. Because devices, browsers and capabilities are such moving targets, we need to find solid ground to stand on.  That means focusing on creating flexible foundations that provide a good user experience to a number of different contexts. So instead of maintaining multiple websites that all essentially do the same thing, we’re trying to create smarter websites that have the power to go more places.

Looking down the road it becomes even harder to predict what’s coming down the pipes. Technology is constantly building on itself and we have to deal with the breakneck speed of innovation. Anyone who claims to know what the landscape is going to be like in five years is full of it. The fact that the future is so impossible to predict is why it becomes incredibly important to design experiences that are compatible with more scenarios—present and future.

What are some of the pitfalls responsive design is faced with?
There are plenty of pitfalls and challenges that responsive design faces. First, I think that responsive web design is viewed as a panacea for mobile design by a lot of people. It’s not and it never claimed to be. Creating contextually-aware experiences requires a hell of a lot more than just adjusting layout. Sure, it’s a piece of the puzzle, but there’s other things that need addressed. User goals can change dramatically based on context, so serving up a one-size-fits-all experience to mobile users runs the very real risk of not giving the user what they need.

For example, a blog’s content is to make a readable experience for as many screens as possible, but what about an e-commerce website?  A user could be at home on a laptop trying to buy a product, but what about a mobile user? Sure, they could be at home on the couch trying to buy the product too, but they could just as well be at the mall looking at the physical product and are trying to read reviews and compare prices. For that user, the “add to cart” button isn’t as important as quick and easy access to price, ratings and reviews. I feel that these are the things we need to consider when designing adaptive experiences. Ask yourself “Why might this mobile user be visiting this site right now? What are they trying to do and what can I do to help them?”

Another big challenge is performance. I mentioned before how we shouldn’t arbitrarily lop off content for mobile users. Well, responsive design fixes that problem (unless you’re using display: none; to hide content for small screens, which you shouldn’t be doing), but it can create big performance issues. Forcing mobile users to download a ton of scripts, media and content just doesn’t make a good experience. That’s why we advocate mobile-first responsive web design, which entails tackling the constraints of the mobile environment first then build up a core experience from there. Conditionally introduce heavier media and scripts when the scenario can accommodate them, instead of trying to cram a desktop site into a mobile-sized screen.

There’s a lot more challenges to responsive design as well: it’s costs more money to produce up front, it requires rethinking the design process, it’s hard to create truly great mobile experiences without compromising the larger screen experiences and vice-versa, etc.  There’s a lot of challenges, but that’s not a good reason to shy away from adaptive design. We just need to tackle these issues head on and collaborate to figure this stuff out. Because the other options simply don’t scale.

How do you approach the actual design when developing a responsive website?
Get designs into the browser as soon as possible. That’s not to say that you can’t use Photoshop or static wireframes, it’s just that those things don’t paint a realistic picture of how things will adapt.  We’ve traditionally followed a waterfall process, but you simply can’t do that for adaptive experiences.

Typically we map out the experience in wireframes and articulate where the experience will split based on the capabilities of the device/browser (for example, here’s how the carousel looks on non-touch devices, but here’s how the interaction changes when touch gestures are supported).

From there we’ll create a working prototype while the visual design team is in Photoshop creating the general look and feel. By the time the visual team has the look and feel in a good spot, the prototype team has the basic site architecture built. The prototype team starts implementing the look and feel while the visual team moves forward with the rest of the design. From there it becomes a series of iterations and back-and-forth between all the designers. The visual team is one step ahead of the prototype team, who’s focused on implementing the previous round of visual designs. It’s not this cut-and-dry though, because the prototype greatly influences the visual design and lots of things often need revisited. It’s all about back-and-forth.

Three things make a responsive process work: collaboration, collaboration, collaboration. It requires everyone being on board with the approach, tackling problems and being willing to revisit designs in order to make them work. This is much different than the traditional waterfall process, where developers working at the end of the line are left with a lot of the burden of figuring out how to make static designs work.

Does responsive design influence content?
Absolutely. All of a sudden, our content needs to be relevant to a whole lot more contexts. We need to be a lot more considerate about how we handle content hierarchy, media and interactions across a ton of screens and scenarios.

Are images still legible on mobile screens? Is there text in the images and is it still readable? Is the image a landscape image whose subject matter becomes tiny on a small screen? Data visualization is currently a hot trend right now, and whenever I fire up these massive JPEGS on my phone I can barely make out any of the text and charts.

Sara Wachter-Boettcher beautifully articulated the challenges of content hierarchy in her post Responsive-ready content. She demonstrates how it’s natural to want to throw sidebar content underneath the main page info, but that it doesn’t necessarily make sense in all circumstances. How layout breaks can very much influence how the user receives the information, so we need to be thoughtful with regards to content hierarchy.

I think the best way to deal with all of this is again to start mobile-first and make sure that all the content on the page is relevant. The less moving parts we have to deal with, the better. Mobile is a great excuse to clean house and gut the bullshit. We have a tendency to fill space with something, anything, if we have the chance. Thankfully we don’t have that luxury on these mobile screens so we’re forced to make some hard decisions. Once that exercise is done, then think of how to take advantage of extra space as it becomes available.

As one of the undersigned on Future friendly, can you tell us a bit more about the idea behind the site?
The idea behind the site is that the future is unpredictable, so we need to be more considerate of this change as we create web experiences. We shouldn’t bemoan the fact that there’s more connected devices we need to care about, but rather we should embrace this diversity and use it as an opportunity to reach more people.

The fact that no one knows what’s around the corner is why the site is intentionally ambiguous. When we all of came together, we realized that there’s no silver bullet to these problems.  We gave some ways people can think differently in order to become more future friendly, but again, these aren’t prescriptive solutions. It was made more to capture a notion than to say “do this or else!” Ultimately, it’s just there to get people to be considerate and to get more brains working on these hard issues.

Any favorite sites or resources you’d like to share with us?
There’s no shortage of great resources out there, and I’ve been doing what I can to collect them on my Mobile Web Best Practices resources site. I also think Twitter is such an invaluable tool for all this. There’s tons of wonderful people willing to share their experience, thoughts and resources. The collective conversation and collaboration that happens on a daily basis is essential to making sense of these really big challenges. It’s really exciting to listen and participate.

What do you think?

Our thanks go to Brad for his time and insights.  We will be keeping an eye out for his upcoming speaking event at Mobilism.

We believe responsive design is a new and exciting trend we all need to be aware of.  With the growth of different mobile devices, we can no longer design for just one or two different mobile devices.

What do you think about responsive design?  Do you have any interesting insights to share? Feel free to let us know what you think about responsive design in the comments below, on Twitter @IntuitionHQ or at Facebook.com/IntuitionHQ.

 

Usability preference testing with IntuitionHQ

Posted by Kirstin on March 28th, 2012

Preference testing

Usability preference testing is when two images/wireframes/screenshots are shown side by side, and users are asked to make a choice on which one they prefer based on the test criteria that you set for them – generally along the lines of a ‘which design do you prefer?’.

Preference testing is really useful for testing a range of different things: it can help you to better understand conventions in design (as shown in our ‘The User Experience and Psychology of Colour’ article on Spyre Studios), for example looking at preferences across cultures and understanding how small differences can affect your users. As with A/B usability tests, there is a huge range of different aspects you could test in this way, from colour palettes to navigation wording.

IntuitionHQ makes it simple to set up a preference usability test.  Here’s a step by step guide:

Step 1 – Write your test

Follow steps 1 and 2 from our IntuitionHQ quick guide post in order to set up your test. Once you are presented with the first ‘Question for task’ screen enter a question worded to direct the user to click the screenshot they prefer for example:

Q.  Click on the image of the buttons you prefer.

Then upload a screenshot that displays each design side by side, in this example the screenshot and question are testing wording preferences on the buttons:

In this case the testers would be familiar with the site and the process the buttons represent. Using a preference test gives an idea of what works for users and helps confirm initial thoughts on design and structure.

Step 2: Interpreting results

As with other types of usability testing with IntuitionHQ, view the results on each question/task by clicking ‘replies’ in the Project Overview:

Your results will show you where the majority of participants have clicked and therefore which design was preferred by participants.  You’ll also be able to see the average length of time participants took to respond. A lengthy average response time can indicate a couple of potential issues – either your question was confusing or the differences between designs were indistinct. Either way it’s definitely an indication that something hasn’t been clear to participants.

With the rise and rise of mobile use and mobile applications, preference testing isn’t just for websites, consider testing your apps as well, here’s an example of a popular social networking site and how IntuitionHQ could be used to test user preference in navigation:

Q. Which navigation layout do you prefer?

Consulting users on their preference can be useful to either confirm the usability of your site or highlight areas in which there are problems. Once you have the results of your test you can decide if one route is more appropriate than another or make further changes and re test. Preference testing gives you an insight into what the user finds most effective.

 

A quick guide to A/B testing with IntuitionHQ

Posted by Kirstin on March 20th, 2012

A/B Testing for Usability

A/B Testing is a method for testing variations in live sites; you can have two different variations of a text, button or other element and find out which one works best. You can easily create an A/B test using IntuitionHQ, this post gives you a step by step process to set up a test.

A/B testing is achieved by sending roughly 50% of the sites traffic to the different variations (either A or B – not both) and seeing which one works best by analysing the results. Whatever ideas you have to test, whatever variations you can think of, just upload them, set a task, and see which one works best. The great thing about this is you don’t need to make changes to your live site, and it’s easy to add multiple tasks to test different variations.

 

How to set up an A/B test

Step 1: Select A/B test 

Follow steps 1 and 2 from our IntuitionHQ quick guide post, then when you are presented with the first Question for task screen, select the link in red, ‘Click here to make an A/B test with two screenshots’:

 

Step 2: Upload two screenshots

You will then be presented with one question field and upload options for two screenshots, A and B:

Enter your question, for example ’Learn more about our project management approach. Upload the two screenshots.  When your participants take the test 50% of users will see the first screenshot and the question and the other 50% will see the second screenshot and question.

 

Step 3: Preview your A/B questions

To view the questions with both screenshots present go to Project Overview – Tasks and click on the number adjacent to either A or B under the Replies column.



You’ll then be able to see your question with both screenshots displaying side by side.

 

Step 4: Interpreting the results of an A/B test

To view your results go to the published project in your dashboard and click on the number under the Replies column:

From the results – we can see that on screenshot A, 25 of the participants clicked on the ‘working with Boost’ navigation, whereas on screenshot B only 21 participants clicked the alternative navigation item -’agile’.  This A/B test result indicates that ‘working with Boost’ works better as a navigation item than ‘agile’.

Following the steps above allows you to set up an A/B test to test variations within your site design. We hope you’ve found this quick guide useful and we’d be grateful for any feedback you have on creating an A/B test with IntuitionHQ.  You can comment via the comment box below or email us on [email protected]

 

 

 

 

 

 

 

Changes to IntuitionHQ plans

Posted by Jacob Creech on March 14th, 2012

Many of our users have upgraded to our monthly subscription plans since the introduction of monthly plans in December 2011.  Some of our users are still on the Pay per Test service and pay $9 per published test. After careful consideration we have decided to discontinue our Pay per Test service at the end of March 2012 and move those users to our Free plan. Users who paid per test prior to the change over will still have access to all their previous tests and results.

A free plan allows you to have 1 live test at any given time, view results from 10 participants and have unlimited questions.  To increase the number of participants and live tests check out our other great plans.

We’re changing from Pay per test to free plans for the following reasons:

  • we believe the monthly pricing gives us the chance to provide a better service for all our users.
  • monthly pricing is perfect for users who run lots of tests.
  • it makes it easier for us to plan for future development when we have a clear view of our users and their IntuitionHQ plans.

The transition to a free plan does not require any action from our Pay per Test users and will have no effect on previous paid tests.

We are committed to keeping our users happy so if you have any questions, comments or feedback about IntuitionHQ, feel free to let us know in the comments below, on Twitter @IntuitionHQ or at Facebook.com/IntuitionHQ.

Tags:
Posted in: Tweets
 

Improve design sign off with IntuitionHQ

Posted by Kirstin on March 7th, 2012

Use IntuitionHQ for usability testing to increase your team and your stakeholders’ involvement in the design process. We’ll help you make the design approval process less painful by explaining how. We’ll also give you some ideas about how you can familiarise your team and stakeholders with your design as it evolves.

The scenario

You’ve met with your  client and their stakeholders and everyone has agreed what your site design needs to achieve. Armed with this information you have produced a design that you believe fulfills all requirements. Your client circulates your design to the highest level of stakeholder only to find that the person at the top of the chain doesn’t like it. You then spend additional time iterating the design until the senior stakeholder is happy. A process that should have been straightforward has now taken way longer than expected.

What could you have done differently?

  • socialise your design
  • an IntuitionHQ usability test on your wireframes
  • your graphic design

Socialising your design
Socialise your design, get your design out there at every opportunity you can. According to Wikipedia, the mere-exposure effect is a psychological phenomenon by which people tend to develop a preference for things merely because they are familiar with them, so expose the highest level stakeholders to the design right from the outset.

Start with wireframes
Try starting right from the wireframe stage. Expose your wireframes to your senior stakeholders by creating a test in IntuitionHQ. This involves stakeholders right from the start and lets them contribute to the design process by providing structured feedback.

A usability test on your wireframes also allows your senior stakeholder to start becoming familiar with the design as it evolves. You might like to produce an A-B test or a preference test  using IntuitionHQ. In an A-B test 50% of your testers see one design and 50% the another so that you can use test results to gauge which design works best. In a preference test two versions of a design or aspects of a design are presented side by side  and the tester is asked to click on their preference.  A preference test can enable your testers/stakeholders to have a direct input to the design direction.

Graphic design
Similarly once you have your graphic design make sure you expose it to the senior stakeholder as early and often as possible. Often people will become distracted by surface features (like colour) when feeding back on a design. If you’ve exposed your site design including navigation and layout as early and often as possible you’ll find your senior stakeholder will be engaged in how the design works for the user rather than becoming bogged down by personal colour preferences or particular graphic aspects. Think about displaying your design on a wall in the office, and have it present at each meeting during the design phase.

So get your design out there:

  • start early, expose it often
  • have the stakeholder involved in testing
  • have stakeholders think about what the design needs to achieve rather than about colours and other design elements
  • present the design at each stage

We’ve found the design process and design approval is a far smoother task when we involve the senior stakeholder early and often.