I have attended the Thinking Digital conference 2013 in Gateshead for the first time this year, having read a review comparing it to TED. And all in all, I think it lived up to my expectations. One participant I met even told me that he preferred it over SXSW!

There were around 30 speakers packed into two days. I’d say 80% were absolutely fantastic – that’s a pretty good hit rate.

Here are some ideas I found particularly interesting. I won’t go into too much detail but have provided links for you to explore. I heard that the videos will become available in about 6 months time. Or you can watch the past talks on their site.

Be collaborative, be creative, be agile

This may sound a bit self-congratulatory, but I found that we’re already implementing most of the ‘best working practices’ that the speakers were advocating. It was mainly about being collaborative, being creative and being agile.

The very first speaker Eddie Obeng kick-started the conference with an energy packed talk (wearing a very bright green shirt) that stressed the importance of working collaboratively.

Maria Giudice talked about being a DEO (Design Executive Officer). Aral Balkan talked about the need to put creative and user centred design thinking at the heart of business, showing many entertaining bad/evil user experience examples from the world around us – I was practically crying with laughter.

“Perfection is achieved not when there is nothing more to add, but there is nothing left to take away” Antoine De Saint-Exupery (introduced during Aral Balkan’s very entertaining talk).

Mike Bracken showed how his team changed the government’s perception of the web by using a more agile approach to their Gov.uk project. I was already impressed by their design principles and how they have actually managed to do it given that it IS a government project after all. Imagine the bureaucracy! During the talk, he shared a chart showing all government transactional services, and told us that they were understandably bringing the most popular services online first. The chart had a very, very long tail – the one at the end was ‘To obtain permission to scatter ashes at sea’ – so you know when that becomes available online, they’ve done it all!

There were many other speakers that touched on similar points. As I work in a company that works very collaboratively, creatively and in agile, it was great to hear that we’re on the right track. And we’re finding that it works for us.

Inspiring next generations

Many speakers talked about how they wanted to inspire their kids and the next generations of technologists. And it struck a chord (or code) with me, as a mother and an auntie.

TeenTech was introduced by the one and only Maggie Philbin, (what would be the modern equivalent of Tomorrow’s World?) bringing teenagers and experienced developers together to make something happen. Let’s get them excited!

Sugata Mitra‘s Minimally Invasive Education (MIE) was also very inspiring. It is basically about creating a self-organised learning environment without teachers present (but you need grannies and a teacher posing the right questions). A group of kids are given one computer (with internet connection) to share, and a question to answer together. Say if you want to teach them ‘cell differentiation’, the question will be ‘why can’t women grow beards?’. A teacher is still very important as you’ll need a right sort of questions. And a granny is important to give the kids some encouragement and positive feedback to keep them going. It is amazing to see how effective these approaches are.

There were two teachers, Jo Fothergill & Tara Taylor-Jorgensen from New Zealand, who talked about how they successfully used MIE to teach their pupils. Sugata himself is also setting up 7 schools (5 in India, 1 in Gateshead, 1 in Durham) to implement the approach. It will be interesting to see how they get on.

In a different talk, Julian Treasure was raising awareness of noise pollution. He said it was a serious problem, second only to air pollution, but no one was doing much about it. In a typical modern classroom, pupils that sit at the back of the room only catch 50% of what their teacher says because of bad acoustics. He also pointed out that playing music while you are studying definitely reduces efficiency as music are inherently created to be listened to, despite what teenagers claim!

Things are happening up North!

There were a few reminders that the North East has become the second largest tech industry after London. And that it’s being happening largely under the radar. There is a good reason that the conference was taking place in Gateshead! I will definitely keep an eye on developments up there.

And…?

Above are just a few ideas I found particularly interesting. There were loads more thoughts discussed that were nothing short of amazing.

If there was any thread going through entire conference, it was probably humility. Think about users. Think about people. Think about emotion. Considering the name of the conference was ‘Thinking Digital’, it was very interesting that it was as much about ‘Analogue’ as ‘Digital’, as one of the speakers said.

And I can’t wait for next year. I’ll definitely be there.

How can we attract talented graduate designers? Can we be a serious contender in the design industry?

The traditional (or conventional) wisdom says the best place for graduates to learn their trades is at successful creative agencies or consultancies. But is it possible for tech start-ups to nurture design talent too?

I took a (very subjective and personal) look at pros and cons of options from a graduate’s point of view to see if joining the start-ups can be a viable option for them.

Pros and cons of established medium to large design agency or consultancy

Pros:

• There are many peers you can learn from – a team or teams of designers who compete and inspire each other (in theory, at least)

• There is a variety of work going on, giving you wider insight.

• Higher possibility of doing projects for large, well-known brands

• Longer term projects allow you deeper understanding of brands

• Design is at the heart of the company

• Large alumni network can help you in the future. Or add some kudos in your CV.

Cons:

• Smaller part / say / influence in a project (you will probably have to be very assertive to be noticed) to begin with

• Pay is often linked to a job title – okay for the first few years but it will become increasingly painful as you reach senior positions

• More office politics (just because there are more people…)

• Tendency to design for the peers and awards

• Less disruptive in general

Other characteristics:

• Many processes and templates to follow

• The projects tend to be longer

Pros and cons of tech start-ups for designers

Pros:

• Greater responsibility, influence and contribution as there are generally less people

• Early exposure to clients

• Get to see the end results quickly

• Multi disciplinary team environment for insights and inspiration

• Emphasis on great user experience

• Likes to be disruptive

Cons:

• As it tends to be small you have less peers to learn from. The worst case scenario is you could just get thrown into the deep end without any support.

• The projects tend to be for smaller clients. (Having said that, more and more large enterprise are seeking out start-ups for innovative solution as you can see from our client list)

• The projects tend to be shorter with less time for crafting design

• Less emphasis on design

Other characteristics:

• It’s usually small

• The projects tend to be shorter 

So, what can tech start-ups do?

1. Invest on support

You will need good senior designers who are willing to help others to begin with. If you do, then the small setting is actually a positive thing as graduates can get more personal, hands on attention.

Make sure training is provided and appropriate tools are available. There might not be many peers inside the company, but there are millions out there in some form of on- and offline communities. Join up.

2. Promote user experience

While visual design might not be at the heart of the company, the user experience should definitely be, alongside technology.

Visual design (including branding) is basically the physical manifestation of user experience. It can’t be ignored. Even if the technology works well, if it fails to communicate and be usable, no one will use it or identify with it. It’s not just about making things look pretty. It’s vital that you get the design right.

You also need to understand that design is something constantly evolving and improving. Let’s try not to call that jpeg “FINAL”…!*

*Dear graduate readers: You will soon encounter a filename that ends with “FINAL FINAL FINAL” or “NEW NEW NEW” when you start working. Someone has obviously been very optimistic.

3. Be disruptive and cutting edge (and fun)

This is the biggest advantage start-ups have over bigger, more established firms. You are more agile and flexible, and you can be more disruptive.

Any designers can make difference, create something new from day one. Surely that is very motivating.

4. Inspire

Working within a multidisciplinary team can inspire designers in a different way from a team of designers. It is not about designs for designs sake. It’s the art of looking sideways in a sense.

In the bigger firms, especially those that operate with a waterfall methodology, sometimes you don’t even get a single opportunity to talk to a developer during a project.

Start-ups should create an environment that encourages all the team members to communicate – if you are running in agile that incorporates UX and design properly (If you’re interested in how to do this, here is my previous blog: Agile Survival Guide for Designers), then that should happen naturally.

Are you a graduate?

There is a lot happening with design in tech start-ups right now. It feels a lot like 1960s was for graphic design. There are opportunities to innovate and experiment. While I agree that there are loads you can learn from being surrounded by designers, surrounded by developers and other disciplines enables you to achieve something equally exciting, and potentially new and groundbreaking.

Maybe you need a bit of entrepreneurial spirit and drive to improve. And a love of creating something you can be proud of. It’s more about what you create and do, rather than what other people think you do.

I am not saying all the tech start-ups are great place for a budding designer. But as long as they hit the four points I listed above, I think they can be a great place to be. Maybe more than what the traditional wisdom says. If you are a graduate / budding designer and interested in working with us, please give us a shout at hello@red-badger.com.

(If you’re interested in seeing the Lego plant pot being made, here is the stop motion animation I made while building it. And it’s inspired by Being Geek Chic blog.)

Are you a designer about to work in agile teams? Or are you a scrum master and don’t know how to handle your ever so grumpy creatives?

Red Badger works with agile methodology and I really like the way we work here. Surprised to hear a designer liking an agile team? I would like to share some tips that designers and scrum masters can follow to make designer’s life in agile somewhat enjoyable.

Things are getting better

My favourite horror story was along the line of “I turned up on a new project and they asked me to design up a login button. I don’t even know what site we are making!!”. Fortunately I‘ve never had this before, but I can imagine that could easily happen in more tech driven teams.

Designers are used to working in waterfall and it suits them very well. The fundamental premise of agile methodology doesn’t sit very well with the design ideal. The difference between agile’s ‘Do just enough to make it work’ and designers’ ‘Keep pushing until it’s brilliant’ mentality are quite hard to compensate. On top of that, visual design is such a subjective art. You can’t say ‘It works’ like you can with coding. So how do you know when visual design is ‘just enough’? No wonder designers find the agile process painful.

But. Things are getting better.

These days, people are more aware of importance of good user experience including visual design – it is becoming an integral part of Minimum Viable Product. (Interesting read about it here on Startup Blender: Minimum Viable Product vs. Minimum Delightful Product). Advances in CSS and HTML allows us to be more ambitious in terms of visual expressions = there are greater expectation on presentation standards. There is a willingness to accommodate user experience process into an agile one. Let’s take advantage of that.

Tip 1: Phase 1 for user experience and backlog creation

This is optional, but I highly recommend having a separate phase for user experience and developing Look & Feel. Especially when whatever you’re making has no brand to work from and/or the brief is loose.

It’s not Sprint 0 – This is a phase BEFORE Sprint 0. At the beginning of Sprint 0, the team should have a good idea of what they are making, and Phase 1 is there to make this ‘idea’ good.

It’s a time to look at the concept in wider context. It’s a time to create Look & Feel, stress test the ideas to create focused backlog, and run it by users.

And it’s not a waterfall in disguise. You’re not solving all the problems, but it’s your chance to have a broader approach developed and agreed. Sprint 0 is there to refine what to be developed during Sprint 1. And you have all the rest of sprints to get things right*.

*Scrum masters and project managers – you may need to think about keeping designers involved a little longer…

Tip 2: Be part of Sprint 0

It’s probably very obvious but it’s crucial for Design and UX to be a part of Sprint 0 to make sure some core visuals are designed up for the Sprint 1. Designers and UX need to stay ahead of development to minimise UI changes later on.

Tip 3: Design not ready? Use Bootstrap.

UI devs don’t need to have the ‘button designed’ on day one these days. There is Bootstrap (or something equivalent)! It looks decent and a quick way to start seeing and testing functionality without the final design applied. So don’t bother with half-baked-hastily-put-together designs. Ask them to use Bootstrap in the meantime.

It’s still important to have Look & Feel developed in Phase 1 though as this will inform the layout and construction of the page, so when you finally get around to do the design, there is a minimum pain for UI devs.

Tip 4: Things are agile for everyone

Sometimes there is a bit of unfair expectation by other team members that when you hand over any design, it should be FINAL and should not change. I agree that’s probably the case if you’re working in waterfall as you have chance to design up all the pages in details, look for inconsistency etc. But if you’re working in agile, designers should be allowed to improve things in later sprints as much as devs are.

Mind you, I’m not saying you can put off ‘getting it right’. You should try that all the time anyway. But if the design needs improving, it needs improving. Insist on it.

Tip 5: Talk to scrum master and project manager

Before any project starts, it’s good to talk to the scrum master and/or project manager over the project plan. Do raise an alarm if they are planning to make you start at the same time as UI devs. You need to explain and convince them why you need some time upfront.

Here is one example. Imagine that you’re putting new tiles up in your bathroom. What would you do first? Measure the walls? Decide on colour schemes? Choose the tiles? But I bet you won’t just pick one tile of certain design and slap it in the middle of the wall before thinking about all these things.

Designers need to think about wider context. How much wider depends on the project, but you will definitely need some time upfront to make sure that you are not creating Frankenstein with plasters all over. Remember putting plasters on Frankenstein takes time – a lot more than making something good in the first place.

Tip 6: Talk to UX

Always, always start sketching with UX. Don’t wait till you get a wireframe because you won’t like it anyway and they won’t like you for changing it so much. It’s much quicker to sit with UX and sketch it out together, so you’re all on the same page. Then you can split from the UX to do what you’re better at based on agreed approach.

Tip 7: Talk to UI devs

It’s good to talk to UI devs about design issues from an early stage too. After all they have to code it. I always ask opinions and suggestions from UI devs (and everyone else for that matter). They know an awful lot more about techs than you do and some – especially the ones I work with here – have a really good eye for design & UX.

By involving them in the design early on, it becomes much easier to improve things over sprints as the benefits and aims of doing so are clear to them.

Tip 8: Talk to everyone

I know it’s obvious, but it’s worth noting. The well working agile team talk to each other. We’re all trying to solve the same problem. You’re not tossing your work over the fence. Be pragmatic, and don’t be too precious – good designs are good whoever designed it.

And remember that you’re the champion of good visual design. Make a noise and be heard.

And well done, you made it work

There is definitely a stronger sense of contributions to the final product in agile team. Probably because you remain part of the team until very nearly the end of development.

Also it’s a rewarding experience seeing your design turned into reality right in front of you. It’s your chance to refine your design as it’s being built. So try it. You never know, you may even like it.

We were talking about how user-centred rapid prototyping works the other day, and thought it will be an interesting thing to share with the wider world. 

So what is it?

Rapid prototyping

First, let me attempt to define rapid prototyping in the context of Red Badger.

It can come in various size and forms, from 2 days to 8 weeks, depending on the propositions we want to test. The final format can be anything from paper prototypes to fully functional products.

Basically, it is a short burst of project to launch a concept in its purest form. The aim is to create a minimum viable product (often mentioned as ‘MVP’) – that is the smallest possible construction you can get away with in order to prove this concept.

Remember the early days of Twitter? I don’t think it was a rapid prototype project, but it’s a good example to illustrate what an MVP is.

Twitter started off with just an ability to post a 140 letter message, follow others and not much else. (It’s the days of a lol cat fixing their servers if I remember correctly.) But these simple propositions were what Twitter was all about. It was the minimum viable product. 

Rapid prototype projects aim to uncover the very essence of a concept and to create a small collection of features and user experience that best represent this essence.

Why essence only? Because sometimes you just have to try it to see if something works, especially if it’s something new. And the last thing you want to do is to discover that it just doesn’t work after spending months designing and developing.

The minimum viable product allows you to start learning as early as possible (For example, it might be user reactions or data performance you’re looking for) so you can start improving. You can still build more features on top later, and you’re in a much better position to judge what to add once the MVP started its lifecycle, than building everything upfront not knowing potential glitches.

It also helps you to really focus on a concept. It’s easy to lose sight of what you set out to achieve in projects because there is just soooo much you can do. If you can’t pin down a MVP, is there really a concept worth exploring?

The things to remember: you can rapidly prototype because a MVP is so focused. It’s not the other way round.

Discovery phase

Explore wider context

If it is appropriate for the proposition we’re testing and its timeline allows us, we usually kick-start a rapid prototype project by exploring and pushing our concept a bit further and it’s a vital part of the whole rapid prototyping process.

This might sound strange as what we are trying to do is to narrow down.

The thing is, how can you tell where to focus if you don’t have a bigger picture? How wide and where we explore is mostly depending on the concept – we might look at competitors, technologies, theories and papers.

And one area we always look at is the audience. 

Persona

All user experience we explore will be underpinned by personas.

A persona is a typical profile of a targeted user base. Each project can have any number of personas – some clients have already defined who the personas are, some not. These profiles are an amalgamation of real people who were interviewed or surveyed to represent different types of audience.

Personas tend to have names and look as if they exist. What work do they do? What magazines do they read? Do they watch sport? Do they like shopping? Friends and family commitments? How do they spend their day? These details bring them to life and help us get into their mind-set. 

User journeys

Once we have personas, we can look at their journeys in and out of the potential concept. 

Where is the touch point? Emily might be using this on a train on her mobile, while Luke might be using this on a desktop at work during the lunch break. Is there any features they’d like? How can this concept help them more?

We then focus on developing user experience around these user journeys. Simply because these are the places our audience will want / need to be.

Branding

Understanding of branding is important at this stage too. I’m not talking about logos, typography and colours, but about brand values and personalities. (If you want to know a bit more about branding, here is the one I’ve written earlier about branding)

While we are working on the BBC Now project, we often asked ourselves “Does this feel like the BBC?”. Established brands are like personalities on their own right, the audience will feel odd (or probably something worse) if they do something completely out of character. 

Or it could be about the first impression. One of the other projects we are currently working on aims at kids. Do we want kids to feel comfortable? Or do we want them to feel they are challenged? Is it about learning? Or wonder and discovery?

And focus again

While we look at personas, user journeys and branding, time constraints are the last thing on our mind. But once they are explored, familiar with the personas point of view, it’s time to discuss what the most compelling element of this concept is.

We create a list* of features and stories that each describe snippets of user experience, and we order it based on how essential each item is. And so, features and stories near the top will constitute the bulk of the minimum viable product, ready to be tested and developed.

*This list is called a ‘product backlog’ in Red Badger as we run all projects in agile project management methodologies. 

User testing to validate the concept

Again, it’s depending on the project, but once the concept is boiled down, it’s a perfect time to touch base with users if a timescale allows this to happen. We can show ideas in paper form and ask questions. Or create a quick and dirty prototype for them to play around with. Or it may be a large scale A/B testing (the audience are randomly shown one of the options and you can decide if A or B is better by looking at the statistics of click through etc) with real audience.

With BBC Now, we created a Flash prototype that looks reasonably realistic, so that the user can focus more on detailed interactions than trying to imagine hypothetical situations. Whereas for the project with kids, we showed them user journeys in scamps (hand drawn sketches) to encourage more creative input. 

User testing at this stage help us confirm that we’re focusing on the right area and answer any questions raised during the discovery phase. 

By this time we’ll have developed a set of scamps or wireframes of key user journeys and visual design style to go with our backlog.

And finally we are ready to start developing!

Continue to What is user-centred rapid prototyping? Part 2

We are now well into the second phase of BBC Connected Studio’s pilot project ‘BBC Now!’, developing away. (If you haven’t heard about Connected Studio, check out this blog post “Connected Studio: the first pilots” by Adrian Woolard.) The first phase has been about exploring what’s possible then distilling, finalising and crystallising our concept until we have something we are happy with.

What is BBC Now?

We have written a bit about the project already in other posts, but here is a quick summary of what BBC Now is all about:

The project was born out of BBC Connected Studio for Homepage, Search & Navigation in spring 2012. Our challenge and what our concept is all about is how to make BBC Homepage more dynamic and lively – giving visitors greater exposure to the content the BBC can offer and making that content more ‘real time’.

Our project champion Eleni has written a blog post about the concept and findings, so I am going to tell you a little bit about our approach in the discovery phase.

Exploring wider context

We kick-started this project by seeing just how far we could push our concept. This might seem an odd thing to do – after all it’s a rapid prototyping project and time is tight so we could only do a fraction of what we discussed. But for us exploring the possibilities is a vital part of the whole process.

Think of it this way – rapid prototyping is not just about being quick. It’s about being really focused on testing a specific proposition. We believe the only way to pin down the most important aspects of a concept is to explore the wider – if not the whole – picture. What would we wish for if we could wave a magic wand?

(Update: if you’re wondering what is rapid prototyping, I’ve just published another post: What is user-centred rapid prototyping? Part 1: Discovery phase.)

User testing

We were given access to a fantastic user testing facility at BBC in Salford to test out our early thinking. With archetypal rapid prototyping this is something we wouldn’t get an opportunity to do until the end of the project.

Having gone wide initially, we were able to hone in on a series of reasonably focused features that we wanted to test with users. We decided the best way to maximise the feedback we got was to create an animated Flash prototype with some functionalities, rather than creating a paper prototype.

As we were testing BBC homepage, we knew one of the most important aspects of user testing was to keep the content as real as possible, so that the lack of realism didn’t become a blocker and we could be sure we were getting a more natural response to the concept.

(If you are a UX or a designer, I’m sure you know all too well how easily people can become fixated by random typos, the mismatch of image and text or latin as a placeholder. Something written down is always easier to talk about than generic concepts of ‘layout’ and ‘experience’…)

We tried to capture a snapshot of what’s going on the day before the testing, frantically cutting some images and adding text in xml.

The testing was very beneficial. We had many interesting insights. Some positive, some negative. All contributed to make our list of features more focused and informed for the next phase.

Learn fast and learn cheaply

With an organisation like the BBC, there are understandably very strict sets of rules and guidelines that have to be adhered to. It affects all areas of project, from UX to development. But being a pilot, we are given a lot more freedom, which is great.

We often say that rapid prototyping is about ‘fail fast and fail cheaply’, but the important message behind this statement is to understand that, ‘fail’ leads to ‘learn’. We all learn from mistakes, and it’s the quickest form of learning.

So try something new and see what happens!

We recently launched a competition ‘Windows Azure Media Challenge’ with Fluxx. The prize is to win an event called RapidStart. In the 11th hour* before the competition was introduced, I was asked to make a flyer to support it. 

It ended up with a stop motion animated Lego rocket. And this is a blog about it. If you’re interested in the competition, take a look at Fluxx’s Paul Dawson’s blog.

*It was 11th hour because I had forgotten that I had Paralympic tickets on the day I planned to work on this. My fault. 

What’s RapidStart?

It’s a few extremely intense days of creative workshop and rapid prototyping. We all gather, come up with loads of ideas, and produce something tangible by the end of the event. We provided UX/Design and Dev support for some of these events organised by Fluxx. 

It’s a bit of a whirlwind experience even for those of us who have taken party in a number of these events. New set of people, new set of problem solving and new set of challenges all the time. But it’s always a very creative and productive few days, and it’s fun. 

Rocket & launch pad

My task was to illustrate the nature of these events. Quick prototyping in the way everyone understands. I was trying to explain this to my husband (a graphic designer and not-very-techie), and I was talking about sketches, origamis and Lego.

Wouldn’t it be great to build something bigger with these bits? Something that starts things off. Something that launches stuff. Did you say launch? What about a rocket launch pad?

As it was a flyer accompanying the presentation, I had a vague idea of creating an animation as well as having a few static visual ready for the flyer. A Lego rocket launch pad was perfect for it. I could take photos to make a stop motion animation!

Luckily both Paul (Fluxx) and David (Red Badger) who were creating the presentation loved the idea and got a go ahead immediately.

A stop motion fun

I started the whole thing after my little boy (2.5 years old who was way too eager to help) went to bed. 

As I only had a night (and was quite keen on the idea of sleep), I did quite a bit of planning before I started. I wrote down a list of shots for single pages to be used in the presentation. I downloaded a video of Saturn V rocket launch and created a mock up version so that I knew exactly how many frames were required and the compositions of each frame. I worked out the order of these shots to be most efficient.

I hung a sheet of paper over the kitchen table to create a back drop. I set up a tripod with my not-so-brilliant SLR and a bunch of masking tape to keep everything steady. The lighting was not brilliant, but there was nothing much I could do. And luckily, it looked quite stylish when I took a test shot. I was ready to go.

First, I took a series of shots for the launch. Looking at the edited Saturn V video, I added some smoke using white and yellow pieces. Then took a series of shots for building the rocket and the launch pad – backwards. I was removing one piece per shot. 

Then took a few more shots for other uses to finish the photoshoot. Like a bunch of Lego pieces to represent little bits of ideas at the beginning of the event.

And lots of different ideas.

All images for animations were put together in Flash for the presentation. Not sure if it was the best solution, but it did a job. Phew!

And here is the final animation that I stitched together later in iMovie. (In the presentation, it was separated to building bit and launch bit.)

Rapid Start Rocket Build & Launch from Sari Griffiths on Vimeo.

It was good fun making this. And yes, I did get some sleep too!

You may have noticed that we’ve recently rebranded.
Here is a brief account of how we did it.

Why rebrand?

The previous Red Badger brand was created when the company was set up by Stu, Dave and Cain. It served us very well, but as we grew, we felt that it no longer represented us and our ambitions as accurately as it did. Also we all had our own ideas of what Red Badger was all about, but there was no simple way to describe them. Working on a new brand would help us see and express ourselves more clearly in a single(ish) voice.

Brand essence workshop

The first workshop we had was about defining a brand essence. It’s basically a few words that describe and sum up the brand. Coming up with the brand essence helps you to focus on what the business is all about.

For example:

• BMW Ultimate Driving Machine
• Coke Open Happiness
• Disney Magical
• Starbucks Rewarding Everyday Moments
• Sony Digital Dream Kids

Okay, these are big brands. And we are not trying to be one. But there is a definite benefit in coming up with something like this.

To find one for us, we did a few things.

1. Personality questions – “What would Red Badger be if it’s…”

We sent a questionnaire around the office and to some of our clients to find out how we see ourselves, and how we’re seen. All questions started with “What would Red Badger be…” and asked things like “…if it’s a car?”, “…if it’s a person?” and “…if it’s an everyday object?”. It was fun and a very useful exercise to find out what everyone thinks of us.

2. Looking at Red and Badger

We started the branding exercise by saying “we might not have a badger in our logo, and we might not use red”, so it was important to look at the meaning of both words to see how relevant they could be to our brand. After all it’s our name.

3. Who are our competitors?

We printed out all potential competitors’ website – or the ones we thought were competitors – to see the space they occupy in the industry visually. By the time we got to this stage, we had a good idea who we were and realised most of them were actually not in our space.

At the end of good discussion, we settled with a set of keywords rather than having a snappy brand essence, and we got a tagline we all liked. (Thanks Stu!)

“Experience. Design. Technology. Crafted.”

Look & feel workshop

Having agreed a tagline and a set of keywords, we had another workshop looking at how these can visually manifest themselves.

As ‘craft’ was one of the central themes that connected many of our ideas, we kept coming back to the idea of a ‘workshop’ as a physical space – where we craft and experiment.

We looked at different visual styles for the new identity and fonts as well. As we were on the same page with our branding, this stage went pretty smoothly. Sketches and photographs are in. Furniture makers’ marks are in.

Now all the important thinking had been done. Let the fun of making begin…

The badger

We looked at the identity as we started looking at a new website. Initially we were looking at a more typographical approach – as is common in Furniture makers’ marks – but in the end we settled on our new Penguin-esq badger. We thought it was appropriate to have a character in the end, considering our clients sometimes refer to us as ‘badgers’.

The strong visual style allowed us to have more than one logo format.

We also like the idea of having a stamp made to show ‘badger approved’ quality.

The red

We concluded that if we were going to use any colour, it had to be red. It’d be a bit confusing otherwise, wouldn’t it? So the red is in. We picked a bit brighter red than in the previous logo.

What now?

We are in the middle of applying the new brand everywhere, including the website. In the true workshop spirit, we’ll keep working on it. And have some fun!

It’s been a month already (where has my month gone?) since  I attended a workshop for Windows Phone Design Clinic on Thursday 10 May at Soho, London, organised by Microsoft and Nokia.

Can’t believe it’s Microsoft

I was 10 mins late coming in and as I walked in, I was greeted by a presentation showing classic Swiss Typography. This the kind of stuff I learned about at art school and the kind of stuff I’ve got a quite a few books about at home. Examples include beautiful urban transport signs from around the world and the famous grid system.

Here are some posters by Josef Müller-Brockmann – typical Swiss Typography.

The audience was about half developers and half designers, so I’m not sure how the developer folks took to this presentation, but my honest first opinion was: this is a lovely design – can’t believe it’s Microsoft. (Sorry!)

I have seen their Metro design templates prior to the workshop, so I knew it was pretty ambitious. But hearing from Dave Crawford first-hand how it came about and what it was all about, it really hit home. This was really happening and it was very well thought through.

When iPhone changed the smart phone market, it was revolutionary. But its iOS design relied heavily on real life metaphors of buttoned machines. I suppose this was to  provide some clues to how a crazy device with no buttons works.

That’s a while ago. These days, users are happily swiping and pinching their devices away – they know how these button-less things work now. It is the perfect time to rethink interfaces for touch devices.

It was surprising that it came from Microsoft.

Let’s face it, they were not really known for good graphic design (Some old fun: Microsoft repackage iPod video). Their brand was more of ‘you can do anything as long as you know what you’re doing’ and it’s about performance, not the look’.  Whereas Apple was more about ‘user experience’ and ‘our way is the right way’.

Lately, I think there is a shift in this positioning. Apple is still criticised for not making iOS open enough etc, but as long as their user experience is concerned, it’s anything goes. They are not doing much about their slipping standards of user experience and slick graphics, that they were once famous for.

Android provides an alternative to iOS, but it is an alternative. The interaction models aren’t very different. It basically has a few more physical buttons than the iPhone. Having said that, it is a jolly good alternative with lots more freedom for developers.

And now with Metro, Microsoft is providing a new approach, rethinking the interaction model for touch screen devices.

Two points stand out for me.

1. Panorama interaction: the edge of screen isn’t the edge of screen.

The screen they call ‘panorama’ is a wide page with a few columns. You have to swipe to see it all, but it’s pretty intuitive to use. It really brings the horizontal direction into play, not just vertical.

2. Back means back.

Metro doesn’t encourage apps to have a ‘home’ button. Sometimes it’s unavoidable, but if you can get away with it, it’s better for it not to be there. Having this principle really challenges you to think about interaction and user experience, and not to default on the standard website model that you see a lot on iOS.

Respect your device

In one of Dave’s slides, he told us to respect a few rules. “Respect your device” was the most memorable one.

There were a few comments from the audience about some clients asking for the apps across mobile devices to be identical because they want consistency. Between iOS and Android, their similarity allows these apps to seem pretty identical, but not in Metro.

I thought the question for this situation will be “what ‘consistency’ means in this context?” It is unlikely that someone is holding two devices side by side, using the apps and saying “oh, they’re not the same”. It’s more likely the user feels they are the same. If your back button didn’t go back as you expected it to do, you feel it’s wrong, even if that’s what happens with other devices. Consistency can only come from how well the app operates on the particular device you’re using.

Having worked on an app for iOS and Android, for both to have the same feel, I know that they can’t be identical either. There are subtle differences due to the existence of the back and menu buttons, forcing architecture to be different. However their visual styles could be very similar, giving the illusion that they are identical.

Okay, I admit that recreating an iOS app for Metro requires a much harder rethink than doing the same for Android. Several speakers at the workshop recommended going back to the drawing board rather than trying to translate. And actually, your app could work much better in Metro than in iOS as a result of it by digging deep into the concept of the app and the brand.

So would I use it?

Yes is the simple answer.

I am a long-term iPhone user but I really wanted to try this out. It’s great having someone challenging the way we interact with devices. It’s a beautiful system to use and look at. I’ve asked for my company phone to be a Windows Phone 7.

I am also looking forward to doing some work on Metro. Although it’s really well thought through, it is not an easy task to design for one. You still need a good design to make it work. But it’s really exciting to see where it’s heading UX-wise. Now, what I’m not so sure about, is what it’s like for devs…?

For further reading about designing for Metro: http://ux.artu.tv/

Following the BBC Connected Studio’s first Creative Studio for Homepage, Navigation and Search – attended by Cain and Alex, we were one of nine ideas invited back to work on two days of rapid prototyping to prove our concept at the Build Studio. On Monday 21st and Tuesday 22nd , four of us – Stu, Haro, Can and I – went up to sunny Salford for a couple of days of intense developing.

The background of BBC Connected Studio is covered by Cain in his blog about the Creative Studio, so I will go straight into describing the two days.

Day one

After a smooth registration and a much needed breakfast, we gathered in the bright and airy 6th floor room at Dock House, Media City, Salford. This was going to be our home for the next couple of days.

Adrian Woolard (Project Lead R&D North Lab) got the day started again. Briefing was short and to the point, already feeling the heat of the day. Everyone in the room was itching to get started. All nine teams grabbed a table each and started straight away. Faulty power sockets were sorted out within a minute, and a mountain of sweets and snacks arrived shortly after – though unfortunately without Wagon Wheels (Much to Adrian’s disappointment).

While we were setting up and getting ready, Adrian and Eleni (Senior Product Manager of BBC Homepage) kindly gave us some brief feedback from the last session as none of us individuals attended the Creative Studio. Many BBC gurus stopped by to chat to us, and especially Ross – the personalisation guru – gave us lots of interesting insights. It was brilliant to talk through your ideas and try to explain concisely, the best way to visualise your idea with clarity.

We spent the rest of the morning reviewing what was available code/data wise, and planning what we were going to do. In terms of concept, we decided to be single minded and focus on one aspect of Cain and Alex’s original proposal, that evolved into “Discovering new content in real time”. In terms of code/data, we decided to start certain areas from scratch (rather than using the homepage code that the BBC provided) using Node.js alongside using the data provided as is. It was a difficult call, but given the time frame, we felt that would be the quickest route to what we wanted to achieve.

After a good lunch, we were running at top speed. Actually the whole room seemed to be running at top speed. There were lots of conversations and frantic tapping of keyboards. You could almost hear the hums from everyone’s brain working. We were all blinkered, totally focused on what we were doing. Everything must be done by 4pm the next day!

By the time we left the building, you could probably see some steam coming out from our (and everyone’s) ears… We had some much needed drink and food, then straight to bed!

Day two

Another beautiful sunny day.

All teams were given a slot to talk to the audience in the morning to see what they thought of our concept. As Stu, Haro and Can were developing away, I picked up the task to take the audience through some flat visuals.

The audience responded to the idea very positively, and it gave us great insights. Some confirming our convictions, some giving us new ideas.
“It would definitely change the way I use the homepage”
“If it’s like this, I don’t mind logging in”

Encouraged, we worked through the afternoon, and before you knew it, it was 4pm. We were all still buzzing as we sat down for the presentation session.

Nine teams presented in a friendly atmosphere, all listening intently, exhausted but proud of what they achieved in such a short space of time. We were also keen to finally find out what all the other teams had been doing around us.

We presented some visuals to explain our concept along with the prototype. Stu wanted more from the prototype – as he always does having such a high standard! – but I thought what we achieved was just right as a proof of concept.

I personally really enjoyed presenting which I don’t usually. Talking to so many people before hand helped me hone what to say and the very positive atmosphere at the presentation undoubtedly helped too.

That was it. It was brief beer time then home time.

So what did we think?

These were a frantic and fantastic two days and it was amazing to see that everyone achieved so much. After all it was a sort of a competition, but it was such a positive and buzzing atmosphere, it didn’t feel like it.

It was a shame we had to run to catch our (very delayed) train at the end. It would’ve been lovely to catch up with everyone over some drink. But hey, I’m sure our path will cross again.

Big thumbs up and thanks to the BBC Connected Studios team. It was run very smoothly and everything seemed to go to schedule. We enjoyed every minute of it.

If you are thinking of attending the future events, go for it. It’s exhausting but so much fun!

http://www.bbcconnectedstudio.co.uk/

I always had a problem with the term ‘User Experience (UX)’ being used to describe a particular discipline – not that I don’t agree with the fact that’s what they are predominantly concerned with. I just don’t like that it seems to imply that other disciplines are NOT about user experience.

I am a graphic designer, and it is definitely (should be) about user experience. But that’s probably very obvious – so I didn’t complain.

And there are developers.

I recently read an excellent blog about the UX developer by Leisa. She makes a point that some front end developers are so in tune with the idea of user experience, they can be called UX developers for their contributions. 

I cannot agree more. But I also agree with one of the comments the article has – “UX dev is just a good front end dev”. Because of front end development’s closeness to users, in the same way as the visual design and site architecture, it has to take user experience into consideration to do a great job.

What about the back end devs?

You might think, well, it’s not important that they understand UX – after all they are not creating direct touch points to user journeys. 

I am lucky enough to have worked with some back end devs (i.e. Stuart and David) with strong UX understanding, and oh my, it REALLY makes a difference.

There would be no ‘you can’t do that because it’s not built / structured / stored in the right way’, because they understand the importance and WHY you’re asking certain things to happen. They would be coming up with alternatives to achieve your goal, or find the way around it. They could suggest you a new way of doing things which you thought technically not possible (or plainly not thought of), because they understand the user journey and user experience principle. It’s the same in any disciplines – you can solve problems so much better / quicker when you know WHY something needs to happen rather than just WHAT needs to happen.

So my conclusion is – UX devs definitely exist and it includes ALL devs. If in doubt, try working with one. It’s so good, you don’t want to work without them ever again.