M-C DEAN

Designer

I'm a product designer with a passion for user centered design. I am also an advocate of creative thinking approaches and design thinking.

I specialize in experience design for software. I've worked on lots of websites, web applications, mobile and social media products, applying principles and techniques from psychology and social sciences, human factors, human-computer interaction, visual design, accessibility and usability. My Ph.D focused on natural language generation and human communication with machines, a combination of AI and HCI.

I have a strong drive for innovation and have designed, envisioned and created new products for different market places and industries from scratch, as well as the strategy for bringing them to market and gaining user adoption. I bring the power and energy of design thinking to both startups and big companies. I like to focus my efforts on large-scale industry disruption.

I love to draw, take photos and skateboard. I'm a student and teacher of Yoga. I'm always exploring new things.

Creative briefs for developers

Creative Commons License photo credit: erix!

If you want your development team to be autonomous, rapid and creative, then you need to ensure that they have the room to move so that can occur. Often teams are given a very tight brief, which leads to the group of smart people you hired taking time to convince you on an alternative solution, or actually just not being in a mindset which drives innovation and excellence. You'll get good functional software for sure, but getting what you asked for isn't always a blessing. If you want the best solution for the problem that you are hiring them for, don't go into solution mode just yet. Articulate your problem to them in a creative brief, which will allow you to inspire the team, and get the most form them.

What Steve Jobs did very well:

Luke Williams  (in his book Disrupt) tells the story of when Steve Jobs came to Frog design to brief them on the work he wanted them to do on the (then called) personal computer. They were expecting a fat document full of restrictions and "must's" and "must not's". But Steve came empty handed and instead asked the team to "Give me Bob Dylan songs". Steve Job's genius was really in how he briefed teams. Giving enough context that they are on the right path, but expressing his need in a way that the teams could get a good sense of where his head was at with the work at hand.

Give a creative brief to the whole team, not just the designers:

Brilliant developers should be briefed in the very same way. I say "brilliant" because they are the ones that really benefit from creative briefs. If they are amazing technically, and that they positively become the code when they work, then you should trust these people to know what to do. If you don't have those kinds of people, you might be asking for trouble by leaving the brief open like that.

Really great thinkers will appreciate your open brief and will do awesome work for you. They are so good technically that they can work fast and produce high quality work. This does not mean that they should be treated like "code monkeys" with a designer in the mix to ensure that something creative results from the effort. You put the designer in a tough place with a lot of responsibility for the innovative and "fun" parts, and leave a very talented group of innovators to just build and not think creatively. Put the creative brief to the whole team, and you will get good results.

Pitch your idea to yourself first:

The creative brief forces you to listen to your idea yourself first. If you are struggling to write it out in a succinct and simple way, then you likely have more thinking to do before briefing a team to work on it. You can get help with this, there are a whole load of methods designed to get this out of you. Check out the book Thinkertoys for more information on these. If you have written your brief out and it doesn't inspire you or leaves you flat, then you;re also not ready to brief the team. Go and think some more until it's clear to you what exactly you are looking for the team to do. They don't need instructions or a checklist, they need a brief. They probably know more about technicalities and design and how to incorporate the two than you do, or you wouldn't need to hire them. Give them your great idea, your vision, or even your gut feeling.

The Brief:

You should put a brief together that you are comfortable with but it should be:

- Creative: resulting from originality of thought - Brief: short

Call it an "Idea sheet" or a "What I want" sheet...whatever you want to call it, and then decide on the best way to communicate your vision to your team. There are thousands of examples of creative briefs on the Internet, so a good scour might be in order, but this is the one I have used recently:

1 - Name your idea: (one idea per brief)

2 - Elevator pitch: (describe your idea)

"The_________________ is a __________________ For_____________________ who need ______________, that allows _________________unlike_____________.

3 - End users: (Say more about who it's for)

4 - Why they should care: (What is going to make end user want this solution)

5 - Why this solution will answer their needs: (make sure you are succinct here)

6 - Draw your idea out: (You don't have to draw well, but you should be able to represent it simply either with stick people or a quick diagram)

Your brief should spark enthusiasm, excitement, loud conversations, passionate disagreements and wonderfully happy teams. You will also be very happy because you will probably have at least a few  unexpected twists and a really awesome product. The most important thing for you to do is to trust them. Once you've hired them, you feel comfortable enough to let them make decisions and mistakes too. Innovative products usually come from a place of great heart, chaos and a few counts of failure. Let it happen quickly and you'll have a better result than you ever imagined possible.