User Interface 12 | October 31, 2007
On Friday I’m lucky enough to be flying to Boston to attend Jared Spool’s excellent User Experience 12 Conference. I’ve seen Jared speak on several occasions, and have always found him both entertaining and educational. This was one of the main reasons we were so excited when Jared agreed to speak at dConstruct this year. If you weren’t able to attend this session, I highly listening to the podcast.
Anyway, UI12 is one of the paramount conferences on the user experience calendar. There are some fantastic people speaking and I’m really looking forward to the full day workshops.
I’m also looking forward to visiting Boston as I’ve never been there before. I’ve managed to arrange two free days before the conference where I plan to go and explore the city. If you’re from Boston or have spent time there, I’d love to get any tips of recommendations you have. And if you fancy meeting up for a beer one evening, give me a shout.
After the conference I’m planning to hire a car for a couple of days and shoot up (or down) the coast. I’m not sure where is a good place to go, but I’m keen to catch the tail end of the fall, and check out some quintal, “Truman Show” style villages. If anybody has recommendations for somewhere nice that’s a days drive away from Boston, please let me know.
Designing the User Experience Curve | October 30, 2007
I’ve been interested in how the lessons learned from game design can be used to improve online experiences for a while now. I guess this interest started when I started learning about the concept of a “flow states”.
Flow is the state of being where you lose all perception of time and you flow from one successful task to another with seeming ease. It’s great if you can get into this state at work as you feel “in the zone” and can get a lot done in a short space of time. Sadly the number of distraction in the modern work place, combined with the fact that we’re perpetual multi-taskers, makes entering into the flow state at work a rare occurrence.
The place where we’re most likely to experience flow is when we’re playing a new computer game. As you start playing a new game you start encountering a multitude of small challenges and rewards. The high from each reward spurs you on the the next challenge, creating a cyclic effect.
If each challenge was as simple as the last you’d soon get bored, so computer games create a user experience curve. As the game progresses, challenges get incrementally harder, as do the rewards. However if the challenges get too hard too quickly, people give up. So the skill is in getting the curve just right.
Creating the perfect game curve used to be the preserve of level designers and was more art than science. However as game development budgets start outpacing those of the average Hollywood movie, the market needs to expand. Blockbuster titles are no longer the preserve of the hardcore gamer, demonstrating their l33t fragging skills. Instead these games need to appeal to a much broader audience. People who want to pick up and play, without having to learn overly complicated controls.
As an increasing number of these titles are sequels, the game designers also want to make sure that people can complete the games and are primed for a sequel. Because of this, games have become less about skills and more about creating an experience, a narrative and a sense of momentum. It would be no good if your newbie gamer gets stuck on level one and gives up.
I bought a copy of Wired magazine recently, and was fascinated by an article on the user experience design of Halo 3. The developers set up a fully featured testing lab and recorded more than 3,000 hours of play from 600 gamers. Normally game testing is restricted to bug testing, but what Bungie did was usability and user experience testing in it’s purest form.
Though usability testing the developers were able to pinpoint areas of the game where inordinate numbers of players were getting lost of killed. By examining real user interaction they were able to figure out what was going wrong and come up with ways to smooth out the user experience. This involved everything from making ammo more obvious, through to channelling users in the desired direction by stopping them from going backwards.
While this could be seen as an overly prescriptive way of creating games, it’s the essence of good user experience design. By removing usability barriers and helping people achieve their goals in an enjoyable manner, you end up crafting the optimal experience.
I was really excited by this article, and think there are a lot of lessons we can learn here. Not least the importance of usability testing on the user experience. At Clearleft we always budget for at least one round of testing, and even the smallest test produces amazing results. However imagine the improvements we could make if customers really started to value the importance of usability testing and budget accordingly.
Snapshot 2007 is not CSS2.2 | October 26, 2007
While browsing my feeds the other day, I got really excited by this post on the CSS working group blog.
There was a lot of discussion earlier this year around Andy Budd’s proposal for a CSS2.2. The basic premise was that the Web needs a halfway point between CSS2 and The Complete CSS3 that is taking forever, so that the key features web developers need now can happen sooner. The structure of CSS3 is actually set up so that this can happen, but the CSS Working Group has realized that this is far from obvious to anyone outside the working group. So we’ve decided to publish a CSS2.2.
Wow, I thought to myself, I can’t believe that the W3C are going to implement an interim specification. That’s fantastic news!
Unfortunately, despite the attention grabbing headline, Snapshot 2007 doesn’t appear to be anything approaching CSS2.2. What I was hoping for was a list of all the selectors, properties and values that the working group felt were stable and ready for implementation. That way, browser manufacturers could start implementing and testing new features, under the knowledge that they weren’t going to change. Similarly, us web developers could start playing with these features and baking them into our more avant guarde projects.
Unless I’m very much mistaken, Snapshot 2007 doesn’t do this. Instead, it’s more of a “State of the Union” address that gives a general indication of where CSS3 is, without supplying the necessary level of detail. While it’s nice to see the “introduction” and “table of contents”, what I want to see is CSS 2007: The Definitive Spec.
Hopefully that will be coming soon.
More About Deadlines | October 20, 2007
My deadlines post a few days ago seemed to spark a bit of a discussion, so I thought I’d write a quick follow-up. There were two main reasons why I wrote the original post. Firstly, I really dislike pronouncements from influential bloggers that are said as fact. Especially when the issues are a little more nuanced and require discussion. Secondly, I’ve always had a mild interest in Taosism, and get a little irritated by articles stating the Tao of “this-n-that” in a very prescriptive and un-taoist way. In fact, I think the latter was the main driving force behind the article.
From the tone of the previous paragraph, you could infer that I’ve “got issues” with Mr Rutledge. However I really like Andy and agree with the vast majority of his arguments. In fact I’m stoked that he’ll be attending SXSW for the first time this year, and look forward to sharing a pint and having a chat. My main criticisms are purely philosophical.
I believe that deadlines are an extremely important tool in any project. They help set expectations and provide a goal everybody can strive towards. In a perfect world no deadline would be missed and every project would be delivered on time. The waterfall style of project management attempts to replicate this perfect world by tightly controlling every step of the process. However experience shows us that projects morph over time and what was true at the start of a project, may not be true 6 months down the line. The rigidity of the “waterfall” process binds our hands and doesn’t provide the flexibility modern design projects need.
This is why agile and iterative models are gaining favour in our industry. Rather than having tightly scripted and immovable deadlines, each part of the process informs the next. Come up with a cool new feature or a better way to do something? Rather than leave this out to reach an arbitrary deadline, simply add an extra sprint. It may affect the project deadline, but the project will be better for it.
I thought I’d talk about a few, real world examples where deadlines work, and a few examples where missing deadlines has actually been a positive thing.
At Clearleft we used to spend ages working on the initial design concept, before showing it to our clients. However the time and effort we invested meant that we became very attached to the design and it proved more difficult to change tack. We realised that the majority of this time was spent obsessing over the details, so came up with the idea of a “one-day design concept”. This self imposed deadline allows us to focus on the heart of the concept without worrying about the details. It also creates a sense of urgency in which creativity can flourish.
The same is true of many other deadlines, from book reports to conference presentations. As the deadline nears, you being to refocus your attention away from less urgent issues and towards the task at hand. You may have known about the deadline for months, but the impending deadline provided you with a level of clarity that you wouldn’t have otherwise had. I’m sure we’ve all experienced that rush of creativity the night before a fixed deadline. As such, deadlines can be a powerful tool.
The problem is not to confuse the utility of a deadline with the deadline itself. Or to put it another way, rules are meant to be broken–just as long as the value in breaking the rule is significantly greater than the consequences. I’ll give you an example. We had a long meeting the other day, so in order to focus attention and avoid spinning off into irrelevant discussions, each section had a tightly controlled time limit. We stuck to these deadlines vigourously throughout the day, until we hit a particularly tricky discussion point. We could have stuck to the timetable and brushed the issue under the carpet. Instead we realised the importance of getting the issue resolved far outweighed the extra time that was required, so finished half an hour late.
You may be thinking that self imposed time deadlines are a lot different from project deadlines, but in most cases they’re not. They are just on a larger scale. We were working on a project recently and halfway through the wireframing process, we came up with a fantastically innovative idea. Implementing this idea required significantly reworking the wireframes, and creating visuals to explain the concept. The extra time meant we’d miss the wireframe deadline and push the project back a week. However the value in missing the deadline far outweighed the potential consequences, so we went ahead and made the changes.
Deadlines can be an extremely useful tool, but we need to remember that in most cases it’s the project that drives the deadlines, and not the deadlines driving the project.
The Real Tao of Deadlines | October 12, 2007
The beauty of Taoism is that it’s a very holistic belief system. Rather than setting down rules and doctrines, Taoism focuses on the natural order of the universe. Nature has it’s own pace, so rather than struggling against the flow, Taoism teaches us to move with it. After all, a young sapling will bend with the wind while the mighty oak gets torn from its roots. Sometimes nature is an unstoppable force and the only way to survive is to understand it’s core essence and be flexible. The same could be said of many a web design project.
In a recent article entitled The Tao of Deadlines, Andy Rutledge lectures that “A designer must never miss a deadline”. While I agree with the sentiment and many of the suggestions, I think the conclusion shows a lack of understanding about then essence of projects and also the Tao.
Sometimes client deadlines are fixed in stone and immovable. These are usually based around some fixed date like a product launch or trade show. However even in these cases, you often find that deadlines are a lot more malleable if quality is at stake. More often than not, client deadlines are a manifestation of a clients desire to see progress. The project may have been on the drawing board for months, and have been the source of numerous discussions and internal meetings. After six months discussion, everybody is so keen to see the project finished, they are only too keen to set a deadline.
Client deadlines are often based on a rough assumption on how long they think a project should take. However, as most clients aren’t experts in design management, there is a very strong chance of underestimating the complexities involved and hence the time it will take. In a desire to please their clients, many design firms will go along with this conceit in order to win work. Unfortunately these agencies end up doing themselves and their clients a huge disservice by over promising and under delivering.
However, even if you are conservative in your estimates, it’s extremely easy to miscalculate deadlines. At the start of a project there are almost limitless possibilities. The Taosists refer to this state of pure potential as P’u (樸). No matter how much documentation the client has written, or how much research and planning you do, you are always operating on limited information. In fact, rather than helping, documentation can hide potential problems and obsfucate matters. Furthermore, what information you do have is often very subjective and open to interpretation. Because of this, the designer will make a best guess estimate based on their feel for the job, the client and previous projects they have worked on. The problem is, all projects are different, and time estimates are more art than science.
As a project progresses, more information comes to light. Issues will rise up and clarifications will appear. The closer you get to the final solution, the more precise your estimates will become. It’s like looking at a block of marble and imagining the statute enclosed within. In fact, the literal translation of P’u is the “uncarved block”. It’s not until you start chipping away that the final form starts to emerge.
I enjoyed Andy’s article, but think he fails to take into account the fundamental Tao of deadlines. Deadlines can stimulate creativity and drive progress. However they can also hinder the quality, virtue or Te (德) of the project. Sometimes designers need more time to think about a problem, developers underestimate the complexity of an issue, or clients are late with sign-off. This has nothing to do with running a bad project or being unprofessional. It’s just the nature of the task. As such, deadlines represent both the dark (Yin) and light (Yang) sides of the hill. They are useful tools, but shouldn’t inhibit the virtue of the project you’re working on.
Setting immovable deadlines is a bit like throwing a boulder in a stream to stem the flow. Water will always find a way around such obstacles. To take a true Taoist approach, you need to see deadlines as guides rather than immutable objects, and be prepared to adapt to an ever changing environment. In short, you need to bend with the wind rather than risk being up-rooted. This is the Taoist spirit of Wu wei, and one we should all strive for.