It recently occurred to me that some of you have questions regarding the general approach that's been taken with the UX Improvement Initiative as well as the current project: Improving the CLE v1.0. I had plans to elaborate on this in Paris, but given the questions I've received, I thought it might be useful if I shed some light on it now.

Initiative vs. project

There are two things happening here: The UX Improvement Initiative and the Projects that fall within it. While "improvement" is fairly broad, the initiative is not a catch-all for any and all UX activity. Instead, the initiative's aim is to improve Sakai in a fairly specific way (more on this further down).

The initiative will use a series of two-month projects, each producing deliverables that have an immediately useful and relevant purpose. In other words, projects will have well defined goals and concrete deliverables intent on solving current design challenges in Sakai.

Take the current project for example. The goals are well defined in the project's profile page and the deliverables will be a set of screens packaged up in a nice bundle I refer to as a "UX Kit" - which basically consists of everything needed for a developer to pick up and implement a design.

Notice that this approach offers two benefits:

The first is that it helps the project focus on tangible results, which keeps things from meandering without a specific outcome. That's not to say that meandering doesn't have its place - just not under this initiative.

The second is that it uncouples design from any dependency on implementation, and vice-versa. This way design can take place on its own schedule and with its own priorities within the context of two-month projects, so long as what's produced can be implemented. This gives UX folks a bit of autonomy in selecting projects and reduces the chance of being bogged down by indecision or delays that aren't directly related to design. In other words, designers can design what they think "should be" without worrying about how and if it will get implemented. If the design has merit, developers can pick it up and implement it at their leisure.

This shifts the emphasis from "code currency" to "quality currency".

Is two months enough time for quality research and design?

While the current project will result in "implementation ready" screens, not all projects under the initiative are required to. Some projects might result in inputs that will be used in other near-term design projects. For example, a project might be research oriented in that it will produce plans, definitions, and tools, but unlike experimental research, the materials produced in this project will be extremely focused.

All deliverables under this initiative should share the characteristics of being relevant to the current state of Sakai, prepared with the intention of being used in a near-term project, and developed to a level of completion that will enable them to be immediately put into practice.

Hopefully by now the focus of the initiative is becoming a bit clearer. The goal is to improve Sakai, not think up something new.

With that in mind, there may likely be a future UX initiative based on thinking beyond the current paradigm. In this future initiative, the projects will consist of more radical and forward thinking R&D that will likely take place over longer intervals with lower rates of screen production than the current initiative. This is marked by the yellow graph below.

The current project

The blue graph represents the current UX Improvement Initiative - with the star icon obviously estimating how far along we are (about ¾ of the way through the first project).

As you see by the angle of the blue graph, the rate of production is quite high. This is explained by the "catch up" effect. Much of today's design work is benefiting from the years of research and discussion that have already taken place. Since we don't need to start from scratch to improve what's already there, we get a nice bump in efficiency.

In terms for what's actually being designed, as you may already know, the current project is mostly concerned with "site setup" and other rudimentary parts of the UX - as opposed to some of the meatier academic aspects of Sakai (that will come later).

That's not to suggest that the work is entirely dry. While rearranging the existing design to flow smoothly, or what I refer to as "plumbing", I periodically toss in a few fresh ideas based on inputs I receive from others, as well as my own thoughts of course. But mostly, the brunt of the effort is plumbing.

Also, since many of the areas touched in the current project are fairly common to other enterprise applications, for example: managing users, setting permissions, changing styles/colors, etc., we can cheat a little by taking advantage of best practices and conventions in place of intensive up-front research. While this doesn't negate the need for usability testing, it does add another bump in efficiency in that we're not dealing with something entirely new and foreign.

Why "site setup"?

Some of you may be wondering why the site setup feature was selected for this first project. Without going too far into the history of how the UX Initiative began, I'll just say that site setup was an area that was discussed early on as an annoyance in the context of new users (in this case, users who have the ability to set up sites) trying to understand Sakai. It was clear from the feedback that this area of Sakai created an unnecessary barrier to those users.

So fixing it made a lot sense from a product perspective.

From a design perspective, I took a close look at how else we might cut into redesigning Sakai and found myself agreeing with "site setup" as an ideal starting point. For one thing, before the site setup process can be redesigned, we'd need to first understand what the resulting site should look like. This line of thinking was fairly attractive in that it removed some of the historic constraints that would sometimes limit a project like this.

Secondly, the site setup process makes an attractive design target since it touches a lot of different areas of Sakai while at the same time acting as a bit of an "add-on" feature – which allows the design effort to go as light or heavy as necessary without committing to more than anyone can handle.

Choosing the first initiative first

If you return to the graphs for a moment, you'll notice that the yellow graph intersects the blue graph where the former picks up and the latter winds down. This yellow graph represents a possible future initiative that will shift the design emphasis from mere improvement to broader and more philosophical questions about Sakai.

Seems like an okay plan, but some of you might be wondering why we don't just start with the yellow graph first and tackle design at a deeper and more rewarding level now in place of the cleanup work that's happening in the first initiative?

For one thing, not all institutions are prepared to accept a quantum leap with respects to changing Sakai. That's not to suggest the result of a deeper design process would force anyone to give up what they currently have, but let's face it, we'd be treading a path less travelled, so all possibilities would be on the table.

Secondly, Sakai needs help now, not two years from now. There's a lot of improvement that can be done in fairly short order with significant gains. Also, circumstantial innovation will undoubtedly be a byproduct of this effort, resulting in a substantially more robust solution than just incremental cleanup work.

Further, any plans for a long-term research project should be considered with caution in this industry since we're often dealing with a rather quickly moving target.

And last but not least, the process of working together as a team with a design lead is new to this community and taking on a theoretically less ambitious effort now will yield huge benefits later on in terms of developing a good team dynamic and building confidence based on our past successes.

Knowing when Sakai has been "improved"

I have a saying that goes: "The more we talk the less we see." It's not a riddle, I mean it quite literally. I firmly believe that regardless of where one is in the product development process, sketching ideas on paper and producing screens to visually support the discussion is invaluable! So the more screens and the faster we can produce them the better off the process.

At some point however screen production will slow. Some of the design work will register with users, and that's what we'll keep. The stuff that doesn't will fall by the wayside. Negative user feedback will be replaced by positive user feedback (or silence). And just as the graphs indicate, the process will reach a lull.

The best way I can describe the max point in the blue graph above is that we'll know we're there in much the same way we came to realize that we have problems in the current product. It'll be fairly obvious.

If that doesn't satisfy you and you're looking for something more concrete, you may want to check out the UX Scorecard I developed. It's basically a set of metrics I've used throughout my career that have proven to give some indication of quality. None of this is six-sigma, but it is a good start if we allow ourselves to put it into practice.

Where we go from here

While all of this is interesting (and hopefully exciting), the long-run success of trying to make a great product requires a shift in world view from being an observer of UX work to being a participant of it. Making lasting and meaningful UX change is by no means a small undertaking. The work is vast, cuts across all areas of the product, and is a feature of our development landscape that requires continuous attention.

I'm thrilled that as a community, Sakai has taken on this agenda, and to keep it moving we need usability folks, designers, developers, and anyone else who wants to see Sakai succeed in this area to get "actively" involved.

Summary

So that's it. That's the 50,000 foot view (oops... 15,240 meter view for many of you).

Today the focus is on tackling the low hanging fruit, cleaning up what we have, cranking out screens, and learning from our mistakes along the way.

Once we get to a point where Sakai's UX has improved a bit, we'll shift our focus from "usable" to "useful" and address the bigger strategic questions.