Full Transcript

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this month, Seth Earley joined us for his virtual seminar, "SharePoint and the User Experience." In this seminar, Seth shows us SharePoint's information architecture, flow, and usability quirks so that you can navigate its functions with ease. He also guides you in deciding which content types are right for your work and dispels the mysteries of SharePoint design.

"SharePoint and the User Experience" has been added to UIE's User Experience Training Library. It's closing in on over 100 recorded seminars, from wonderful topic experts just like Seth, giving you the tips and techniques you need to create great design.

Hello, Seth. Welcome back.

Seth Earley: Hi. Thanks for having me back.

Adam: Seth, for those that weren't with us last week for the presentation, can you give us an overview?

Seth: Sure, sure. So what we did was we talked about traditional information architecture methodology and how that applied to SharePoint. And I was just remembering that there was one slide that I usually use and I didn't, and that showed the typical information architecture methodology, the approach to IA best practices. And then the next slide shows the approach for IA best practices for SharePoint. And guess what: those are exactly the same.

In other words, the things that we do on a day-to-day basis when we're doing IA for any kind of environment, any kind of content management system, are the same things we do for SharePoint.

We have to understand where we are, where we're going. We have to do future state vision. We have to do gap analysis. We do strategy documents. We have to do analysis of content and understanding of our audiences. We have to do task analysis. We have to do an analysis of the detailed requirements and be able to then translate those into design elements in the SharePoint world.

And that's where I was spending my time in the virtual seminar. I was going from requirements to the solution design documents. So that's where I spent the bulk of my time in that virtual seminar, talking about the different types of design elements that we have in SharePoint and explaining what they were.

I also talked a little bit about testing plans and how we need to look at testing taxonomies, user interface, tagging, and auto-categorization. I talked about governance and socialization and the fact that we have to think about things like migration strategies upfront when we begin these processes. And metrics development: how do we measure our success?

This was all part of boiling my three day information architecture workshop down to one hour. And now I'm boiling that one hour down to about five minutes here, so I'm really giving you a high level look at this.

But the point here is to say that when we are trying to develop SharePoint information architecture, we are following many of the same constructs. And the tricky bit is taking things that we develop from a conceptual perspective. Once we start developing a sense of what our content is, we start building things like site maps, we have to decide, what are the things that we are trying to organize? So a typical site map, if you do a card sort, you might have representations of sales and marketing and operations and HR and you go into subdivisions of those areas. What do those things represent?

We have to do what I called in the webinar structural disambiguation. And it's saying that we have to say, at any level, when we choose a concept--let's say the concept is sales--we have to say, what does sales really mean in the SharePoint world? Because it can be lots of different structural elements.

We can make sales a site collection. We can make sales a site. We can make sales a library. We could have a list of items around sales. We could have a column or a metadata field that is sales-related. We could have a content type, a term, a document set, a folder, et cetera.

And so the point here is that we have to take those concepts that we come up with when we are trying to organize information and we have to align those concepts with design elements and design constructs. And that's what I had called structural disambiguation. That's my term for this process.

So that was really where we started talking about the different architectural concepts, the use of pages, the use of web parts, the use of a managed metadata service and a term store. We talked about views. We talked about navigational constructs around global navigation and local navigation and attributes for filtering and searching of content.

So we talked about a number of different pieces, and I walked through what each of those were and diagrammed those to show you exactly how, when you go from a concept, you can start building these out into site collections, sites, libraries, lists, content-typed columns, and so on.

So that was really the bulk of the seminar. And I did walk through that in a specific example of looking at some use cases for a particular company, a fictitious consulting firm. And then I talked about content prioritization based on scenarios. And then what I did was I walked through how we develop a content model for that particular type of information, how we prioritize and then how we would actually surface that information--we used the example of a case study--by building out a content type of case study and then showing how those elements would fit together in terms of a hierarchy.

And then we talked about wire-frames. And again, a lot of the stuff that we're trying to do in the virtual seminar is to show people exactly where what they're already doing around information architecture, usability, and user centered design fits in with the SharePoint world. So that's really what we're trying to do. And we talked a little bit about audience personalization and audience analysis.

So that was really the start-to-finish overview of the seminar.

Adam: OK, great. So there were lots of questions, and some we got to and some we didn't, and you and I have come up with a pretty great little list on ones that we thought were worth talking about. Donna wanted to know if you could share the best practices for design in SharePoint. Could you summarize those?

Seth: Sure. So I think the whole point that we're making is really that the best practices around SharePoint design are really the best practices around any kind of user-centered design. There really is no difference between those. What's going to happen is you're going to have challenges around translating those designs into actual SharePoint sites and site collections, and there might be some custom coding to do what you need to do.

The point is the best practices are going to have a clear understanding of your road map and your direction to have that vision of where you're going, to have executive buy-in, which you already need.

Really, to have the business users understanding what this is that you're building for them and having clear vision of what those requirements are, and understanding the specific tasks of your audiences. Building out use cases and user scenarios. I call them high fidelity use cases and high fidelity user scenarios.

Not saying the use case being the user should find sales information but what specific information under what circumstance accomplishing what task? Really to build out clear design documentation and have your design documents in such a way that you have articulation of all of your content types, that you have specifications around all of your metadata standards and structures, that you have specifications and details around your libraries, and how you're building your libraries and your views.

It's really to design it all on paper and to make sure you validate that and validate it iteratively. You've got the best practice around design is to test and validate on an iterative basis. So you want to make sure you get this in front of people as much as possible, and do user testing based on wireframes and based on use cases and scenarios.

Again, to sum it up, some people say where's the SharePoint part? The SharePoint part is really about these design elements that we have to assemble together into this user experience. In many ways, there is no mystery to it because you have to build content types no matter what environment you're in.

If you're in Site Core you do that, if you're in Drupal you do that, if you're in Jumla you do that, if you're in IBM Web Content Manager tools, I forget what the latest version of their iteration is, but they have applications. Lotus Notes we used to do that. The point here is you're building object models, content object models, and you're building windows into those objects by putting them into libraries and then you're leveraging those libraries.

When you think about it, you could do custom development around SharePoint. You could change the navigation and you could change the look and feel and use those libraries as the repository for your elements and leverage the metadata and workflow processes and so on. You can use web parse to surface that information in HTML pages.

There's a lot that you can do. The question is what can you do out of the box versus what do you have to do customization for?

Adam: Craig asked about structural disambiguation, which we mentioned in the presentation. Is that something specific about SharePoint or is it something in regards to your point of view on good user centered design process?

Seth: Yeah, I kind of stole my thunder on that when I was doing the overview. That's my term and I think that term is just saying that when we have a concept we have to say what the concept will be. So we have to disambiguate it from a design perspective. We have to say what design element does this concept represent and that's where I was going with that sales example, that sales could be used at multiple levels in our design hierarchy, really.

That's my term. It's my way of saying it. I like to say disambiguate.

Adam: Good. Thanks for the clarification. There was something that you spoke about in the seminar that had people going hey, what did he just say? Can you say more about that? That had to do with you saying not to use folders. Can you clarify and elaborate a bit more on that?

Seth: Sure. Sure. I think it's very easy to get lazy and use folders and just say I'm just going to put this in a folder. I think that shortcuts the thought process. When you need to think about the structure, the isness and aboutness of content, you can use folders in very rare circumstances. You should attempt not to use folders because you can typically do the same thing with metadata structures, with content models.

For example, if I'm putting in a bunch of folders around a region of the US that my content pertains to, someone would have to dig into each folder to see what's there. I can do the same thing with a metadata field called region.

I think what happens when people start using folders or start out by using folders and default to using folders or initially begin using folders, they start to do things that they should be doing with metadata.

We should be doing metadata instead of folders so that we can have multiple ways of doing our retrieval of that information and we don't get people locked into deep folder hierarchies. Otherwise, what happens is we end up replicating what we do with SharePoint on a fileshare and just bring that into a SharePoint environment. It becomes a glorified file share.

That's really the reason we recommend that you don't use folders because it shortcuts that thought process. It gets people to start relying on navigation construct versus classification and that's really what we want to do. We want to leverage classification, not navigation.

Adam: Joel asks about the kind of expertise you need to master SharePoint and a follow-up, I guess, is in your experience working with all those Fortune 1000 organizations, who is it that's mastering it? Is it the UX analysts, the designers? Who have you seen that's babysitting SharePoint?

Seth: That's a great question. There's a couple of questions in there. One of them says, what do you need for expertise around SharePoint. If you're going to be doing SharePoint design, I think if you're an information architect and a user experience designer you have many of the skills that you need, you just need to get some fluency with SharePoint. And I think the best way to do that is to get in there and start mucking around with it.

Start creating mysites, start creating content types, start working with lists and with libraries, and start actually getting your hands dirty by going into the environment and seeing what you can do. Work with navigation. You'd be surprised how much you can do without any training, just by going in and playing around.

In terms of additional skills, you can get into all sorts of Microsoft programming skills and get into a lot of very detailed Microsoft certifications. But I think, for the most part, if you have good user experience knowledge and good information architecture knowledge, I think you can do a lot with SharePoint just by going in and using context sensitive help, getting a book and teaching yourself. There's a lot of folks that do it that way.

Again, it depends on whether you're trying to become a programmer and do the more detailed integration or the more customization of SharePoint. Or if you're an architect and you're trying to understand how to build that user experience and leverage content models and metadata. Different directions.

The other question is where does this fit in the organization? Really, we see it in a lot of areas. We see that the technical organization will own the infrastructure and then there'll usually be a business organization that will own the business process and the user experience.

The problem is those areas overlap so you need to have a hybrid model. You need to have people from technology and you need to have people from business. You need to have somebody who owns the site and owns the content and curates the content.

Governance structures are very important in SharePoint, more than just about any other environment because it does take the burden away from the IT organization and puts a lot of power in the hands of the user. Again, usually it sits in the IT organization from an infrastructure perspective, but it's owned by the business area that's trying to get business value from it.

Adam: You talked about the importance of not just "putting it out there." And can you provide a bit more on the detail and cost or the impact of not applying a design process?

Seth: Yeah. It comes back to--and I have an interesting slide that I use sometimes to explain this--it comes back to what is the cost? It becomes an opportunity cost. What you're trying to do is you're trying to support a business process. When we do any kind of development we're trying to enable some kind of a process in the organization.

Our content, we're usually working at a pretty deep level in the organization by working with content sources. Maybe it's a call center knowledge base, for example. Really, the process that we measure, the process we're trying to impact would be the customer support process, for the call center, for example.

What people say is how do I measure this? You measure it by measuring the impact on the business. If you say, what is the cost of not doing it this way? The cost is not achieving your business goals, your business objectives.

The problem is there's lots of potential positive factors. It's saying if I don't do this I'm not going to be able to find my content. What does it mean to the process if I can't find my content? If I can't find knowledge based content and I'm in the call center that means I can't answer my calls or it's going to take much longer to answer those calls.

If I have to recreate content every time I build a proposal in a consulting firm or professional services firm, what is the cost to the consultant's time when we have to recreate things all the time by hand? It becomes that idea of manual creation. The same thing when you start getting into digital assets and non-text assets. Everything is digital, right? The digital asset management has a particular meaning. Non-text and rich media assets.

Those people tend to recreate a lot and go to their agencies to do so. If you can find them and reuse them then you have much greater efficiencies and effectiveness. I think it's really the impact of not doing it right. It can really slow the organization down and the goals that people are trying to achieve.

Think of it, if you start multiplying this across lots of areas. At first it might not be so bad because having something is better than nothing or it's a fresh start or whatever it is. But over time it's more and more crowded and congested and you fill it with content and you can't find that content. It just becomes a mess. I call it an information shanty town. You just can't find things. There's no infrastructure, there's no rules, there's no guidelines, there's no enforcement of compliance.

I think it really comes down to whatever business process you're trying to support, you're going to miss those opportunities.

Adam: The team at Vanguard wants to know how you're presenting wireframes and, the next step, who are you showing them to?

Seth: That's a great question. It really depends on the types of wireframes that you're creating. We create pretty high fidelity wireframes that actually use content from the site. There's no lorem ipsum, for the most part. If we're doing it as a presale we might use lorem ipsum. I don't know what the name of that type of content is, the filler content, the nonsense content, in case somebody isn't familiar with lorem ipsum. I think everybody is, though.

The idea is you put in content that's relevant because you if you just have lorem ipsum or generic content everywhere people really can't understand your design, they can't understand your wireframes. You almost have to mock it up as if it were a real site with real information for real individuals and then people start getting it. They go, OK, I see that.

Having just choice one, choice two, choice three doesn't help. It doesn't help to give people schematics because you could probably give anybody anything for anything. It really depends on your content. I've seen some wireframes that I would never want to show to an executive. And I've seen other wireframes that are really nice, that really resonate with the executives.

I think that it really depends on the context and what you're trying to explain because users typically don't conceptualize things well unless you put something in front of them to look at. And sometimes they don't conceptualize things well until you start filling in more detail and then the question is how far do you go?

I like to create higher fidelity wireframes and things that actually represent the content areas that you're looking at. That's my favorite term today, high fidelity. I've been using that a lot. I think it's to be contrasted with the generic stuff that you see a lot of times. We create them for purposes of explaining how things will work in testing user experience.

We show them to a variety of different types of audiences, but it really depends on the detail that we can put into them.

Adam: Can you talk a bit about how long it takes to create a functional organizational taxonomy?

Seth: Oh, boy. That's such a great question. These things can take anywhere from a couple of weeks to do a high level straw man taxonomy for a department level view of this, to several months to create an enterprise-wide framework. But they truly are never done, right? In other words, you create a first pass at this, but you always have to realize taxonomy is not done. We continually have to look at new terms. We continually have to evolve it based on our content.

We've created enterprise taxonomy frameworks, which is really all the big buckets and the domain model and all of the usages and all the consuming systems. And looking at an insurance company or a financial-services company, we've done that in three or four months. But then, fleshing that out and applying it to a particular area might take six months. And then we've been on projects with some organizations for five years, just on an ongoing basis.

So it really does take an iterative approach, and it really does depend on what you're trying to do. What you want to do is look at the area that you're trying to enable and then cycle through it.

You want to use an agile methodology, but create a framework, a base foundation or a framework, that understands the big-picture organizing principles and how you're going to leverage those in different systems, and then iterate through the details as you apply the taxonomy to different areas and different functional areas.

Adam: Very cool. Thank you, Seth.

One thing I did want to ask you. You mentioned the workshops that you folks do. And I know that, like UIE, you also do webinars. Can you talk a little bit about where folks can get their hands on that great material?

Seth: Oh, absolutely, yes. If you go to www.earley.com. Now, Earley is spelled E-A-R-L-E-Y. Don't forget the E before the Y. I tell people that, and I see things coming in, "early," spelled without the E, all the time, and I'm sure we would've been twice the size company if we had gotten the other domain.

But if you go to earley.com, you'll be able to go to a training area, and you'll be able to see our upcoming webinars. You'll be able to see our various types of offerings around the SharePoint information architecture courses. And we also do custom training on-site, and that's really a great way to do this. I think, if you think about the types of organizations that need to do SharePoint IA, it's really great if you can do it specifically for your problem areas. So we can do that.

But if you go to the training, you'll see SharePoint IA training and custom training. And then if you go to webinars, you'll see our monthly webinars, and we also have a big archive as well. And many of those are free, so feel free to poke around take a look at some of those materials.

Adam: Fantastic. Thanks, Seth. To everyone listening in, thanks for your support of the UIE Virtual Seminar Program. And remember, you can get all the details on upcoming seminars at uievs.com.