Organization Horsepower

Thinking Like a Motorcycle Racing Team

Tag: branding

4 Distinctions from the SPTech Conference: Branding, User Acceptance, Maturity, and User Experience

I was very fortunate to be asked to speak at BZ Media’s SPTech Conference  in Boston this week. My talk was “Way Beyond Portals: SharePoint as the User eXperience Platform (UXP)” where I explored the concept of utilizing SharePoint as an underlying technology for enterprise driven user experience based systems.

While there was a lot of talk at the conference about technical topics related to SharePoint, there were also quite a few sessions on brandinguser acceptance, and maturity. Unfortunately, there was also a lot of chatter that seemed to confuse the topics. It got me thinking about the distinctions between branding, user acceptance, as well as maturity and how those things contribute and factor into user experience.

  1. Branding – I have never experienced a business application that was relevant because it was branded, but I have experienced many applications that fail because they failed to attract enough attention to be relevant. “Don’t put lipstick on a pig” was an analogy I heard mentioned, but I would argue that the only time you should build a pig is if your end goal is bacon, and if that is the case, bacon is a better brand than the pig.  The distinction here is that branding is not something you decide whether or not you need, it’s a requirement. There are varying levels of effort that go into branding, but it’s just not optional.
  2. User Acceptance – There are two components to user acceptance, position and value. Branding fits on the positioning side of the equation while value determines how “sticky” the application is. There are many sites that are positioned well in terms of both branding and purpose, and pass initial acceptance, but over time fail to show sustained value. Information sites tend to fall into this position. I think that there is a place for information sites, but we need to make intelligent design decisions on how “sticky” we want those sites to be. If we want sustained acceptance we need to design in value that exceeds knowing something to include a connection to real work.
  3. Maturity – As the architect of the SharePoint Maturity Model, Sadie Van Buren is the pre-eminent expert on defining maturity for SharePoint installations. While branding is a component or indicator of a mature model, a branded site is not necessarily a mature site. While user acceptance is not a named component of the maturity model, it’s hard to imagine a mature application of technology where acceptance was not achieved. I think the real power of the maturity model is as an indicator of the willingness to leverage technology for real business purposes (value). Highly mature installations show both intuitive user experience and a clear business-based purpose.
  4. User Experience – Defining user experience as the culmination of the acceptance of a process and the ability perform a value-based behavior, it’s easy to see how important branding, user acceptance, and maturity are to user experience. It’s impossible to have a successful user experience if the design of that experience fails in any regard. User experience isn’t just a branding exercise; it also involves the performance-based design that demonstrates sustained value and maturity.

Clearly there are valuable distinctions between these topics but they are all critical components of successful technology implementations whether they are SharePoint sites or applications, and all deserve an effort in our design processes. As I continue to think and write about user experience it occurs to me that best user experience may not be a “positive” one. While we certainly don’t want to create negative experiences, if our experiences are truly intuitive and functional they are transparent in and of themselves. Positive and negative are only relative to prior experience. But I will write more on that some other time.

 

Thoughts from SHARE 2012: Three Drivers that Transcend SharePoint

I just got back from the SHARE conference in Atlanta, and while it’s true that the conference is built around SharePoint as a core technology, the conference is really intended to focus on business applications of SharePoint. I’m not going to do a blow-by-blow conference report; Kristian Kalsing did a pretty good one here. Instead, I’m going to pick out for you the three drivers that are not only critical to the success of SharePoint-based solutions but really to any business solution.
  1. It’s about the business not the technology. When is that last time you experienced or heard the tale of an executive who calls a meeting and says we need an “X”? Recent examples of “X” have included social networking, Kahn Academy, and even Angry Birds. The point being: if you simply take the order and implement your companies version of these tools, the chances of adoption are immediately in danger because nothing in the business is driving the initiative. For example, social networking in and of itself isn’t enough to merit attention, but “connecting the sales force to the engineering staff in near time or real time to shorten the sales cycle by 10 days” is something the organization and your leadership can get behind. The fact that it’s built in SharePoint or any other tool is inconsequential and may be detrimental depending on your organization’s prior experience with the tool (see #3). When it comes time to justify expense or measure ROI of your solution, having real business drivers will be critical.
  2. You’ll need a roadmap. Every project needs a plan, but a roadmap can be so much more. When attacking tough enterprise issues, you’ve got be certain about what the real problem is and how you are going to measure your fix for the problem. Your roadmap can even include governance for the organization or project and accurate requirements gathering and analysis. Susan Hanley was one of the speakers at the conference on governance and is a great resource on governance issues. Sarah Haase from Best Buy is also a great corporate practitioner; her blog can be found here. Our own John Chapin also has a blog post on roadmap creation.
  3. Branding is important (don’t call it SharePoint)! Unless your company sells SharePoint or somehow derives income from marketing SharePoint, you won’t do yourself or your users any good by naming your solution after the technology it was built in. This goes for any branded technology. In fact, if your users have a negative impression of that tool, it may actually interfere with user acceptance of the tool. Let’s face it; sometimes users cringe when they hear SharePoint but won’t bat an eye when you call it the “Sales Efficiency Accelerator.” The trick is this: when users visit this mythical application, it can’t contain the elements of poor user experience that caused them to hate the tool in the first place. Branding will get your users to overlook the underlying technology once or twice, but good user experiences will keep them coming back.

Overall, I’m glad I went to the SHARE conference. It’s nice to see a group of people who are focused on the business applications of SharePoint and not just the stability and scalability of a corporate technology platform. After all, the tools we use are only as good as what we use them for.

Pizza and SharePoint™—Branding and Design

Once upon a time, in a galaxy far, far away… I used to work for one of the giant pizza chains. As a learning professional, I took it upon myself to understand what it was like to work in a pizza store. You don’t have to be in a store for too long before a mistake happens. Wrong toppings, giant bubbles, or just plain ugly pizzas. Most operators had enough sense not to send these pizzas to the customer and would make a new pizza, but instead of wasting $3 in food cost and throwing out the mistake, these pizzas would become “crew pies” and would often sit boxed on top of the oven until someone had time for a break and would grab a slice or two.

Well, on one store trip, I noticed a sign on the wall that said “no crew pies.” My first reaction was that the store operator was sending a message about mistakes, and not making them, but the company had all sorts of slogans and signs about making quality product and “no crew pies” was not one of them, so I had to ask.

Turns out the operator had much different reasons, and it wasn’t a slogan; it was a rule. He explained to me that he was in a war for good employees with the other restaurants in town. It was hard to find and keep people, and he felt that it sent the wrong message to serve the people that worked for him the worst product his store turned out. Besides, if his team thought that bad pizza was good enough for them, how far of a stretch is it for them to expect his customers to live with bad pizza?

Fast forward to today. I am in the privileged position of consulting with some of the world’s largest companies. Companies that are selling customers some of the most advanced systems, services, and technology available. However, all too often the internal sites these companies use to support their own employees are the internet equivalent of “crew pies.” Barely branded and poorly organized. This is especially true when it comes to SharePoint™ sites.

It’s not enough to just have the information out there. The person has to first want to use the site (acceptance) and then be able to use the site (usability). Newsflash: The default SharePoint™ page templates are not attractive and are not intuitively usable. Even if you are lucky enough to have an IT department that branded the default templates, it most likely is still not good enough. Chances are if you already have an existing SharePoint™ implementation, you’ve seen these default templates in action, as have your users. They have already formed a negative impression of what SharePoint™ is and have little or no vision of what its potential is.

I’m not suggesting that all of your internal sites become graphical Flash sites with splash pages, but I am saying that at a cursory glance, your internal sites need to:

  1. Not look like SharePoint™ default templates
  2. Reflect the importance of the people, business line, product or service it is intended to support

In SharePoint™ development circles, efforts towards user acceptance are often referred to as branding, but it’s more than that; it’s part of the overall design. The goal of design should be a positive or at least transparent user experience. There are two components of user experience, acceptance and usability. Acceptance is typically the result of good positioning and good visual design whereas usability stems from information design.

If we go back to our “crew pie” example, mistake pizzas may in fact taste good, but the user experience is disrupted because admittedly user acceptance is compromised: the pizza is ugly or its usability is challenged—it has the wrong stuff. That’s not to say the crew won’t eat it, but they may not like it.

The intangible message here is that our internal sites and systems set the tone for what our employees deliver to our customers or users, and it’s imperative that our customer’s user experience be flawless. Besides, in a war for talent, our valued employees deserve better than a “crew pie.”

In my next blog post, we’ll dive more into the user acceptance side of the equation and explore some strategies for designing and validating user acceptance as part of a branding, positioning, or graphic design effort.