Simplifying an IBM Connections Community for Rollout - Part 1

Last Month, I wrote about the many problems with Connections.Cloud. One of the great things about working with IBM (as opposed to Microsoft) is that I've found that IBM are always willing to help. I had three separate contacts from IBM help me through the problem.

It became clear that IBM is aware of the shortcomings with Connections and that they're already well on the way to getting them corrected.  If all goes well, IBM will be in a much better spot than Microsoft by the end of the year. 

We managed to get the problems with our communities down to four things;

1. Dissatisfaction with the way @Mentions currently work
2. Lack of Collaborative document editing for guests
3. Usability Features
4. General Design Issues (Building without Design)

Of these, we were told that the first two can't be solved now but will be solved soon.  In that case, we had to either switch to another product (and inherit a whole new set of problems) or persevere without those features on the assurance they will be delivered in the near future.

We seriously considered the competition but decided to persevere with IBM.

Improving the Usability of Connections

The third thing, usability features, turned out to be something that we could resolve by configuring the communities better. Our IBM representative came out to our offices and explained how to do this and showed us a few examples. 

Essentially, we replaced most of the connections navigation features with our own and it seems to have made a huge difference. There's still space for some improvements in connections itself but at least now we believe that our guests will be able to use the systems we provide.

I want to go over these changes in detail but I'll do that in my next post. 

Stop Building before you "Design"

The final thing, "general design issues" was actually an internal problem - and one that I've faced many times before in other systems; The idea of building without design. 

In the old days, it used to be IT teams who built systems without design. I think that most of the IT people who were developing in the 80's or 90's can cite an interface (or ten) or an error message that they're not particularly proud of. 

It's something that I feel that the majority of today's IT teams have grown out of.  There's a lot to be said for developing with standards and libraries such as bootstrap. 

Unfortunately, one of the problems with today's systems is that by making them available for configuration by general (non-technical) users, we have once again put interface development into the hands of the untrained. 

Telling a Story, Not Showing off Features

Connections in particular, offers a richness of "applets" which in turn allows you to put "everything" on the screen at once. It's a difficult temptation to resist but if you don't resist it, you'll end up with a bunch of communities which not only all look the same but are also impenetrable to users. 

When you're putting together a community, you really need to be "telling a story".  You need to be asking;

• Who exactly will be using my community?
  We're not talking about names here, though that can sometimes help. We're talking about attributes. What kinds of age-ranges will be using the community?  What kind of experience(s) will they be bringing with them? How technical are they (mainly high, mainly low -- or perhaps they'll have a wide range of technical experience levels).
  
• What kinds of things will they be wanting to see?  
  You need to establish the language of people.  For example, unless they're very technical, they won't want to see "Files".  They might want to see "Research" or "Minutes and Agendas" or Whitepapers.  They probably won't want to see "Events" but might want to see "Meetings". Knowing what your people want is the key to labelling things correctly in Connections.
  
• What do people need to get out of the System?
  Pretend that you're a user of the system. Think about what you'd want to get out of it. Perhaps you might want to visit a forum to discuss some design tips on a product?  If that's the case, don't just give your users a link to forums, create a forum (or at least a question) on design tips or on a specific product.
  
  In fact, I think it's fair to say that your users should never ever visit an empty forum.  You need to kickstart your forum internally (with proper discussion, not just with single questions) long before the first user enters the system. 
  
• What are the top five things that a member of your community will need?
  All of the top things required by your community members should be a single click away from the home page of your community.  Anything that isn't a major outcome for your people probably shouldn't be on the front page -- or if it is, it should be much smaller.
  
• How will Announcements be Made?
  Depending upon your community, you may find that you have announcements to make. It's not enough to assume that your users will see a red circle on the bell icon and investigate. We asked our user group, what they'd do if they saw a number there and some of them told us that they'd ignore it because it wasn't part of their system. ... (wow.....)
  
  So, if you've got a particularly big announcement to make, it follows that you should reserve some space on your front page for it. 

Contracting Artwork

The second thing about building without design is the idea of "contracting out artwork" without having a clear intention. 

In particular, don't contract artwork to simply reproduce buttons with the language of IBM Connections on them. Use the words from the language of your intended users. 

What this means is use words like Minutes or Agendas or Product Details.... not "Files" 

Don't assume that your external artwork providers will know anything about connections.  Be very specific. Tell them exactly what you need, otherwise you'll find they'll try to overwrite the whole connections experience, for example telling you to change the top menu in connections to "Red" for all of your guests.  Of course, it's possible to change that colour in your own internal company but it's not currently possible for guests. 

It's critical that you establish a guest account for the people making decisions about your community. Make sure that they know what the system looks like for guests -- because it's quite different from he "paid subscriber" screen.

Below is a screenshot showing my guest user account and highlighting things we were asked to change (but can't).  The blue bar at the top of the screen, the grey panel on the side, the bell, the words in the menus, the entire left hand menu, even the user's personal profile.

Each time we said "No, we can't change that", we were met with irritation from our business users and the designers. 

Designing FOR Connections

Ultimately, the answer was to work WITH connections, and not against it. Design things that will work in connections and plan the user experience to drive them to the things you want to engage them in.

One of the best ways to do this is to get some paper with the connections banner and grey sidebar drawn in -- and a lot of white space in the middle.   

Have your users draw navigation options in the blank space and tell them that almost anything goes in terms of static pictures and text except for overlapping hotspot circles and layers (eg: Editable text on top of graphics).  

Essentially you'll need to be able to draw a table around most of the content, so it's imperative that everything can be fitted neatly into a box.  While it's not impossible, it does introduce a lot of challenges, particularly as you move between screen resolutions. 

Here's how to explain that requirement to users.... Remember, it's only in terms of hotspots (clickable items), everything else can be a picture -- so long as the loading time isn't too long. 

and here's a blank form that you can use..

A Sample Blank form you can use. The three user-configurable areas are in red.

 

Where possible, print several forms and try to encourage your users to be creative while still considering the story (journey) that they want a user to the site to embark upon. 

A Quick Example

Here's a look at one of our internal IT communities, showing something that (while it might be the right way for overly detailed-orientated IT people like myself to work) is NOT suitable for general use by guests.  In fact, after our recent experience, I think there's some serious redesign about to happen.

What NOT to do

What to Do

Compare this with one of the clean interfaces we considered once we had our heads in the right space for this project.

In my next post, (unless something better turns up in the meantime), I'll walk through the steps to build a "clean" community.