UX Tip of the Week: Meet Bob

by Maite Rodriguez


From the developers to creatives to business people, how to get everyone to finally understand the what UX is really about.


Let’s get started.


I would like to introduce you to Bob.


He will be our “user” for today.



Bob = User


For starters, you should always make it clear it is all about the “user” aka Bob.




If this is not absolutely clear from the beginning, then there is no point in reading the rest of this …..





Stop using the term “user” to the team. These “users” are people with feelings like Bob. Try to use the persona’s name that the UX team meticulously researched and created for the brief.


Personas are there for a reason….


If you have to, frame a photo of your persona, let’s say Bob, and place it next to everyone’s computer as a daily reminder.



Let’s make this abundantly clear, people are not “stupid” or “slow” or “lazy”.


If your “users” do not understand the design, it is 99.999999999999%everyone’s fault involved in the project.


One team, One accountability.



If you are not there to defend the “user” … then who will? If there is no one representing Bob, then there is no UX.



Do not resort to the easiest tech solution. I know, it’s hard…


Mo’ work, mo’ problems.


But, if it’s for the “user” aka Bob’s best interest sometimes we all have to make sacrifices. As that great kung fu fighter once said in that kung fu movie:


“Take the hard righteous path than the easy wrong one to save the kingdom.”



UX is not like paint. We can’t just slab some paint on a chipped wall and call it a day. It is much more than that, so much more.

Here’s in on little insider secret…. UX doesn’t really exist.


UX is just a easy term that is used to group a whole lot of things that would take too much time to explain in one simple job title.



So, if you just take one thing from all of this, remember:


Every code written, every interaction made, every word read, every visual seen, the “user” should always be taken into consideration.


So, today I will rename the term “user” to “people” because it is all about the people’s experience…. Bob’s experience.


Until next week….




UX Tip of the Week: Post-its

by Maite Rodriguez

The Magic of Post-its



Post-its, Post-its, Post-its, Post-its, Post-its evuuuuurrryyyyy where..


All you need is a pen, wall space and post-its for your inner genius to come through.


When should you resort to post-its you ask?


  • Feeling overwhelmed with all the initial research and don’t know where to start….. post-it

  • Creating a christmas shopping list that you still haven’t started …. post-it

  • Need to do a feature analysis for a competitive website… post-it

  • Takings note at a meeting… post-it

  • Preparing a plan for action… post-it

  • Can’t decide where to eat for lunch…. post-it

  • Weighing the pros and cons of anything really… post-it

  • Need to prioritise and MOSCOW your project… post-it

  • Explaining to you co-worker how to get to Dirty Burger… post it

  • Trying to understanding foreign concepts (aka not related to UX) …..post it!


See! I challenge you to find a moment when the post-it can’t work its magic.



Until next week…..





UX tip of the week: Competitive analysis for mobile navigation

by Sinem Erdemli

We started the week with user testing on an e-commerce site. It was all good until we asked people to find something, they had no idea how to work the side navigation.

And that was a surprise. 


It was obvious that users were struggling with it and it wasn’t a batch of those users who can’t work anything and have no idea what’s going on. There’s a limit to how much you can blame users.

The question in hand was obvious, one we had been pondering on for a while:

How might we get the benefits of a a mega nav on mobile?

So we went back to the office and got our post-its out. (Keep your eyes peeled for our next post on why post-its are king)

It was time to take a step back and clear our muddy heads. 

The game plan

1- List out relevant websites that have a similar issue (in our case it was squeezing mega nav content into mobile navigation)

2- Collect screenshots, the more you have the more ideas you can “steal” nope not that.. borrow

3- Break down the screens into it’s components. This is where the mighty post-it comes to play. 

4-List out Pros and Cons for each. Identify your favourites.

5- Sketch out the flow for each, find out how the users are lead to a particular Product Listing Page. How soon do they see the content? 

6- Compare flows. Visually comparing the flows let you highlight differences at a glance, it helps understanding (and communicating!) what works and what doesn’t. 


6.a- If you can, go out and test the few examples with people, see if any alternative stands out, find out what people think. 

7-Show this to any stakeholder, it may be the client, it may be the designers, the dev team.. Talk about the issues users has, show the comparisons, think about what’s possible what needs more exploration..

8- Identify what you like, what can be done, with a little help from the favourite features list- and try it out. 

Taking a step back and looking around is useful. You clear your head, benchmark yourself among others and get to spend some play time.  Try it, you’ll feel better. 

Until next week, 



UX Tip of the Week: Guerilla Testing

by Maite Rodriguez

What we learned this week:

Guerilla Testing

How to approach people and lower your chances of being rejected.




  • Choose a location where people in your target audience are likely to convene. In our case it was a Co-op working space.
  • Go right at the end of lunch time when people have finished their food and are more likely to crave sweets.
  • Bring candy, brownies, cookies… get creative and place it next to your working space. Try to avoid being creepy. A fan to blow the smel may help catch their attention. Kidding!
  • Smile and ask if they have time to spare. (The amount of time you will be user testing)
  • If they say no let them walk away. No begging.
  • If they say yes, game on.
  • When you ask them the pre-screening questions and find out they are not your target user, its okay to cut the testing short.
  • Take notes. Voice recorder, video recorder or just a plain old note pad.
  • ASK PERMISSION before you do a voice or video recording!
  • During the testing. Watch, Listen, and ask follow up questions like:
    1. Why?
    2. What did you expect to see?
    3. How did that make you feel?
  • After 3 users it starts getting tiring.
  • Go home.
  • Next day, review notes and find the trends.




  • Just show up with nothing prepared and wing it.
  • Lie and tell them it will take them 2 minutes when it will actually be 10.
  • User test anyone who is willing to talk to you.
  • Invade their personal space once they are close enough.
  • Creepily stare them down as they walk towards you.




The end




Nodeconf Budapest 2014

by Alex Savin

Nodeconf Budapest

Suddenly, there is this moment in your life when you find yourself at the Node JS conference in Budapest. A one day single track event named One-Shot, with a bunch of speakers and a nice variety of topics, complemented with great Kenyan coffee and Hungarian craft beer. Organized by the local Javascript shop Rising Stack.

Some of the talks and slides are already available online, so I’ll just go through some of those that I feel are worthy of your attention.

Hacking with Tessel

Matteo Collina did a rather brave demo of live hacking on a Tessel – a Node-compatible microcontroller with built-in wifi and a bunch of extension modules.

What’s the first thing you do, when you get a shiny new microcontroller? Make it blink the light.

There are a bunch of npm modules compatible with Tessel, which makes it great fun to hack on the hardware and make it do various things for you. Like blinking lights in various fashions. As was expected, things didn’t go smoothly, but Matteo managed to stay away from cursing and get things blinking (again).

Torrent with Node

Mathias Buus was venturing onto the p2p side of the internet. After a short introduction to the technology behind torrents, Mathias demonstrated how easy it is to implement your own torrent client with Node, and even stream video. But that was not enough – the next stop was infamous Docker with its (rather large) images. During the course of a spotless demo, Mathias managed to share a Docker image via torrent, stream it on another machine, boot it and launch things. If you’d decided to launch Node, it would torrent-stream all the necessary files for a proper launch, but nothing else. And yes, you can do this too – the thing is named Torrent Mount and allows you to mount a filesystem via torrent link.

Docker with Bittorrent

Check his talk (Docker demo starts at around 15 min), and slides.

C J Silverio told a story of something we all take for granted most of the time – npmjs registry. How it all started as a small side CouchDB project and then miserably failed when the world suddenly start doing npm install way too often.

Watch how things evolved for npm, becoming faster and more reliable (or check out slides).

A full list of talks is available on the Rising Stack YouTube channel. Ok, here is another worthy talk – Design for Retry by Aria Stewart. She talks about something we all try to avoid – errors and how to design proper error handling in web apps.

Nitro coffee

Breaks were spiced by a special kind of cold brewed coffee, mixed with nitrogen. Yes, nitro powered coffee is a thing, and I’d love to taste it again next year.


Silicon Milkroundabout – From both sides of the fence

by Roisi Proven


On Saturday May 10th, I nervously walked through the doors of the Old Truman Brewery for the first time. I’d heard good things about Silicon Milkroundabout, but had always been too nervous to give it a go myself. However, job dissatisfaction paired with the desire for a change drove me to finally sign up, and I was assigned a spot on the Saturday “Product” day.

I have to say as a first timer, the experience was a little overwhelming! The hall was already starting to fill up when I got there at 12pm, and there was a maze of stalls and stands to wade through. The SMR staff were very helpful, and the map of the hall I got on entrance made navigating the maze slightly less daunting.

I’d done my research before I got there on the day, and I had a little notebook of companies that I knew I needed to make time to speak to. There were 5 I felt I HAD to speak to, and a few that I was drawn to on the day, based on their stand or the company presence overall. At the top of my shortlist was Red Badger.

In May, RB had a small stand near the door, not in the middle of things but easy to find. I had to do a bit of awkward hovering to get some time with one of the founders, but when I did we had a short but interesting conversation. I took my card, filled in the form, and kicked off a process which led to me getting the job that I am very happy I have today.

Fast Forward to November, and my Saturday at Silicon Milkroundabout looks a whole lot different. This time, I’m not a candidate, I’m the person that people are selling themselves to. A different sort of weird! The Red Badger stall looks different this time around too. Where before we had a small table, this time around we had an award-winning shed.


That awkward hovering I said I did? There was a lot of that going on. Having remembered how daunting it was to approach a complete stranger and ask for a job, I did my best to hoover up the hoverers. I had a few really interesting, productive conversations during the day, but just as many were people who just wanted to compliment us on our stand or our selfie video. It was great to get some positive feedback for all of the team’s hard work on the run up to the weekend.

The biggest difference was, given the fact I was standing still, I was able to fully appreciate the sheer amount of people that came through the doors, and the variety of roles that they represent. The team at SMR have done a great job of keeping the calibre of candidates high, and it does seem like there is a candidate for almost everything the companies are looking for.

Here at Red Badger we’ll be combing through the CVs and contacts that we made over the weekend, and will hopefully be making contact with a several potential new Badgers soon. For anyone that met us this time around, thanks for taking the time out to hang in our shed. For anyone that missed us, we’ll see you at SMR 9 next year!


Badger Academy – Week 10

by Sarah Knight

Badger Time Retro

This week Joe introduced us to the concept of Agile Retrospectives. This is an opportunity to look back at the project so far and review how everything is going. What do we want to start doing? Continue doing more of? Stop doing? It’s a good way of opening up communication about what we think we need to improve on, and come up with specific ways this can be achieved.

We decided that the easiest way of tracking this was by Trello board. We’ve got 4 columns:

- To improve
- Improving/Monitor
- Improved
- N/A – (this is for if we later decide that a card is no longer relevant, but doesn’t fit in the improved column)

We created a card for each thing we want to improve on, and labelled it STOP, START or CONTINUE. These were all placed in the ‘To improve’ column. We then went through them all and discussed how they could be implemented, or if any of them needed to be reworded to make them more SMART.

A few examples:

START: Descriptive pull requests for every card currently in development, with a task list.
CONTINUE: Tracking possible enhancements as GitHub issues.
START: Using blockers (as a marker) for stories that can’t be worked on for some external reason (or because you’re stuck).
START: When pairing, make sure to swap around who’s writing and who’s reviewing.

I’d not come across the practice of a retrospective in this form before, but think it’s a really great method to open up dialogues about things you want to do differently. We’ve been using it for a few weeks now and are really seeing the benefits. Communication has improved, and coaches and cubs alike are able to see who’s been working on what, and how things are going. At regular intervals we revisit the retro board and discuss our progress. It’s a good way to track improvements, as we move cards from one column to another, and ensure that we continue to think and talk about other improvements we’d like to make.


We added in the functionality to edit a resource on the front end and back end. However, because a resource can be linked to a role, which has days associated with it, changing a resource cost could potentially affect the costs on a number of days and therefore projects as a whole.

So on the front end we needed to provide some options as to what editing a resource would actually affect.

Affected projects

- No bookings – no previous bookings would be affected by the new cost, it will only be applied to future bookings
- Bookings from – allows the user to choose a date and any booked days from that date onwards will have the new cost applied
- All bookings – All previous bookings will be updated with the new cost

So that the user can see exactly what they’re doing, we needed to flag up the projects and phases that would be affected by any changes they made. However, because a resource isn’t directly associated with a project, but via a role, that belongs to a phase, that belongs to a project it was a bit tricky.

project associations

As you can see from the diagram above, editing Resource 1 would affect Project 1, and both its phases (via Roles 1 and 3). Editing Resource 2 will only impact on Phase 1 (via Role 2), but still affect Project 1 as a whole.

We needed to go through all the roles linked to the current resource id, and in turn go through all the phases associated with those roles, and the projects associated with those phases to build up a list of affected phases and projects. Several phases from the same project could be associated with the same resource, so we needed to make sure that the projects didn’t get repeated.

To filter by a from date, we needed to add in an extra step to turn the string from the date input field into a date object. We then went through all the roles linked to the current resource id and filtered out those that have a day with a date greater than or equal to the from-date. Then pass in the list of roles to the same filtering process as above.

At one point we got a bit stuck trying to do a nested filter to get the roles that belonged to the resource, and find the days that belonged to those same roles. Viktor pointed out using a second ‘filter’ returns an array to the first filter when it’s expecting a boolean. So we changed it to ‘any’ which does return true or false and everything worked!


Will cars become the new mobile?

by Mike Altendorf


It seems slightly crazy to be talking about ‘the new mobile’. It seems like mobile only recently became the new mobile and I can’t even remember what it was before that. Such is the speed of change in this digital world of ours that simply by proclaiming something ‘new’ makes it old. What I find particularly interesting at the moment though is that it seems it is more reinvention than invention. The ‘internet of things’ is in the process of breathing new life into a host of everyday objects. I heard today about a company that is developing a lock that will text you if it is being broken into; I have heard about belt buckles that will alert family members if elderly relatives go on an unexpected walkabout; shoes that analyse the way you run, even toilet paper holders than text you when they are about to run out (ok, maybe I made the last one up).

All of sudden every physical thing around us has an opportunity to become something else. The thought is actually overwhelming. Can we deal with that much information? Do we need it? At what point does it become too much? In a dot.com-esque way there is no doubt that there will be many missteps along the way but there is no doubt that the ‘internet of things’ is set to revolutionise our lives and there is one piece of everyday equipment which I think has the potential to become ‘the new wearable mobile’ and that is the car.

The idea of the car that is more than the car has been with us as long as the car has. In 1938 at the New York World Fair General Motors predicted that motorists would be able to simply type in a destination, sit back and relax (http://www.economist.com/news/business-and-finance/21618531-making- autonomous-vehicles-reality-coming-street-near-you). Those of a certain generation will have dreamt of having their own Kit that could not only talk to them but could save the day against any baddy out there (and there is always the Batmobile of course). Cars have always had huge potential and right now we are on the cusp of that potential being realised. As far as platforms go cars have far more to offer than the mobile phone. They don’t just tell you where to go, they can take you there. The computing power in the average sedan is already overtaking that of a smartphone. Sensors help us park, keep us from getting too close to other cars on the road, alert us to obstacles, sense and adapt to different weather conditions, open garage doors. We can call, email, surf the web, watch movies. Almost without us noticing cars have become a whole lot more than four wheels and an engine. 

The reality is however that we have barely scratched the surface of what is possible. With the exception of mobiles and computers, cars are the machines that the majority of us spend the most time engaging with and now we have the possibility of them communicating with their surroundings? This not only opens up the idea of the self-driving car but of a whole transport network that is communicating internally. Cars talking to each other, to traffic lights, to buildings: Cars that are monitoring you as you drive, evaluating your behaviour and adapting accordingly, communicating with people and places. Imagine a car that can not just call for help from an accident but automatically request an ambulance? Cars that can prepare your house for your arrival or come and pick you up when you have had more than half a pint? 

The thing is once we no longer need to concentrate on the road that frees up the time we spend travelling to do other things. Retailers need to consider whether a car will become the next device from which people will shop and how they can exploit tech to connect with it. Unlike the mobile it doesn’t need to be small enough for us to carry round – in fact it will be carrying us around. What would you do with a screen the size of a windscreen if you didn’t need to be able to see out of it all the time? 

All of this might seem a bit fantastical but when you consider how mobile has exploded in the last five years perhaps there is a chance that I will be taking delivery of my very own Kit sometime before my 60th birthday.


Badger Academy Week 9

by Eric Juta

Badger Academy endeavours have slowed down slightly, managing my last year of university and working part-time is a becoming a sizeable challenge. Much more so to come once I arrive in the real world!

In reference to Albert’s post, I personally have found the same experience that working at a startup while at University is a significant contribution towards my own academic performance! The amount of trials and tributes faced at Badger Academy have prepared me for kata-like performance at University. There’s so much I’ve learned at Badger Academy that isn’t taught at University or put into practice! (Sadly they don’t teach git workflows at University)

I highly recommend working for a startup and gaining experience in preparation for post-grad life. My dissertation has its foundations laid ahead of it due to the concepts taught at Red-Badger!


The architecture of a single page application talking via ajax requests to the backend rails api emphasizes data flow. Without the chance to just install a ruby gem and have most of the work done for you, we are forced to implement the same methodology and best network practices (As demonstrated before with Nginx).

The process of authentication leading to API-data fetching is similar to a TCP Three-way handshake.

In Badger-Time, the process occurs like the following:

  1. The clientside router checks if an generated authentication token is stored in HTML5 LocalStorage on any route (A persisted datastore in the browser with its own API)
  2. The router redirects the user to the /login route and renders the React.js component
  3. The user logs in with their pre-registered Badger-Time details.
  4. The user’s credentials are verified in the backend api, a generated authentication token is sent over (Made to expire after a day until a refresh call is made by the user)
  5. The generated authentication token is received, it is stored in HTML5 LocalStorage.
  6. Sequential requests from then on after include the authentication token in the request headers.
  7. The API checks if the request header has a valid authentication token and replies back after executing the body of the request.

(I take that back, that was more like 7 steps rather than 3)

Technically and code-wise, the above process is implemented and our decisions in doing so are:

  • NPM’s Superstore-sync module to have an API for setting and getting the auth token from HTML5 LocalStorage.
  • Modification of the API helper on the frontend to send token in all request headers if present.
  • A Before filter/action in the Application controller to verify whether the request header has a token for a session table match; there is also an expiry value.

  • An action verifies the appropriate BCrypt encrypted password details and generates a token value from a hash.


A similar fashion is seen via the OAuth protocol to talk between the backend rails api and FreeAgent.

The tokens are stored in the process environment variables and are read directly instead!

So for now, the FreeAgent account is hardcoded.

FreeAgent OAuth tokens are refreshed with data pull down on a recurrent clockwork module task to keep the rails models updated! Asynchronously too because of the Sidekiq and Redis combination! No interruptions at all! Deployment and usage has continuous activity!

There was also the decision to diff our Remote Timeslips (FreeAgent populates this model) and diff our Days model on every sync too.

This was actually quite easy (algorithmic wise!), we assume that all Timeslips are up-to-date, therefore the Days model and its burnt hours attributes would be overwritten. Don’t overwrite if the burnt hour is already up-to-date; a comparison of updated-at or burnt hours values.

Leaving comments

Our BDD process is finally done; I’d like to mention again!

Another trick we setup DevOps wise was to start the phantomjs debug server in a docker container then run the cucumber tests, we now have console session logs stored! We can view those logs through the Phantomjs Web UI!

No more document writing on javascript error triggers!



Product Hunt Hackathon

by Jon Sharratt

Last weekend Product Hunt decided to host a global hackathon opening up their API to the community for consumption.  Budding developers got together over at YCombinator on-site for a two day hackathon to come up with and deliver a new product idea.  Remote entries were also allowed and across the globe from Hong Kong, France and our home town in London, plenty of fresh ideas were ready to be developed.

I applied on my own (a bit last minute) and with no real thought and put down the first idea that came to my head, ‘crowdsourcing for products’ via the product hunt API.  The main thing as a personal goal was to prove to the people over at YCombinator I could come up and deliver an idea over two days.  After a couple of days I got an email with an invite to participate, that was it I was ready to hack!

I got up Saturday morning and opened up the Badger HQ (a little hungover from the night before) to find Albert a fellow badger who had stayed the night on the sofa after having a few beers also with some of the other badgers the night before.  The tech I decided to use was a slight risk as I had only dabbled with it previously.  The tech chosen:

I began by using the basis of the project from what the Badger Academy Cubs have been creating for our own internal project of which they are doing a great job as you might of seen already.  Albert started to gain interest in the whole project idea and got setup.  Another great addition to the team a couple of hours later was  Viktor, a beast at LiveScript, just what we needed.  He saw on our companies Slack I was in the office and got involved.  This was it we had a great team to get this hack really moving.

We decided on getting the core functionality we wanted to show off to the judges done on Saturday.  Then on Sunday we would style it up and tweak the UI to make it a more usable and a nicer experience.  I had implemented the core layout using twitter bootstrap (http://getbootstrap.com/) with styling from a theme on Bootswatch (http://bootswatch.com).  Later Viktor informed us of an awesome library over at react bootstrap (http://react-bootstrap.github.io/) and converted the project so we could change the layout quickly and more effectively.


Product Fund Day 1


By the end of Saturday the project was taking shape with the huge help of Viktor and Albert.  Authentication done, Product Hunt API consumed and stripe checkout integrated to allow users to pledge money.  I had previously created a quick and dirty node.js passport (http://passportjs.org/) strategy to make the authentication process easier (https://github.com/allotropyio/passport-product-hunt).  So with all of that said it was time to call it a night ready for a fresh start on Sunday.

Sunday came along and all that was left to do was add validation to forms and finish off some of the advanced part of the journey such as supporting product makers having the ability to assign costs and a deadline for features to be funded.  Viktor also added the awesome firebase (https://www.firebase.com/) to add a storage layer for pledges and feature requests rather than it being stored in memory on the client.

Not only did it allow an easy way to implement a storage layer it also allowed the UI to live update when any pledges or features were added to the site.  It really helped make the site come alive and would made the site more engaging to users viewing the site.  I would say as a side note that the blend of React, LiveScript, Node and Firebase is just a match made in heaven for this kind of project (a blog post for another time).


On Sunday we were also joined by @jazlalli1 who worked in another team on a cool hack for Product Hunt taking their data to produce analytics and trends.

As the deadline approached our own lovely QA Roisi joined on Slack did some testing remotely which helped iron out a few creases.  Once we were pleased we were ready to submit the hack on challengepost.com.  We had created a droplet on digital ocean, registered the domain productfund.io and got it deployed and submitted on time.

Check out the final result on producthunt.com at http://www.producthunt.com/posts/product-fund

The next day we found out that we had made the top 20 finalists! we had some great feedback from the community.

We then waited to hear about the finalists and who had won.  Turns out our small idea made the top 3 hacks of the first ever Product Hunt hackathon.  All in all great job on everyones behalf for two days work.

The prize:

“The top 3 winners will receive guaranteed interviews with 500 Startups, Techstars, and office hours with YC partner and founder of Reddit, Alexis Ohanian!”

Just to add there were some great entries, checkout the other finalists at http://www.producthunt.com/e/product-hunt-hackathon-2014