Making adversity your friend: three UX lessons from collaborative design

Collaborative work is a big thing right now. It sometimes seems like no one works in isolation any more — and that can be a good thing. Bringing people’s different ideas and skills together for a project can lift the quality of work and make the whole process more dynamic. But is “the more, the merrier” always the right approach?

My colleague Shant and I worked on a project that made us rethink the meaning of collaborative work and the impact it can have on a project’s outcome.

We were commissioned to redesign a website that had great content and received a lot of traffic, but lost most of that traffic due to disastrous structure. The project seemed interesting and promising, everyone seemed on board, and we thought it would go smoothly. But from the very beginning challenges cropped up.

In collaborative work, finding that sweet spot where different people’s ideas and talents come together and flourish can take compromise.

Collaborative managers: The power of alliances

The person who had commissioned the redesign, who we’ll call Katie, no longer had enough time to dedicate to the project. So she brought in another person to help her. We’ll call him Peter.

We first met Peter during a meeting about advertising options on the new site. This is where it started to get interesting. Peter had very different ideas about what made for an easy to use and nice looking website. He liked the abundance of banners on the existing site and was taken aback when we suggested taking some of them off the new one:

Different ideas about good design can be a stumbling block in collaborative work.

Peter: But what about the skins, the tower banners? Where would they go?
Us: We suggest getting rid of them and using leaderboards and MRECs. These banners are responsive, so the clients will get more exposure on mobile devices.
Peter: But I kind of like the tower banners. They are so big, really hard to miss!
Us: But they’re not responsive — that means clients with those will miss out on 40 per cent of exposure!
Peter: Well… Why can’t you make the tower banners responsive?
Us: We are trying … If we convert them to leaderboards, they will be!
Peter: But I like the tower banners. I have an idea! Let’s make the tower banner take up the whole screen on mobile. It will really stand out!

Thankfully, as part of “team redesign” we had a project manager who had been in charge of that website for more than three years. She was aware of the problems with advertising and helped us convince Peter and Katie to let the tower banners go. She contacted the clients and told them about how the new site would give them more exposure on mobile devices if they switched to leaderboards and MRECs (medium rectangle-sized advertisements). The clients didn’t have a problem with it, so Peter and Katie were able to let it go.

LESSON 1: Remember the power of alliances
In this case we were dealing with people who didn’t have complete trust in us because the concept of “design with a purpose” was very new to them. It was scary for them to let go of their old security blanket (in this case, tower banners), even though they understood how inefficient they were. They did trust the project manager because they had worked together for several years, and she knew the shortcomings of the website all too well. By getting the project manager on our side and cultivating a relationship with her, we were able to ease the collaborative process.

Collaborative goals: Facts are your friend

The next memorable meeting was when we presented the new model for navigation. When we came to the boardroom, instead of the four people we’d expected to see (Katie, Peter, project manager and developer) we saw 17.

It turned out that Peter and Katie had read an article about collaborative design the previous day and got very inspired. They decided to make it really collaborative and involve all sales reps in the design process.

Initially we were meant to present our model and explain the reasons behind it. However, the sales reps had a different idea of how the meeting should go and decided it was a good time to brainstorm.

Rep 1: Your new navigation is kind of small. What happened to the 37 categories we used to have?
Us: Well, you see, these categories are related to each other, so we grouped them together under one label.
Rep 1: Hmm. I don’t know if I like that.
Rep 2: I think I could sell more ads if we made the clients feel more special!
Us: How would you make them special?
Rep 3: I know! Let’s make a separate category for each client!
Us: What do you mean?
Rep 3: I mean, in the navigation bar, let’s make every client a tab!
Us: Hold on, do you mean all 347 of them?
Rep 3: Oh yes! And let’s make them all different colours!
Rep 1: Yes! It will be really special; we can tell clients they will each get a spot in the main navigation …
Rep 4: And they will all stand out!
Rep 5: Yes, that sounds great!
Us: Wait, it will be impossible to use!
Peter and Katie: No, it will be fine. We like it, let’s do that!

The entire meeting turned into a lesson in which we explained that the main navigation is not there to make clients feel special, but to help people use the site. We also went back to the original brief and research which showed that having 347 clients in the navigation bar would take them further from their goals.

LESSON 2: Whatever crazy ideas are thrown at you, remember to stay calm and breathe
However fast team members multiply, remember to stay Zen. Regardless of how surreal requests from the client are, remember that the original brief, goals and research are your best friends in collaborative design.

Collaborative chaos: Anything goes

Once the new structure was approved, we needed to test the strength of the labels. We organised a card sorting session, recruiting people who fitted the audience profile. The day came, we showed up with a stack of cards, and we started setting up. The door opened, we turned to greet our first person and we saw … a sales rep.

At first we thought the reps who started pouring in had a question, or that the boardroom had accidentally been double-booked. But it turned out they had come to do some card sorting! Apparently, earlier that day Katie and Peter had had a brilliant idea: why hire random people when there are 12 sales reps wandering around the office? They cancelled most of the recruits who were meant to come and sent in the reps instead. All at once. Without telling us.

Some of the original recruits still showed up at allocated times, and luckily there were two of us. So we split into two groups, one testing the reps, the other the recruits. The session with recruits was full of insights, of course. The session with reps was very different. It went something like this:

Rep 1: These are not the sections from the current site.
Us: That’s right. These are for the new site that we are working on.
Rep 1: But I don’t understand, why are they different?
Us: Because we are changing the way information is sorted. Just think about how you would group these cards together …
Rep 1: But we don’t have these on our current website!
Us: Okay, imagine that this is a completely different site. You are on someone else’s site, an imaginary one. How would you group these cards with words so that they make sense?
Rep 1: Well, they wouldn’t. I don’t see my client’s name on the card!
Us: But you are on a different site, the client is not listed there …
Rep 1: Well, if I was on another website, I would like to see my client. As a group of its own.

We also had this conversation:

Us: So, do you mind walking us through how you organised the cards? I can see that you’ve just put them next to each other in a line?
Rep 2: Yes, each card is a category.
Us: Okay … And what would be under each category?
Rep 2: Nothing. All categories should be separate.
Us: You don’t think that some of them belong together?
Rep 2: No. Each one should be separate.
Us: Why?
Rep 2: Because then I can probably sell it to more clients. Each category would be a priority.

Card-sorting sessions can give valuable, but not always pleasing, insights to how people prioritise and structure information.

LESSON 3: “In the midst of chaos, there is also opportunity”
This is straight out of Sun Tzu’s The Art of War. By keeping an open mind to the things that were happening, we were able to turn our disadvantage into an advantage. Even though sales reps were not the people we recruited, we were able to use their results. The contrast between the two groups was so strong, it helped us illustrate the point even better to Peter and Katie.

 

Even though at times it seemed like this collaborative project was heading down the road to disaster, it was a great experience. In addition to the regular challenges, we encountered many that we couldn’t possibly have predicted when we started. Although you may not face those exact challenges, at some point you might have to deal with something equally bizarre. Remember the three things that will help you succeed:

1. Securing the trust and support of as many people as you can
2. Wearing a big smile, and wielding research and brief as a shield
3. Treating chaos and disruption as an opportunity

After all, the work of the designer, like everything else, is an achievement in spite of adversity, not in the absence of it. For without adversity, there would be no achievement.

What bizarre situations have you found yourself in that were caused by collaborative design gone wrong? How did you handle the situation?

The post Making adversity your friend: three UX lessons from collaborative design appeared first on UX Mastery.

by Vera Kravchuk via UX Mastery

7 Reasons NOT to Use a Static Site Generator

In my previous article we discussed reasons why you could benefit from using a static site generator. To recap:

• A static site is a collection of pages contained in basic HTML files. You could hand-write these in a text editor but managing assets and repeated elements such as navigation can become problematic.
• A Content Management System stores page content in a database and provides facilities to edit and apply themes. Management becomes easier at the expense of flexibility, performance, server requirements, security and back-ups.
• A Static Site Generator is a compromise between using a hand-coded static site and a full CMS. You generate an HTML-only website using raw data (such as markdown files) and templates. The resulting build is transferred to your live server.

Popular static site generators include Jekyll, Pelican, Hugo and Metalsmith -- see StaticGen for many more options.

An SSG appears to offer the benefits of both CMS and static worlds but they will not be suitable to every project…

Continue reading %7 Reasons NOT to Use a Static Site Generator%

by Craig Buckler via SitePoint

What Should You Sell in Your eCommerce Store?

I recently did a Reddit AMA on dropshipping eCommerce, and the most frequently asked question was “What should I sell online?”

So I decided to write a guide on how to choose the products to sell in you store. And, I mean literally to sell, not to just have in your store.

[author_more]

You can import dozens of products into your store in minutes, but the tricky part is knowing which products you should use in your marketing campaigns, feature on the front page of your store, and include in your promotional emails.

These main products that you are going to focus on are called ‘Alpha Products’. These are the products that bring the traffic to your store. After you know the Alpha Products, it takes no time to fill in the rest of the store with cross-sell, upsell, and related products.

I have structured this article into two to parts: Generating Product Ideas and Filtering Products.

My goal is to provide a roadmap for brainstorming product ideas and then filtering out the ones that aren’t worth testing.

This article will be useful for all eCommerce start-ups, small businesses, and medium businesses looking for new product ideas.

Generating Product Ideas

Brainstorm

You never start with a blank page. Your head is already full of good ideas: your hobbies, products you like, trends, exciting products that you have heard of.

Write everything down that comes to mind. It doesn’t matter if you think the product will be a best seller or not. Trust me — write it down.

Browse Other Shops

Back in the 1980’s, Sam Walton was arrested for crawling around stores on his hands and knees. He later told a friend he was measuring the spaces between product shelves to determine how they displayed their products.

At the time, Walmart was making $400M+ in sales, but Walton knew that there was more he could learn.

When you browse other stores, look at their offerings, best selling lists, and promoted products. Many stores have a tremendous amount of data and employ entire departments to organize their sales and pick their products. Use that information to your benefit.

Browse a lot. Browse frequently.

Here is a link list that is worth spending time researching:

Continue reading %What Should You Sell in Your eCommerce Store?%

by Tomas Šlimas via SitePoint

An Introduction to jQuery’s Deferred Objects

For a long time, JavaScript developers have used callback functions to perform several tasks. A very common example is to add a callback via the addEventListener() function to execute various operations when an event, such as click or keypress, is fired. Callback functions are simple and get the job done for simple cases. Unfortunately, when your web pages increase in complexity and you need to perform many asynchronous operations, either in parallel or in sequence, they become unmanageable.

ECMAScript 2015 (a.k.a. ECMAScript 6) introduced a native means to deal with such situations: promises. If you don't know what promises are, you can read the article An Overview of JavaScript Promises. jQuery provided and still provides its own flavor of promises, called Deferred objects. They were introduced to jQuery years before promises were introduced to ECMAScript. In this article, I'll discuss what Deferred objects are, and what problems they try to solve.

[author_more]

A Brief History

The Deferred object was introduced in jQuery 1.5 as a chainable utility used to register multiple callbacks into callback queues, invoke callback queues, and relay the success or failure state of any synchronous or asynchronous function. Since then, it has been the subject of discussion, some criticism, and a lot of changes along the way. A couple of examples of criticism are You're Missing the Point of Promises and JavaScript Promises and why jQuery implementation is broken.

Together with the Promise object, Deferred represents the jQuery implementation of promises. In jQuery version 1.x and 2.x the Deferred object adheres to the CommonJS Promises/A proposal. This proposal was used as a base for the Promises/A+ proposal which native promises are built upon. As mentioned in the introduction, the reason why jQuery doesn't adhere to the Promises/A+ proposal is because it implemented promises way before this proposal was even conceived.

Because jQuery was a precursor and due to backward-compatibility issues, there are differences in how you can use promises in pure JavaScript and in jQuery 1.x and 2.x. Moreover, because jQuery follows a different proposal, the library is incompatible with other libraries that implemented Promises such as the Q library.

In the upcoming jQuery 3 the interoperability with native Promises (as implemented in ECMAScript 2015) has been improved. The signature of the main method (then()) is still a bit different for backward compatibility, but the behavior is more in line with the standard.

Callbacks in jQuery

To understand why you might even need the use of the Deferred object, let's discuss an example. When using jQuery, it's very common to use its Ajax methods to perform asynchronous requests. For the sake of the example, let's say that you're developing a web page that is sending Ajax requests to the GitHub API. Your goal is to retrieve the list of a user's repositories, find the most recently updated repository, locate the first file with the string "README" in its name and finally retrieve that file's contents. Based on this description, each Ajax request may only start when the previous step has been completed. In other words, the requests must run in sequence.

Turning the previous description into pseudocode (please note that I'm not using the real GitHub API), we get:

var username = 'testuser';
var fileToSearch = 'README.md';

$.getJSON('http://ift.tt/1MnlJYG' + username + '/repositories', function(repositories) {
   var lastUpdatedRepository = repositories[0].name;

   $.getJSON('http://ift.tt/1MnlJYG' + username + '/repository/' + lastUpdatedRepository + '/files', function(files) {
      var README = null;

      for (var i = 0; i < files.length; i++) {
         if (files[i].name.indexOf(fileToSearch) >= 0) {
            README = files[i].path;

            break;
         }
      }

      $.getJSON('http://ift.tt/1MnlJYG' + username + '/repository/' + lastUpdatedRepository + '/file/' + README + '/content', function(content) {
         console.log('The content of the file is: ' + content);
      });
   });
});

As you can see in this example, using callbacks we have to nest the calls to perform the Ajax requests in the sequence we want. This makes the code less readable. The situation where you have a lot of nested callbacks, or independent callbacks that have to be synchronized, is often referred to as the "callback hell."

To make it slightly better, you can extract named functions from the anonymous inline functions I created. However, this change doesn't help much and we still find ourselves in callback hell. Enter the Deferred and the Promise objects.

Continue reading %An Introduction to jQuery’s Deferred Objects%

by Aurelio De Rosa via SitePoint

Monthly – jQuery Responsive Calendar Plugin

Monthly.js is a jQuery based responsive calendar plugin.

Features

• Use as a date picker, or a full fledged calendar
• Fully responsive design
• Intuitive event labels

by via jQuery-Plugins.net RSS Feed

The Results of The Ultimate CSS Survey

A little over a month ago I launched what I hope will be an annual thing here at SitePoint: The Ultimate CSS Survey – a 3-part survey aimed at gathering info on the habits and preferences of CSS developers in the industry.

Thanks to support from CSS-Tricks, Sidebar, and lots of others in the community, we were able to compile more than 6,800 entries in the three parts combined. Part one alone was filled out more than 3,400 times!

Now that we’ve allowed some time to pass, we’re ready to have a look at the results. I’ve embedded the official Typeform results from each part on this page. Below each of the embedded results pages I’ve put together a bullet list of some of the most common and useful bits of feedback we received in the optional “feedback” question.

I know this was not a perfect survey, and some of the questions did not cover all bases so to speak – so we’ll definitely improve on that next year, thanks to the feedback we received.

Continue reading %The Results of The Ultimate CSS Survey%

by Louis Lazaris via SitePoint

This Week in Mobile Web Development (#99)

Read this on the Web Mobile Web Weekly March 16, 2016   #99 Peter Cooper recommends Progressive Web Apps and What's Next for Mobile — Google’s Alex Russell gave a talk at Fluent about a new way to build web apps that combines emerging browser features to bring mobile apps up to desktop standards. (Note: Click the X to skip the login wall.) O'Reilly Media Holly Schinsky recommends 7 Reasons Why Ionic 2 Is Better Than Ionic 1 — Josh explains the specific things he likes about Ionic 2 over Ionic 1 from a development perspective. Josh Morony Peter Cooper recommends Building a Mobile-First WordPress-Powered Artists Website — A free video course covering the complete process of designing an artist’s website from a mobile-first perspective using WordPress as a CMS. CSS Tricks This issue is sponsored by Imgix Implement Responsive Images With No Hassle — Making images responsive doesn't have to be complicated. imgix handles every device size and orientation, and supports the srcset attribute, the picture element, and Client Hints. Integration is simple—try it out for the first month risk-free. Imgix Brian Rinaldi recommends Use 'rem' for Global Sizing; Use 'em' for Local Sizing — Robin Rendle explains a process for building stylesheets for a responsive site that uses both em and rem to give more control at the module level. CSS-Tricks Holly Schinsky recommends Angular 2 and the Future of HTML5 Apps — Brad Green’s keynote from Fluent on how new techniques are making it easy to use advanced browser features like Web Workers, HTTP/2, and service workers for building robust apps. O'Reilly Media Brian Rinaldi recommends Getting Started With Ionic — The first part in this series by Jeremy Wilken is a general introduction to Ionic and how to get set up. Nettuts+ Brian Rinaldi recommends Announcing Tools for Apache Cordova Update 7 — The plugin now uses Cordova 6.0.0 as a default and added some Ionic templates. The Visual Studio Blog Brian Rinaldi recommends A Never-Ending Story On Ad-Blockers — Running a popular site that depends on advertising, Vitaly Friedman has a lot of insight on the impact of ad blockers and how to deal with them as a publisher. Smashing Magazine Brian Rinaldi recommends The Web’s Original Sin — PPK thinks ad blockers are not the real problem (and affect a small portion of the web by his numbers). Instead, he thinks the expectation of free content that has always existed on the web is at fault. QuirksMode Peter Cooper recommends How To Make Users Think Your App Loads Faster — What to show users whilst they are waiting. Nick Babich Brian Rinaldi recommends My First Ionic Framework App, and what I learned from it — A developer shares code and experiences from building his first Ionic hybrid app and publishing it to the marketplace. Jorge Vergara Holly Schinsky recommends Part 6: Build an App With Ionic 2 - Navigating between pages — Part 6 in a series on building an Ionic 2 app with a focus on navigation from page to page. gonehybrid.com Peter Cooper recommends The Mobile Web Sucks. Is Google AMP the Solution? Contently Holly Schinsky recommends Cordova-Plugin-Paystack: Add Paystack Payments to your hybrid apps — A Cordova plugin for adding Paystack Payments to your hybrid apps using the Paystack Mobile SDK Native library. Tolu Olowu Holly Schinsky recommends The State of Browser APIs — An in-depth post detailing some popular browser APIs, how they work and the current status of support for them. Barış Güler Holly Schinsky recommends PhoneGap Push Plugin 1.6.0 — A new version of the PhoneGap Push Plugin was released with changes to the action button handling, the installation process and more. PhoneGap Blog Brian Rinaldi recommends FullScreen and Navigation Bar Color in a NativeScript Android app — How to customize the visibility and color of the navigation bar on Android using JavaScript in a NativeScript app. Brad Martin Brian Rinaldi recommends Using Custom Components in NativeScript — A look at creating and using a custom UI component in a NativeScript app. Bradley Gore Job listing Stop Applying to Jobs - Let Companies Apply to You — On Hired, sign up in 10 minutes and get offers from top companies like Facebook, Uber, & Stripe. Engineers get an average of 5 offers on the platform in 1 week. Try it today. Hired.com Curated by Brian Rinaldi and Holly Schinsky for Cooper Press. Cooper Press is located at Office 30, Fairfield Enterprise Centre, Louth, LN11 0LS, UK Update your email address or stop receiving MWW here

by via Mobile Web Weekly