The Anatomy of a Creative Brief…

…or at least the creative brief we’re going to use.

Image from Crossett Library Bennington College

As I mentioned in my previous post, the Firefox for Android UX & Product folk are embarking on a new experiment towards streamlining how we define and design new features.

One of the new things we’re doing is collaboratively developing a “creative brief” which the UX team can then use for focused brainstorming and exploration. Ian Barlow — Firefox for Android’s exceedingly awesome UX lead — and I put together the following framework for this.

Overview & goals
A few sentences (as few as one) that outline the overarching goals and purpose of this project/feature.

• What is this feature/project?
• What are we hoping to accomplish?

Non-goals
This section is technically optional, but it’s often useful to think about and explicitly state what you’re not trying to do.

• The flipside — what is this feature/project not?
• What specific aspects are we not interested in exploring or expanding into?

Who is this for?
Defining our target audience.

• Who is this for?
• What specific demographics/groups/sorts of people are we trying to help?
• Which of the Firefox “user types” are included?

Why are we doing this?
What triggers lead to this initiative? This could be one or any combination of the following, and more.

• User feedback
• User research
• Demonstrated/observed user problems
• Technology opportunities
• Market drivers
• Other specific problems that need to be solved
• Partnership opportunities
• Competitive analyses
• etc.

Inspiration
What elements could/should we use as inspiration when we start thinking/brainstorming about this project? The “inspiration board” for the project.

• What examples of this idea/feature already exist?
• What design elements from elsewhere do we think could be interesting and useful?
• Any other inspirational images, links, articles, etc.

User research
Any background studies we have done or can find about our target users.

• Links to any relevant user studies we’ve done ourselves either directly or peripherally related to this feature, project, or users.
• “Literature review” results — external articles, studies, etc. that we believe would be helpful when working on this feature/project.

User stories & use cases
These are not intended to be final user stories for this project, but rather a handful of stories and use cases that provide a starting point and further inspiration & understanding about how the Product team is thinking about this project/feature.

Criteria for success
What do our victory conditions look like? How will we know we have succeeded? What metrics do we think we’ll use to make these victory conditions measurable and concrete?

And that’s about that. We’re in the process of fleshing out the creative brief for our first project experiment, and when we have that in a more complete state, I’ll post about it here.

As always, questions & feedback are welcome, and you can always find the Firefox for Android team hanging out in the #mobile IRC channel.

Working with UX: an experiment in process

Photo by: Matt Doucett

The Firefox for Android team is embarking on a new experiment towards improving our already-pretty-great integration of UX design & innovation into our product development process.

We’re doing this by introducing a couple of new & slightly more formal steps to the beginning of our feature definition process:

1. Brief: collaboratively develop a creative brief (Product & UX)
2. Brainstorm: create and flesh out a couple of design concepts (UX)
3. Refine: expand upon & fine-tune those design concepts (UX & Product)
4. Pitch: present those concepts to the team as a whole to see which concept (or parts of the concepts) we want to explore further (UX & Product)

At this point, we’re back into our regular feature definition & development process, where Product, UX, and Engineering work together to flesh out, iterate on, and build the selected design concepts.

We’re doing this experiment for a couple of reasons.

First, it will simplify and clarify the interaction between Product and UX — UX will always have a solid idea of what Product is looking for in terms of feature innovation and design work, and it will make it easier for Product to clearly provide that direction.

Second, it will make our feature pipeline more efficient — using this expanded process, we believe that we’ll be able to have more features ready for engineering more quickly, so there will always be a healthy and curated backlog of new and interesting projects that both paid and volunteer contributors can pick up and start hacking on.

For now, we’re going start with this experiment with one longer-term feature (exploring the idea of a kid-friendly “flavour” of Firefox for Android), and a few smaller more focused features (TBD). We’re all pretty excited about trying something new around this, and we’ll be blogging our progress and results so you can all follow along.

As always, you can find the Firefox for Android team in the #mobile IRC channel if you have any questions or just want to chat & hang out.

Next post: What our creative brief is going to look like!

Open source projects & the tools that make them go

I’ve been actively involved in open source projects since around 1997, and as part of Mozilla since 2005. During that time I’ve noticed that successful projects usually make do with a short list of relatively simple tools. These are:

1. A version control & source code management system
2. A bug tracker
3. A mailing list (for asynchronous discussion)
4. An IRC channel (for synchronous discussion)
5. A wiki (for documentation, designs, meeting notes, and so on)
6. An etherpad install (for collaborative note taking & a host of other things)

That’s really it. There are more elaborate tools, and there are more elaborate processes that can be built around them, but I have seen it proven time and again that if you have these tools and a good group of smart and dedicated people, you can literally change the world.

(Photo by OZinOH.)

Testing, because it’s been a while

I haven’t posted anything to any of my non-tumblr blogs since March 2012. That’s really silly. Now I have a thing I want to blog, but I need to update my feed on ye olde Planet.  This is a post that will let me use a new tag that will let me create a new feed, since I don’t want my old work posts to accidentally get spammed all over Planet, confusing everyone.

So here we are.