I’m in the midst of our first sprint on the ‘publishing tools’ project at the Economist, wherein we’re defining interface designs for the ongoing migration of economist.com over to Drupal 6. hurrah!
There is no sprint zero in this project and no time to consider the overall environment design, we’re going to be approaching this incrementally throughout the project, so instead we’re ploughing headlong into proper interface design, and the first few sprints are dedicated to designing publishing tools to allow a group of editors to update what are known as the Channel Index Pages (experimental versions can be seen on economist.com now here and here for example). They’re not much to look at just yet but designers in the New York office are hard at work wireframing and designing up much richer and more exciting!
So, Sprint One dives straight into research and interaction design, I work three days a week on the one week sprints and the format we’re using goes a little like this:
Day One: Research
This week I spent the day talking to Channel Index Editors (who update the website pages) and Section Editors (who edit the print version of The Economist). The interviews were a mixture of me getting to know who is who and what they do, understanding the way The Economist as an organisation works, the publishing processes, perceptions and concerns re: web vs print content production and quality, and getting walkthroughs of some of the current software in use for both web and print production.
There’s no time in the schedule for formal research analysis so it ends up as a page of scribbled notes at the end of the day that, as it turns out, is already serving as a really useful reference point. Some of the scribbled bullet points included:
- the channel index admin interface is working pretty well at the moment no critical usability issues
- however, one of the key tasks on this page (news package creation, where the editors group together related content) is currently a very ‘human’ task, relying a lot of the memory of the individual editors and a little on Google searches – there is an opportunity to support this task
- the biggest usability issues are around the content creation tasks which uses the infamous ‘tree’ system and wastes vast quantities of editorial time due to it’s inefficiencies – improving this interface as we port the system to Drupal will free up significant time for journalists and editors to do what they do best and what they really want to do. As one participant so poignantly shared: ‘what I want to be doing is spending my time writing and at the moment I spend half my time writing and the rest of my time fighting the content management system’
- people are using the print publication software (known as CCI) for much of the web production process to take advantage of its visible workflow/approval infrastructure (which is basically all about getting the right sets of initials on your content) – we need to find a way to support this process in the Drupal system
- unlike many CMS implementations I’ve worked on, workflow is not really a ‘top down’ imposition but actually considered desirable – writers *want* people further up the editorial food chain to review their work and for this review to be evident. is this significant for the way we design workflow/reviews?
Day Two: Planning, Designing & More Research
My second day on this sprint kicked off with a Scrum Sprint Planning Meeting – much standing up, reviewing backlog, breaking down stories into tasks and guessing hours.
It’s always a kind of tricky process for design work (and probably for other kinds of work too) because the tasks seem to be so mixed up and messy in a lot of cases – what I say I’m going to do (theoretically) and the way they actually happen aren’t necessarily the same – but it seems to work pretty well here, mostly because the team are pretty flexible and very interested in making design work in a Scrum environment.
Then it was onto some design work – lots of sketching, some prototype building, rinse & repeat until I had to head out for another user research interview.
Day Three: Design, and setting up next week’s research
Day three was all about building my ‘demos’ for next week – demos are a requirement for the Scrum methodology and we have to have something to show at the ‘demo’ session each week and, of course, they’re also what I’ll use in my next round of research, which is day one of the next sprint and which I set up with a few of the people I’d met earlier in the week.
At the moment I’m building my prototypes in Omnigraffle – mostly because I’m using a mix of wireframes and screengrabs and it’s the fastest, easiest way I’ve found to do it – and then just throwing it into ‘presentation’ view makes a great format for use in user research sessions.
One of the big issues I’ve been dealing with this week has been the environment for the content management to take place. The project team I’ve come into have a strong preference for ‘in place’ editing, and I’ve been pretty cautious about taking this approach because it can be difficult to manage complex editing tasks in this environment and because there’s been no indication from user research that it is necessary or beneficial.
At the end of day three I’ve got two prototypes ready for Monday – one is a traditional ‘Admin System’ interface with some simple ‘in place’ editing on Preview and the other is almost entirely ‘in place’ editing. We’ll see how they go in testing on Monday and what we see there will guide the decision making going forward.
Unlike the D7UX project, the technical team here are not at all daunted by the prospect of trying to make Drupal do some pretty serious in-place editing (it’s a different story of course when you don’t have to worry about Core!). Time will tell whether they’re just an overly optimistic bunch or not :)
And now, to the weekend! :)