disambiguity

WWAD? (What would Apple do?)

People say that it is some kind of Steve Jobs special sauce that makes Apple the company that it is, but as this Fortune article reveals, they reap rewards from using design techniques that we all have access to, and should *all* be doing. All the time.

These techniques include prototyping:

“One of the best pieces of advice Mickey ever gave us was to go rent a warehouse and build a prototype of a store, and not, you know, just design it, go build 20 of them, then discover it didn’t work,” says Jobs. In other words, design it as you would a product. Apple Store Version 0.0 took shape in a warehouse near the Apple campus. “Ron and I had a store all designed,” says Jobs, when they were stopped by an insight: The computer was evolving from a simple productivity tool to a “hub” for video, photography, music, information, and so forth. The sale, then, was less about the machine than what you could do with it.

But looking at their store, they winced. The hardware was laid out by product category - in other words, by how the company was organized internally, not by how a customer might actually want to buy things. “We were like, ‘Oh, God, we’re screwed!’” says Jobs.

But they weren’t screwed; they were in a mockup. “So we redesigned it,” he says. “And it cost us, I don’t know, six, nine months. But it was the right decision by a million miles.”

and User Research:

“When we launched retail, I got this group together, people from a variety of walks of life,” says Johnson. “As an icebreaker, we said, ‘Tell us about the best service experience you’ve ever had.’” Of the 18 people, 16 said it was in a hotel. This was unexpected. But of course: The concierge desk at a hotel isn’t selling anything; it’s there to help. “We said, ‘Well, how do we create a store that has the friendliness of a Four Seasons Hotel?’” The answer: “Let’s put a bar in our stores. But instead of dispensing alcohol, we dispense advice.”

OK. So maybe you don’t have budget to build a store twenty times over, but everyone has time and budget to do a paper prototype and show some people. Even if that’s all you can do, do it. 

Both of these techniques have been key in helping Apple make more dollars per square foot than stores like Saks or Tiffany - a pretty successful outcome by any measure, not to mention the way that the experience of the Apple store contributes to the over all Apple brand equity.

WWAD? Prototyping and user research. Go crazy.

Design Consequences: A fun workshop technique for brainstorming & consensus building

For my recent BarCamp session I shared a design technique that a colleague and I developed quite recently that we’ve found to be quite successful in both generating great design ideas and developing consensus about the design approach for projects within a multi-disciplinary team.

We call this technique Design Consequences, due to the similarity it has with the similarly named childrens games. We tend to use it in the earlier stages of the design process, although it can be used for more detailed interface design problems.

So, how does it work? It’s pretty simple really.

What you need:

1. a clearly articulated design problem and design goal(s) - for the BarCamp exercise our design problem was to design an electronic version of the BarCamp session wall where people could add their own session and choose which sessions they were going to attend. 
2. some design ideas or components - when I do this in a client context, we do this by spending time beforehand looking at our specific challenges and seeing how other people have approached them, and trying to understand design techniques or principles that work (as well as those that don’t). This gives people access to a much greater repoirtore of ideas to draw in the Design Consequences exercise.
3. a multi-disciplinary team - try to get the entire team if you can. The exercise works best with no more than 8 people involved, but it can be done with more if required. Get management to the table, bring all kinds of designers, bring the product managers and marketers, bring your developers. Bring everyone you can, as long as they’re familiar with the project and the design problem.
4. lots of paper and markers and post its - make them as colourful and fun as possible. Make it look like a crafting session. A sense of play and enjoyment is key to this exercise.
5. some examples of the type of output you’re expecting - anything that starts with the word ‘design’ can be very intimidating and scary. Lots of people ahve been told throughout their lives that they can’t draw, or that they aren’t creative. I have some *very* scratchy samples that have been created by people who design for a living. I show these before we get started so that people realise quickly that pretty drawings are not part of the equation.
6. A bundle of energy - you need to be just a little bit hyper to run this exercise

What you do:

1. Round One - everyone has seven minutes to design, individually, the the first page that users would see when confronting the ‘design problem’. So, a typical example would be a website homepage, but it could be any part of an application or website or even, say, an email. The faciliator(s) should participate, but keep an eye on the clock and give some warnings with a few minutes to go, and again at about 30 seconds.
2. Round Two - here’s the consequences twist. Everyone picks up the page they’ve designed, then passes it on to the person on their right (or left, it doesn’t really matter). Everyone then has to review the page they’ve received (ask for clarification from the original designer if it’s a little sketchy in places), then decide - if you were the user, what would *you* interact with, and what would happen next. You have seven minutes to draw ‘what happens next’. (Don’t tell people about Round Two before Round One, it’s much more fun when it’s a bit of a surprise).
3. Show and Tell - we then go around in a circle and each person describes the page they received, what aspect they chose to interact with and why, and then describes what they designed next. Discussion is encouraged.

What do you get? Lots of great data, and lots of great conversation fodder.

It’s a good idea to capture as much of this as possible as you go around the group. Of course, the best way to do this is to write up ideas onto post it notes as you go and stick them on the wall. There should be an ‘in’ section of the wall and an ‘out’ section of the wall. (’In’ means that the idea has legs for this particular design problem). Affinity sorting on the run also helps to draw out the key themes or ideas that have emerged from the exercise. You should be leading the group discussion, helping the group to gain consesus and make decisions as to the design approach to be taken in solving the design problem, and trying to document these decisions as you go.

This process can be quite time consuming and intense, but more often than not there will be a few key ideas that the group is particularly enthusiastic about and that really propels the decision making.

By the end of the session you should be in a position where everyone is in agreement about *what* will be included in the wireframes that comprise the next phase of the design process.

Why would you use this approach?

• It makes a great change from the talk-fest of meetings
• It generates lots of ideas - and often some really great ones 
• It stops people getting to attached to their design ideas and makes evaluation and critiquing more effective
• It helps get all the team feedback and ideas into the pot (in particular, it’s great to get management and technical input at this stage)
• It drives buy-in, involvement and consensus
• It pulls in cross-discipline scills (for example, developers are often really great at quickly identifying great ID approaches for Rich Internet Applications)
• You’d be amazed what you learn earlier rather than later by involving the entire team at this early stage
• Getting lots of brains involved in the design process can uncover some really creative gems
• It makes the design process faster
• It’s fun!

So, there you have it. Some quick notes on a technique that’s been quite useful for me lately. I’d be interested to hear what you think of it and if you try it, to see if you too find it useful.

What is this thing you call UCD?

Whenever arguments about User Centred Design (UCD) get started, in my experience, it’s due to a lack of definition. What is UCD? What do you actually need to *do* to be able to claim that you’ve used a UCD process or philosophy or methodology?

Good question.

I borrowed the diagram about from the Flow website. It’s not very pretty, but it does outline the general process that a UCD flavoured project will take.

Now… you don’t need to do every one of the activities listed here in order to be ‘UCD Compliant’, but you will need to take user input at each one of the points shown in this diagram - Research, Concept, Design, Implementation and Launch.

That is pretty much what defines a UCD project - it involves *real* people who are actual or potential users of your product, and it involves people at each of these points, allowing you to check and iterate your design at each stage of the project.

Let’s examine a few scenarios:

I do user centred design, I think about users all the time when I design.

This is not UCD. Thinking about users is very different to actually meeting them, talking to them, watching them interact with your product, or exist in the space for which your product is designed. UCD is more than just thinking about users.

I am a talented designer, and I know this domain. I don’t need to use a UCD process. I can make a good guess about what the right design is and then test that design, rather than doing all that research at the beginning.

This is frequently UCD in disguise. You see, you *can* re-use your research from project to project. If you are are designer who knows all about a particular client, or design problem, or subject area, or type of product this is very often because you’ve been through the UCD process to acquire that knowledge in the first place.

I don’t have time for all this UCD malarchy. It takes too long.

One of the great things about the UCD methodology is that it can ’squeeze to fit’. You don’t need to do all the exercises for each step. You can improvise each activity to fit the resources, time, budget that you have available for the project. UCD gurus including Jakob Nielsen and Deborah Mayhew both advocate getting as much as you can from each step, using the methods and means most appropriate to the project.

But, don’t throw out any of the steps. That way trouble lies.

All lifecycle tasks will always apply, but they can be expanded and contracted depending on the requirements, characteristics, and resources of a particular project.

Deborah Mayhew, The Usability Engineering Lifecycle.

So, when I’m talking about User Centred Design (and, in particular, asking for reasons why people might not choose to use it) … that’s what I’m talking about.

How’s that fit with your idea of UCD? About right? Any objections?

why bother calling if you call so late?

Don’t get me wrong… it’s not that I don’t want to work with you. I’d love nothing more to help make sure that your design is great and people love to use your product.

It’s just…  by the time you get to the part in your project plan that says ‘Usability Testing’, there’s not much I can do. You’ve left things too late.

Sure, I know. That’s when you do the usability testing, isn’t it? In that mad rush when you’re trying to get everything coded up and launched. I know, because it usually means that we don’t get much time to do the testing, and it’s usually not with the finished product.

And, you know… that probably would be ok, if we’d have done some testing earlier on in the piece.

OK, so you might not call it testing. You might call it research. Or you might just call it putting some ideas in front of people who might be using your product in the future and seeing what they think.

No, we don’t need your finished product before we can test. Not at all. We’ve tested with scraps of paper in the past and discovered we were heading down the wrong path altogether. We’ve learned a LOT about how our design should work even with some ugly wireframes.

And the great thing is that scraps of paper and wireframes cost nothing… compared to the amount you’ve invested in getting to the ‘Usability Testing’ line item on the project plan.

Compared to the amount you’ll probably have to spend if you want to implement any of the things we’ll probably learn if we do that testing now.

Of course… between you and I…. we know that’s probably not going to happen anyway, is it. There’s no time for changes. There’s a launch date fast approaching, and hardly enough time to finish the work you have already.

We’re just ticking a box here, aren’t we. With the best of intentions.

It’s a shame tho’. We could have been a good team.

We could have got to a kick butt design, one that we *knew* would work. We could have stopped all this coding and re-coding. We could have had good strong answers to questions that the business was asking. We could have taken so much of the guesswork out of it.

We could have been launching this thing with out the sneaking suspicion we’d be back at the drawing board (literally) in the very near future.

But I’ll tell you what I’ve found, and you tell me that you don’t have time to do anything about it.

And hopefully, next time, we can work together from the beginning.

I think that would be a much better idea.

Give me one good reason you can’t use User Centred Design in your project… Submissions Open!

I’m collecting reasons that you’ve heard or used as to why you can’t use a proper UCD (User Centred Design) methodology in your project.

Not just ‘yeah, I think about users when I’m doing the design’, but actually involving *real* users in your design process. Doing a proper UCD methodology.

How do you rationalise using UCD in your projects?

How have you heard other people rationalise it?

If you’re a UCD consultant, what reasons do you come up against and have to refute regularly?

Let me have ‘em.

Information Architecture is in the DNA of Design (On Evolving not Dying)

Rumours of the impending death of Information Architecture have been greatly exaggerated, but I think it is true that the Information Architect you were five years ago is very different to what you’ll be in five years time. (In fact, it’s probably very different already).

These rumours seem to have been kicked off by ‘important people in IA’ seemingly rejecting the IA community by moving onto other things - starting a new company, being interested in things that occur off the screen, finding themselves doing more Interaction Design than IA, or more strategic business thinking than sitemapping.

These are important symptoms, but they’re not fatal. It’s more about metamorphosis, adaptation, evolution. And that’s exciting (and just a little scary, sometimes).

As I see it, there are three important trends impacting on Information Architecture practice today - the content and categories we work with, our relationship with our ‘audience’, and our work practices.

Technological empowerment has meant that our audience are now active producers of content and rather than trying to ‘hide’ inactive content, our biggest challenge is often to manage the incoming surge of content in all it’s formats.

We’ve moved beyond just text and images - now audio and video are commonplace content formats for IAs to address.

The rise of search has meant that traditional site structures have become far less relevant to findability, and metadata (in its various forms) is more important than ever.

The semantic web is awakening and wondering what role we’ll play in it’s destiny.

Location, physical space, is becoming a key factor in understanding and defining content more and more often.

Our audiences are actively involved in IA, labelling, categorising, creating content.

Information Architecture is becoming more interactive and dynamic than ever before. Many of the more ’static’ tools are no longer as useful as they were before. New and different tools are being borrowed from different disciplines, evolved from older tools and methods.

Teams are becoming more cross skilled and agile. A ‘pure’ IA project is becoming rarer. IAs are becoming more involved in strategic decision making, but they’re also getting more involved in interaction design as Rich Internet Applications become more and more prevalent.

The diagram above shows the range of tasks and ‘practices’ that people who identify as practitioners of Information Architecture can and will often cross into. With the exception of Visual Design (which I stay well clear of due to accute lack of talent), I frequently use methods which range across all of the disciplines in this diagram. Similarly, tasks and methods have to be included within multiple disciplines.

Where do Personas and Scenarios live? You can’t exclude them from IA, ID or Research, which all use them frequently. Design does not reside only with Visual Design, but in almost all of these categories in one form or another. Although Research is a discipline of it’s own, most of these disciplines will use research in one way or another to achieve their outcomes/outputs.

Information Architecture is not dying. On the contrary, it is evolving and becoming more enriched as it becomes more inclusive of the various disciplines from which it’s practitioners originate.

Certainly in five years time there may be fewer people with the job title ‘Information Architect’ (and rightly so, if we’re doing more than that), but given the vastness of content that joins the web every day now, and the opportunities and challenges of the semantic web, the need for the skills and understanding of skilled practitioners of Information Architecture are more needed now than ever.

We’ll be very different IAs in a few years time, but I for one think we’ll have a more interesting, challenging and varied role to play, and personally, I can’t wait.

What about you?

Related reading on IA’s Recent Growing Pains

Adam Greenfield: IA or not IA (Don’t miss the comments on this one!)
Christina Wodtke: Why am I so angry?
Peter Merholtz: Tribeless
Joshua Porter: Thoughts on the Impending Death of IA
David Armano: Will IA go MIA?

pair design pays dividends

In agile development methodologies, pair programming is considered a key practice. Pair programming involves two programmers (in any combination of novice and/or expert) working together to write code. Advocates of agile methodologies outline a range of advantages of pair programming, and I’ve always thought that, in theory and as a relative outsider to the code writing process, it would be a great approach to development. I’ve never worked on a project where there was budget or resource available for pair programming though.

In the past 12 months or so, practitioners of the various design disciplines that I’m interested in have been talking more and more about agile methodologies and how they might apply to design processes. There’s been a lot of talk of collaborative design and rapid iteration, but I’ve not seen anyone talking much about ‘pair designing’.

In my experience, designing can often be a rather lonely activity. If you’re fortunate enough to be able to integrate real users into your design methodology then that can break it up a little. If you’re working within a team of other designers, perhaps you’ll be able to get them to review your work from time to time and give you some feedback. Working in a ‘pair design’ environment is, however, quite rare.

I’ve been fortunate enough to work on a few projects where we’ve taken a ‘pair design’ approach (in fact, I’m working on one right now), and I’ve been pleasantly surprised that the benefits that the agile advocates outline for pair programming largely hold true for pair design.

Using the list of benefits set out by Wikipedia, here’s a run down of what I’ve found.

• Increased discipline. Pairing partners are more likely to “do the right thing” and are less likely to take long breaks. Whilst I like to think that I ‘do the right thing’ when I’m designing solo, I have certainly found that working with another designer does heighten your focus on the task at hand and, even more importantly, lengthens the time that this level of focus can be maintained.I’ve also found that in pair design, you tend to design more away from the computer, instead using flip charts and pencil and paper, and post it notes stuck all over walls and drawings and user flows that you’ve mapped out on paper.This is good design practice but, even better, keeps you away from the distraction of email, and bloglines, and all the other kinds of distractions that you find on your computer. It keeps you focussed on the design process.This makes you design better, and makes you more efficient.

• Better code. Pairing partners are less likely to go down ratholes and tend to come up with higher quality designs. I don’t know about ratholes… But I do know that when designing in pairs there tends to be a more rigorous approach taken to design decisions. This is because you have to be able to explain each decision you’re making, or design approach you’re taking AS you make it, not in retrospect. Each decision needs to be justifiable. And, because you have someone there designing with you, you get to actually discuss the benefits of each approach rather than just doing what you think is best (or worse… what you can do most easily in Visio because you have a template already set up that way…. Oh, come on. You know you’ve done it.)On the ‘going down ratholes’ issue though, if you happen to be designing with your client, then you are able to check really quickly whether the approach you’re taking has a hope in hell of being adopted by the client. This means that you don’t waste time designing something that will never be implemented, and that what you do design has a much better chance of adoption.On that note - designing with your client means that they understand the rationale behind every design decision. So, if you’re just a temporary resource on the project, you leave behind an evangelist for your design - again, making it more likely that what you’ve designed will actually survive the development phase.
• Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working. For me, getting stuck into designing IS flow. But see above re: increased discipline and below re: less interruption. Both of those definitely mean you get lots more flow time, which is all good.

• Improved morale. Pair programming can be more enjoyable for some engineers than programming alone.As I mentioned before, designing solo can be a lonely business. When you crack a really curly design problem, there’s no one to celebrate with… well, no one who really gets it. With pair design, you have a celebration partner. This is good

• Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire codebase.OK. This has been a little less relevant to me, as a consultant, but see above re: designing with your client and gaining and evangelist.

• Mentoring. Everyone, even junior programmers, possess knowledge that others don’t. Pair programming is a painless way of spreading that knowledge. This is almost certainly true when you have an expert/novice pairing, but even when you have two designers with similar experience there is a lot to be learned.How often do you get to actually watch the process that other designers go through and how they approach their work? Not often, I’d guess. This is a great opportunity to say, ’so hey, here’s how I do it… how would you do this?’ and pick up some handy new ideas or approaches or Visio tricks. (Hey, none of us know everything, do we!)

• Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling. Yep. Pair designing is definitely a great icebreaker

• Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.Now, this one is DEFINITELY true, and don’t underestimate how important this is. You can get an awful lot of design done in a couple of hours if that’s ALL that you’re doing. But how often do you actually get this much time to do nothing but the design you’re working on? In my case, not that often. Two people in a room makes you MUCH less interruptable!

• One fewer workstation required. Since two people use one workstation, one fewer workstation is required, and therefore the extra workstation can be used for other purposes. Well, in our case we abandoned workstations all together and took over a small office/war room. So, I guess there have been a couple of free workstations!

Choosing the right co-designer is pretty important. I’d be loathe to pair design with someone who knew nothing about interaction design… it would be way too much mentoring and not enough designing, which isn’t practical or appropriate on a ‘project’ based design. i would however suggest that if you find a client who has people with the right skills, you do what you can to try to get them involved. This is much more likely if you’re applying other agile methods that involve rapid designing and iterating.Now, it would be unrealistic to suggest that pair design be adopted for all design projects, it’s never going to happen, and in many situations would be unnecessary.

But, if you do have the chance to work this kind of methodology into your project, then I’d encourage you to go for it. I think you’ll find it a very rewarding experience.

Have you experienced pair design? I’d be really interested to hear if you’ve had similarly good experiences, or if there are some horror stories out there!

Where’s the Gantt gone?

Having been a project manager in a past life, and still working day to day on projects, I watch with interest the deployment of a range of web based project management tools. In a lot of ways it’s like a dream come true. For most of us, Microsoft Project - the only real project management tool available beforehand - is possibly the most over featured piece of software in the world.

I’ve heard it said that most people only use about 5% of Microsoft Word’s functionality… I can’t imagine what a miniscule proportion of functionality most people use in Microsoft Project. And like MS Word but worse, often times that unused functionality would rear up and cause problems for users who didn’t understand it or weren’t aware of it.

Not only that, but it’s also prohibitively expensive. So unless you’re working in a company where they’ve got the finance and inclination to pay for your license fee - you’re unlikely to get access to it.

Then along comes 37 Signals with Basecamp, BackPack and TaDa Lists . Project managers everywhere were ecstatic (not to mention all those David Allen Getting Things Done disciples). With the ability to create and assign tasks, to post messages, to do simple scheduling and starting at the bargain price of free - 37 Signals and their products soon had a lot of evangelists wondering aloud how they ever managed without these web based project management tools.

Just last night I got my invitation to check out GoPlan. It’s been developed by the team at WeBreakStuff, so I had pretty high expectations. These guys think a lot about usability and user experience, so their work should be top notch. And, I have to say, I wasn’t disappointed.

GoPlan is a spunky looking piece of web application, and it has lots of great functionality.

You can create multiple projects with multiple users (users with varied permission to access content and functionality), there’s notes, a project blog, a calendar, a file upload.

GoPlan also has two similar but different sections called Tasks and Tickets. Tasks, I assume, are things you have to do in the course of the project. You can assign it to a category but not a person, and you can assign a deadline to it (although, strangely that doesn’t make it show up in the calendar). Tickets, I assume, are for bugs and variations. You can assign a priority, a severity (is it just me, or are these two *very* similar criteria… when is a critical severity ever a low priority? I guess there are exceptions… nevermind, tangent).

Oh, and there’s a cool inbuilt ‘chat’ so you can have your rapid fire online discussions AND keep a record of what you actually decided!

All good. All a lot like the 37 Signals offering. But all slightly disappointing to someone who’s managed some reasonably complex projects in her time.

I never thought I’d say it, but I miss the Gantt Chart.

I think it’s quite interesting that both 37 Signals and WeBreakStuff have not used any visualisation tools as a part of their project management offerings. (Well, ok GoPlan has a calendar… do we count that? I might if their task deadlines integrated with the calendar, so for now.. no).

One of the most recognisable features of Microsoft Project is the Gantt chart it generates. Back when I used to make lots of big MS Project files, I thought that I was really just making those charts for my clients (they’re pretty, they look seriously impressive - wow! that’s one complicated project!… this was before Getting Real, ok!)

Interestingly, if you take a look at 37 Sig’s Manifesto for BaseCamp, this is one of the first things you’ll read:

Projects don’t fail from of a lack of charts, graphs, reports, or statistics, they fail from a lack of communication.

Ah yes. But what I’ve come to notice is that charts, graphs, reports and statistics do more than just impress clients. And they can play an important role in communication, and motivation.

What is a Gantt Chart? Well, GanttChart.com (yeah, who knew!) says:

A Gantt chart is a graphical representation of the duration of tasks against the progression of time.

You can see why that might come in handy.

At a simplistic level - nothing focusses attention like a Gantt Chart with lots of red on it - indicating that you’re way behind schedule.

On a more practical level - when constructing project plans, I’ve come to realise how much I did actually rely on the Gantt Chart to help eliminate errors in my scheduling, and to quickly see the implications of alternate scheduling, risks and delays.

When reviewing a complex project plan to see if I’d made errors in scheduling, or understanding project relationships, or if I’d just missed lots of stuff out - it was the Gantt Chart that would most quickly let me know if I’d stuffed up. Breaks in the flow, a critical path that just stops (before the end of the project), tasks that just look too long or too short compared to the tasks around them - all rapid visual indicators that something’s not right.

It get’s really hard and boring to read through a long list of tasks, and even more difficult to understand the relationships between tasks in this format. This is where the Gantt Chart comes into it’s own. Relationships between tasks and groups of tasks are immediately apparent. Tasks that are on the critical path are obvious.

In retrospect, I’d have to say that Gantt Charts were really important in eliminating errors in project planning for me, back in the day.

So, the Gantt Chart is much more than just client eye candy. It also plays a real role in faciliating the detailed planning phase of the project. It also helps with rapid comprehension of project progress and task relationships as the project continues.

Gantt Charts allow you to understand how long your project is going to take, in what order tasks need to be undertaken (no, it’s not always self evident!), and what tasks are dependent on other tasks. This means that if you move tasks around, or some tasks get delayed, you can see what’s going to happen to your project as a result.

This is all really handy stuff to know if you’re managing a team and have a deadline. It helps you communicate within the team, and to your client, early and accurately. It helps everyone make decisions.

In both the 37 Signals products as in GoPlan, there seems to be no notion of a critical path, or dependencies between tasks. To me, that means that I either have to work a lot harder to keep my projects under control or to impose a structure of my own, or that these products are only intended for reasonably simple projects where, perhaps, the deadline is not such a big deal.

I’ve been using BackPack and BaseCamp for almost as long as they’ve been available, and I have to say that they’ve certainly been valuable to me. Particularly when I was freelancing and had to manage my own tasks on several projects. In these cases though, when I was working on big projects, I was a resource (information architect) and someone else was a project manager who had the biggest Gantt Chart you’ve ever seen in your life! (I needed a separate tool just to manage my tasks!)

I find it intriguing that both 37 Sigs and GoPlan seem to have taken such an anti-chart approach to their tools (and there’s much more than just the Gantt chart that they could have included). I suspect it’s to do with the lack of the critical path. Or perhaps, they’re not actually *project* management tools, but ’sets of tasks’ tools.

Either way - if any one’s planning a web based PM tool that *does* include a critical path and some pretty pictures… I’d really love to see it!

What about you? Do you miss the Gantt chart? or are Critical Paths soooo 1.0?
Technorati Tags: 37+Signals, BackPack, BaseCamp, GoPlan, WeBreakStuff

Moo Flickr Mini Cards + Getting Real

It’s been really great working with the guys at Moo because of the responsiveness and user centric approach that they’ve taken to this project. I look forward to seeing how this product evolves and where else Moo shows up - they’re a really smart crew, doing really smart work! Yay Moo!

innovation - give it ten years (girly geeks london)

So, I went to the Girl Geeks Dinner in London last evening. It was an interesting night. The first thing you need to know if you’re thinking of going, is that it’s not a dinner. It’s drinks and a talk. But it’s still good.

I went there knowing absolutely no one, and ended up meeting a few people (hooray to those girls who were brave enough to introduce themselves to people they’ve never met… this happened about three times throughout the night, I did it a few times but not as bravely as some!)

One thing I’m taking away from the evening is that I need to find a way to talk about what I do that sounds as exciting as I think it is. As you do when you don’t know anyone, you find yourself explaining what you do with your time at work. You’d know by now that I’m pretty enthusiastic about my work - but I know that when I talk about it, it doesn’t have that zing. That’s something to work on.

Someone who does much better at it is Abigail Sellen. She’s been involved in amazing HCI work for ages. At the moment, she’s working with Microsoft. Abigail gave a really interesting talk to the Geeky Girls. I loved her relaxed presentation style. Abigail has been doing this work and talking about it a lot. She has such an understated approach, but her CV is so incredibly sexy, I suppose it’s easy to be understated.

Abigail says - if you’re going to *really* innovate - really do something out of the square - then be prepared for a ten year wait to see it go to market- otherwise be prepared to engage in taking it to market (getting out of the research lab and going out for lunch with product managers, engaging with the economics and the politics of the organisation outside of the research lab). She was talking about projects they were working on ten years ago that we’re looking at today and thinking ‘how sexy’. Seen that two handed desktop interaction? That kind of thing. They were working on it ten years ago and now the market is almost ready to find a place for it.

If you want to take innovation to market quickly, then focus on tweaks. Find ways to make existing technology work better. And this is no small task. Abigail gave the example of the mobile phone and the way that SMS completely revolutionised what that device meant to people and how they used it. That’s a reasonably small innovation that came to market reasonably quickly (depending on what market you’re in) and made huge changes.

At Microsoft they’ve been looking at the home technology market. Their thinking is that up until now, home technology has been divided into two areas: time saving and time wasting. This is a pretty simple breakdown, they say, and there must be some more interesting opportunities for technology in this environment - like for using it to allow people to express themselves, to emote, and for supporting families.

Really interesting stuff - enough to turn some of us green with jealousy, I’m sure. Sometimes I really like the idea of working in a research lab. But then, they too have frustrations - such as the ten year wait, and the products that are designed but never get to market, and getting IP Patents for all your ideas can’t be that much fun either.

It was definitely worth the effort to make it to Geek Girls and I’d recommend it to other London gals. Get along and check it out!

Meanwhile - check out Sarah Blow’s great t-shirt (picture above). It’s a customised XXL Mans Microsoft .NET tshirt. Microsoft has never looked so cool. Mash-up of the year I reckon

Technorati Tags: LGGD7

Check out a non-crunchy version of the photo here.