Posts Tagged ‘musings’


No upfront design? Really?

by Sari Griffiths

I have recently read a book (Responsive Design Workflow) and a blog (Stop doing upfront design, it’s a waste of time) talking about how designers can work in agile and the benefit of doing so. I agree with pretty much all they suggest and highly recommend you read both. (If you’re interested in how designers can work in agile team, here is my previous post: Agile Survival Guide for Designers.) But I found the phrase ‘no upfront design’ a bit troublesome. I felt this was a bit like headline writing – correct in some respects but sensational and ultimately misleading. A better definition is needed of what exactly constitutes ‘upfront design’.


‘No upfront design’ only when there has been upfront design

If you read carefully, the process these articles recommend DOES include some upfront design. They assume you already have something – brand guidelines, interaction language, visual assets – to work from. So while ‘no upfront work’ is needed for detailed designs, the branding and general look & feel work need to be in place… upfront. 

Other things you need to have upfront include: the creative concept and the questions you are trying to answer (you’ll also need to know which is the most important question). And to me, these are some of, if not the most important tasks to do during the ‘upfront’ design phase. 

‘No upfront design’ for designers but upfront design for the team

When they say ‘no upfront design’, it seems to mean ‘no upfront design as designers know it’. Probably because these articles were written for designers, the important part of the message is omitted. But I think it’s more beneficial to look at the role designer plays within the team rather than within the limit of the design discipline. 

What we found works best at Red Badger is to bring developers into upfront design process. All disciplines work together. What designers no longer do is to do upfront design in isolation

You still need upfront thinking and designing in one form or another.   

We work on the concept together (okay, maybe not all developers, but definitely a technical architect and any available team members). It’s essential that we all know and have an input into the why, what and how of the project. 

It definitely makes sense to start coding early too. You can experiment and play around with movements and structures – not just flat designs (a must for responsive design), pushing technologies. It will give you a creative solution that can be realised as you have envisioned it, and that can be taken seamlessly to the development phase – blurring the upfront and development phases of the project. 

When designers code

I think it’s great that visual designers are encouraged to code and experiment and I’m sure it will be the norm in the future. I like doing a bit of coding myself. But I think you should have one simple ground rule.

“Don’t design in browsers” – Jenn Lukas at Ampersand 2013

I have just attended the Ampersand Conference in Brighton where the very entertaining Jenn Lukas  introduced many ways that designers and developers can work closer together, and a lot of cat based GIF animations. She spoke about letting designers create a type set, using Typecast, creating icon fonts using IcoMoon and making CSS valuables (colour values, font sizes etc) directly editable by designers. She also suggested adding a screen size in the corner of the development page so that designers can make design decisions on break points for a responsive website in the live environment.

Then she made the point – “I don’t recommend you to design in the browser. It limits your design”. It was interesting to hear that from a developer’s point of view. It’s a good idea to test the design early in code and then improve – but don’t limit your design by confining yourself to a browser window from the beginning. 

If you find yourself constrained by the browser, stop coding and go back to the paper. Coding should help expand your creativity rather than limit it.

Mix it up

What does this all mean? It means things are mixing up. Boundaries between disciplines are overlapping. (Have you tried to find ‘UX designer’ recently? There are UI developers, visual designers and UX consultants who would all call themselves ‘UX designer’) The development phase is creeping into upfront design phase, and upfront design phase is creeping into development phase.  

Orders and processes are changing and I guess the easiest way to describe this is by pointing out what it’s not. But saying ‘no upfront design’ suggests what’s left is still intact – when in fact, the rest of the process also has to change.  

So it’s definitely not ‘no upfront design’ for me. It’s more like ‘design and develop from start to finish’*. Doesn’t it sound more fun?

*It needs to be catchier… Any suggestions?


Thinking Digital

by Sari Griffiths

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.

View from Thinking Digital
“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 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.


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.


What is user-centred rapid prototyping? Part 1: Discovery phase

by Sari Griffiths

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. 


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.


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


UX for every one – UX developers are here.

by Sari Griffiths

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. 🙂


The new Badger

by Rachel Eyres

Rachel in the office

So I’ve joined the team at Red Badger, and now that I’m 2 weeks in I thought I’d share some musings. For those that don’t know me, I’m the new Director of Client Services, which means I’m going to be responsible for all things business development, account management, marketing and  generally helping the team to grow the business. And refreshingly, that doesn’t just mean “make as much money as fast as possible”, but rather focus on interesting, value-adding work which plays to the company’s strengths – use of cutting edge technologies, blended UX and delivery teams, innovation and creativity. So I’ve spent a couple of weeks settling in and doing all the things you’d expect. I’ve been getting to know the team, meeting some of RB’s very impressive clients, telling some of my own contacts about the company’s capability, and the thing I’ve spent the most time on so far is drawing up a business development strategy for the company. This is still a work in progress and needs lots of input from the founders, but it’s starting to take shape. One of the things I love about smaller companies is you can be creative, unconstrained by history and structure, and just come up with some great ideas and go after them.

Here’s what I’ve noticed so far:

The focus – the guys who set up the company are friends I’ve worked with in the past – they were always outstanding and focussed but doing their own thing has amplified this, and their commitment has rubbed off on the entire team. Everyone’s top quality, really into it and switched on. And how many consultancies can you say that about?

The team feeling – usually there’s at least some friction between the UX guys, the developers, the project manager etc. Not here. Everyone seems to instinctively, and through experience, get what each other is trying to achieve and they can genuinely work together. lovely.

The techy-ness – whilst it’s integrated and design focussed, this is a very technical company. The guys are forever trying new things, just to see if there’s a better way, which really pays off.

Just doing it – I’ve spent some time recently at an organisation that provides advisory services on cloud computing and other venerable subjects, which is great but very slow and time consuming. None of that here – we’re just doing cloud, we’re just doing 3d, we’re just doing multi-channel, we’re just doing mobile. There’s no fuss, no-one’s shouting about it and trying to turn it into a pretty picture, it just happens.

So I’m excited, which is a good place to start. The work we’re doing at the moment for customers is very exciting, the focus areas for the next 12 months are pretty cool, and some of the new product ideas the team are thinking about will blow your mind. But more on that stuff later. For now it’s just “hello, I’m here, taking it all in, liking what I see so far…..”