I've been confirmed as a speaker at SharePoint Saturday Houston Saturday April 28 2012! Looking forward to meeting some new SharePoint folks as well as seeing some old friends.

I'm presenting "UX & SharePoint... Why Bother?" again. Explaining User Experience and how UX techniques benefit a SharePoint project. Make sure and stop by!

Very excited to be added to the speakers list at SharePoint Saturday Austin this weekend! I'm a last minute addition to cover for another speaker who could not attend. One man gathers what another man spills!

My presentations is titled "SharePoint & UX... Why Bother?" discussing User Experience and its Importance to SharePoint. I hope to see you there at the session or at least If you manage to notice that I am there, please stop by and say "Hi".

Stay Weird!

Ah, the fine art of wireframes. Probably the most recognized tool of the User Centered Design process. It's used in a many of today's application and web design projects. There are applications to help you wireframe. Websites about wireframing. Even groups to show off your wireframes. Some wireframes are pencil some are digital. Some are sketchy some are clean. What "wireframe" means goes beyond style these days and it seems to change depending on who you talk to and when you ask them. The clarity or lack therof is not in the drawing but in its purpose. Let's look at wireframing and see what it means to us now.

CONTEXT

Definition

Wireframes are rough sketches or drawings representing the page layout. The drawing can contain such things as page elements, content inventory, and annotations.

Wireframes are not graphic design and don't have anything to do with visual design. Keep saying that; it might help later.

Back in the Day

The idea of wireframing started out simple enough. It was born from a need to create quick drawings for content placement, hierarchy, and interaction. We used paper and pencil or a white board and the world marveled at how fast our teams could design and develop solid solutions.

Current State

The way wireframes are being used today is changing. Time to market is becoming shorter. The kinds of interactions being represented are richer. And honestly there is more buy in from stake holders towards the process of “user centered design”. Visual communication is now at a premium and wireframes seem to be the commodity of choice.

HOW WIREFRAMES ARE USED TODAY

Requirements gathering

Wireframing, in this sense, is done with zero documentation to work from. This is the documentation ideally created during a work session or two. Wireframing can speed up gathering requirements and improve communication. The main idea is to make drawings that everyone can see and come to an agreement on "what the application needs to be". Great tool for national or global teams.

The deliverable from this is not to be used as a UI wireframe document. During the requirements gathering no one really cares to discuss content relationships and appropriate hierarchy at that level. There should not be time for that. It might, however, be a great start to the next conversation.

Information and Interaction design

This is the traditional process and deliverable that has been attached to the word "wireframe" for so many years. Based on documented requirements, client input and whatever else the UX practitioner is handed and expected to make UI magic from. This is a road map for the user interface and interaction design to be reviewed by the clients stake holders, SMEs, as well as, Technical Leads and even Graphic Designers. Still a very rough set of drawings built for rapid iteration and constant feedback it’s a good idea to make expectations clear that this is not visual design, but the information design.

Development schematic

This purpose to me is the most laborious. The level of detail here is not what was intended when wireframes first became a thing. However it does cut to the chase for the guys in the trenches. This drawing is a blueprint pure and simple. The level of detail here is down to the user control and the line length of the text. It makes my head hurt writing this paragraph.

EFFECTS OF PROCESS

Water fall

Traditionally this process allows for more time between deliverables so the drawings can be more detailed, but the danger here is… well the drawings can be more detailed.

It's important to set expectations on effort and purpose of the drawings. As the project moves from stage to stage if the intent of wireframing becomes blurry things can get messy.

Agile

The quick iterations between reviews I think plays into the strengths of wireframes. The one huge caveat being the really detailed blue print for the developers. It can be problematic making the deadlines with that much detail. The UX practitioner needs to know his/her technical stuff and perhaps even rapid prototyping is more useful than wireframes once some of the more high level questions are answered.

HOW SHAREPOINT ADDS A WRINKLE

Client Side

Unlike most custom applications, with SharePoint the casual user will likely have some ability to edit the site in some way. Wireframes can be used to help define areas of interaction and who can do what. Also, each web part is its own little peice of business logic and wireframes can help decide which ones can be used and what explain what it is they do.

Administration Side

When creating a site or application with SharePoint administration and content management functions are part and parcel with the framework. Wireframes can help make clear what that experience will look like.

At the end of the day

It’s all visual communication and wireframes still look like ugly drawings of web pages, but the difference is the intent of the drawing and the audience that will digest it.

I’m pretty sure that making up rules for usability based only on the W3C standards or any other set of recommendations that changes with the speed of mud and developed by a group of people who don’t make a thing is as bad as designing a site with only technical requirements in mind.

Oh and by the way, click the link below to read more.

Please familiarize yourself with the out of the box web parts and controls. Learn not only how they work, but also the limitations of each one. Wouldn’t hurt to brush up on some popular third party web parts as well.

This will keep your designs/wire frames/work flows more in the realm of executable and less in the realm of pure fantasy. As an added bonus, the developers will be less likely to plot your death if you do this.

Got tired of design quotes. Now I will offer a profanity laced tirade on user experience design each Friday. It should be cathartic.

Somewhere in the intersection of skill set, project constraints and user expectation lies a best practice.

I'm all for sharing information and learning and improving technique, but to try to create a perfect storm of steps to facilitate a UX process for a corporate standard... I'm not buying it.

User Experience Design is an odd combination of skills that make up a job title driven by industry need. The UX professional is expected to have a large toolkit with everything from human centered behavioral research techniques to the ability to communicate visually with your team, clients and whoever else has a stake in the project.

There are folks out there with very different set of tools than the ones I possess and I can not expect them to identify, design and create solutions with the same process I use. I have previously mentioned some of the things I do and when I do them. That however is not process.

For me it's pretty simple. My strength is visual communication. I use my business, communication and design experience to identify the problems that the software solution solves and then make sure everyone understands what the solution looks like. Is that over simplification? To be sure. But when you can distill a thing to its simplest form and still it works, that thing is something to hang on to. All the details are just a matter of situation and design preference.

Do you card sort? When? Why? Can you moderate a prototype or software user testing session? Can you draw? Can you collect statistics an data and glean actionable information from it? Are you good at collecting requirements? Does interaction design make sense to you? Blah blah. You evaluate the business constraints, use your toolkit to define, design and communicate.

In the end of a project, look back. See if you clearly understood the business problems, defined what a win is, kept the user in focus, designed and communicated the solution clearly. If you do that then you have used the correct process. Throw away the spread sheet, after all it is design and design gets messy.

From a design perspective, SharePoint projects are tricky. There's lots of moving parts and technical “right angles” to keep up with. I need to be on top of my creative game and have a sharp toolkit to deliver. At this point in my career, the most important asset in that toolkit is communication.

From time to time I am partnered with a team that has not worked with me or any other designer before. When that's the case it's crucial for me to communicate my process and capabilities to the team up front; in many instances before collecting requirements or even client interviews.

WHEN DO I SHOW UP?

As soon as possible, I mean that. Not as soon as the "design" phase begins, but at the beginning of the project. Why? Because the problems that are solved in the design are defined early and solved before a single pixel is pushed. If you are just having a designer "skin" the application, the resource is not being used to its full capacity and it is possible that the experience will suffer.

WHAT DO I DELIVER?

Using a generic life cycle of a development project, I'll attempt to share an overview of what it is a designer can deliver to increase the quality and value of a site. I will define some of these deliverables in greater detail in future posts.

Nothing really shocking there. However, with SharePoint not only do I make these kinds of things real, I also create lists, libraries and add web parts as needed. That means I'm delivering not just the presentation layer, but also a chunk of the business logic. That's one of the things that hooked me on SharePoint.

Very rarely do you find an argument for creating a site without a designer. Developers, Project Managers and Directors love the idea. Once adding that toolkit to the team is a reality, it does take time to integrate all the things a designer can do for maximum value.

More detail on these kinds of things to come. What is it you want to cover? Comment and let me know.

I think user testing web apps is a good thing during development. Not just a good thing. A necessary thing. With user testing you get an hard look at all your assumptions. A reality check. The sad thing is, when the times get tough, the tough stop testing. When the budget gets tight and time is of the essence; user testing is the first thing that is removed from the process. Instead, the user experience is crafted in board rooms and cubes. The result is what I like to call assumptionware.

In assumptionware, the user is only a partial known quantity at best. In assumptionware we emulate sites that may or may not be suitable by comparison. In assumptionware we use “best practices” when perhaps they aren’t best. Cutting corners on design assuming it’s a fit for the intent of the users. Always producing diminishing results.

To effectively combat assumptionware, We, the designers, have to face facts. The fact is there is always a sense of urgency driven by cost and speed of business and there always will be. What we will have to do is adapt our toolkit and approach.