The Anatomy of a Creative Brief…

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

equine anatomy illustration
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

crayons

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!

Developing a Mozilla Code of Conduct

Mozilla is going to explore developing a Code of Conduct for our community and contributors, using the Ubuntu project Code of Conduct and supporting documents as an initial template. We’re looking to create something aspirational rather than proscriptive, and the Ubuntu documents provide a tried and proven starting point.

The next step is to look at those documents and see what we need to do to adapt them to work for the Mozilla project. For this, I need your help.

I’ve started a thread over in the mozilla.governance newsgroup to get the process started. It includes a link to a rough first draft of a Code and an explanation of where that draft came from.

Please note that all discussion related to the development of a Code of Conduct should happen in that thread/newsgroup. If you post comments here, I’ll just ask you to move ’em over there 🙂

Please, please try to make time to participate if you can. This is a big and very important step for the Mozilla project and our community.

Thanks!

Last call! Feature page survey!

If you have ever used one of the Feature Pages or Feature Lists on the Mozilla Wiki, please help us improve the system by participating in our Feature Page Survey.

We’re going to close the survey down TOMORROW, and we need to get as many responses as we can. The survey should only take 5-8 minutes to fill out, and we’d really appreciate all the feedback we can get.

>>> Feature Page Survey < <<

Thanks!

Mozillians, please help: Feature Page Survey!

If you have ever used one of the Feature Pages or Feature Lists on the Mozilla Wiki, please help us improve the system by participating in our Feature Page Survey.

We’re going to close the survey down at the end of January, and we need to get as many responses as we can. The survey should only take 5-8 minutes to fill out, and we’d really appreciate all the feedback we can get.

>>> Feature Page Survey <<<

Thanks!

About rants: cathartic but generally destructive

Before you post a rant about something going on in the Mozilla project, take a moment to put yourself in the other person’s shoes — getting blindsided by a bunch of criticism on a widely-read forum when no one had previously asked you about it or tried talking to you is never, ever fun.

Posting a rant is also a pretty crap way to get your point across, because:

a) It’s hurtful and humiliating to the person being criticised
b) It immediately puts the other person on the defensive
c) It brings the situation to the direct attention of a larger number of people, which makes the other person feel even worse if they do turn out to be wrong
d) It often doesn’t accomplish a lot other than bring some widespread drama to a situation that probably could have been resolved in a much more sensible way

Mozillians are almost invariably smart, capable people who care deeply about what they’re doing and are always genuinely trying to do the right thing. Always start from that premise, give them the benefit of the doubt, and just talk to them if there’s a problem.