Blog

Sidekick School + Inaura #2 - Revisiting the problem

Posted on 11th December 2012 by Ian Kynnersley -

The 3rd Sidekick School project is now about half-way through.

We're partnering with Inaura on a product that will help vulnerable and hard to manage kids and the services that work with them to help and educate them. If we get it right it has the potential to be life-changing for a lot of young people. 

If that wasn't enough of a challenge, the idea behind the Sidekick School programme is to help charities to build new forms of income not just new products and services. 

So the remit is a new software thing that is useful enough for people to want to use, beneficial to an under-served segment of society and valuable enough for someone to pay for. In 3 months. What could be simpler?

Asi has already written about some of our original ideas, hypotheses and research. Since then I have taken over running the project and we have started to build something.  

There are plenty of tools for schools to use to keep all their records on. But when it comes to those kids on the fringes of the education system they are spending their time at several different organisations in a given week, and there are no good tools out there to facilitate great cross-agency collaboration. 

This is a problem for several reasons. 

Firstly, it's bad for the kids. Each time they go somewhere new they have to tell their story all over again. This is often embarrassing or traumatic for them. They need an opportunity to build trust and earn respect of the teachers and professionals working with them and that can be seriously undermined if they have to regularly explain themselves.

Secondly, it's hard for the organisations that take the kids: the Pupil Referral Units and the Alternative Providers. They need to know the background as well as the up-to-date situation of a young person's condition, behaviour, academic progress and their home situation. They also have to show that they're doing a good job, delivering value, making a difference in a child's life and education. 

Thirdly it's bad for the school. They need reliable alternative providers that have proven their ability to manage and help difficult or in-need youngsters. They need to keep outside agencies updated on changes to a pupil's situation and similarly be kept up to date on all aspects of their off-site students' lives and achievements. This is now not only useful from an organisational perspective but, since September this year, essential for Ofsted compliance.

We think we might have cracked it. I will write a follow-up post over the next few days to explain our plan and how we will go about executing it, and validating all the assumptions it's based on.

Simplicity

Posted on 25th June 2012 by Ian Kynnersley -

Everyone loves simplicity. It's the heart of disruptive innovation.

If you're not the simplest solution, you're the target of one

(cf: Aaron Levie on Fast Company)

This all raises a question. What do we mean by simple? And simple for who?

I often talk about Sidekick using simple technology to try to tackle difficult problems. We also bandy around the phrase "just enough technology" to describe the things we build. We run short, delivery focussed projects that aim to do just that; use just enough simple technology to try and address a problem.

It's the Lean approach to business and the Agile approach to building software. It's also the simplest way to get something made. But simple for who? Ultimately this is simple for us. 

But isn't the important simplicity actually simplicity for the end user? And as anyone who's ever made anything knows, simplicity for the end user is one of the most difficult things to achieve. 

The real killers though are the systems that make genuinely difficult, complex processes easy. I've got so used to using Heroku that I've almost forgotten the pain and fear involved in directly deploying website updates. The value in BankSimple, Square and FreeAgent is in making the dauntingly complex world of money simple enough for anyone to understand. 

Solutions like this are defiantly not simple to make. They require an over-arching commitment to product simplicity that must inform every difficult decision when all the pressure is to take the simpler option for the team. They require an almost telepathic relationship between designers and developers. And they require the complete backing of those in charge of the money. 

This is far from easy for a team with limited resources. You have to keep both forms of simplicity alive at all times and be prepared to sacrifice features. The only way to deliver genuine simplicity is if everyone commits to the idea that it is overwhelmingly your most powerful feature.

Innovation of a browser (sort of)

Posted on 11th January 2012 by Ian Kynnersley -

There's a lot of talk in the studio at the moment about large organisations innovating like startups. For obvious reasons, large organisations often find it difficult to really innovate or disrupt themselves. Some address this issue by setting up R&D departments or Labs but these are often there to experiment with new ideas and come up with new products to compliment a company's existing portfolio rather than to disrupt a company's primary business.

It occurred to me today that Firefox is a great example of a large organisation innovating like a startup.

In 2002, Mozilla had the Mozilla Suite. They had inherited Netscape and turned it into the Mozilla Navigator which was the browser part of this monster suite of apps that was growing with every release and becoming increasingly bloated and slow. Hardly anyone used it.

A couple of employees decided to start again and created a stripped back, lightweight browser with the promise that each release would be smaller than the last and that only essential functionality would be built-in. And so Mozilla Phoenix was born. A tiny browser that paled in comparison to it's older brother but that was focussed on making browsing the web a pleasurable experience.

They stayed true to their word and within 18 months, after a brief stint as Firebird, Phoenix had become Mozilla Firefox. Each release was smaller than the last and - for a while at least - the core browser was completely stripped of unnecessary functionality. It was easy to install and ran incredibly quickly and could be extended through the use of 3rd party extensions.

Within 2 years, the Mozilla Foundation announced they were no longer supporting the Mozilla Suite in favour of Firefox (and the standalone email client Thunderbird which appeared shortly after Firefox). At this point, Microsoft Internet Explorer accounted for over 90% of internet traffic with Firefox less than 4%.

As at October 2011, IE accounts for just 34% and Firefox makes up 24%. Not only that, it is also directly responsible for the wholesale shift away from the idea that IE IS the internet, creating opportunities for competitive browsers to flourish and in turn for the internet to move forward.

These days, Mozilla IS Firefox. Obviously they do a whole load more stuff as well but it's their core product and their calling card. It's the thing they do.

Starting thoughts...

Posted on 11th September 2011 by Ian Kynnersley -

I have introduced myself before on this blog when I first got involved as a freelancer but recently I have accepted a permanent role here at Sidekick and so I thought I'd take the opportunity to say a little bit more about the company I'm joining and why I'm so excited to be a real part of the team.

If you've been keeping up with the blog, you'll know that there are a lot of changes afoot here in the way we work. These are, in part, a result of all the experimental projects we've started which have developed a life of their own but also because we're growing up and building a much greater understanding of who we are as a company.

One of the reasons I wanted to write about this stuff is because of a conversation I saw taking place on Twitter recently when lots of smart people at cool creative agencies were talking about how agencies should be talking less about making things and actually getting on with making them themselves. Interestingly, this mostly seems to just be talk at the moment.

However, we really are doing it, and maybe we should be talking more about it.

We're building real products for our clients and launching our own startups building products with strong social goals, one of which already has paying customers and is starting to make a difference to people's lives.

This is A BIG DEAL.

There are loads of new things to think about for a company that has historically been a pure design consultancy but that now owns products that have lives beyond the length of the project: product ownership, product development, support and maintenance, financial independence of startups vs in-house projects.

In addition to finding out how to run several companies within the same structure each with their own agenda, priorities and competing financial and resourcing requirements, we are already starting work on our new social incubator project that will take up a huge amount of the studio's time in the first half of next year.

So much change, so much to learn and master. Exciting times.

Decisions, decisions, decisions

Posted on 15th July 2011 by Ian Kynnersley -

As some of you may know, I make a living by making applications, sometimes web, sometimes iPhone, sometimes both together.

For the last couple of months I've been doing that here at Sidekick alongside the mighty talents of Nick Marsh, Jonathan Attenborough, Mat Ranson and Max Williams on a pretty cool client project.

As a developer I have spent my career making things which, as a general rule, have been "designed" by Business Analysts with little or no idea about design, users or most importantly fun. Over the last few years I have been introduced to the idea of design as it relates to the creation of a product or service and what it means to design something with the requirements of the user foremost in your mind.

On this project Sidekick had the foresight to get me involved during the vision stage where we talked to the client about what they do, what tools they currently have, what they like and dislike about them and where they saw this new product fitting in. We ran several workshops with them and started to sketch out what it was we were building and how it would address their needs and fit in with the way they worked. And how it would change the way they worked.

Developers are well used to being handed finished designs and asked to estimate and build them so it was really great to be part of the design process and even better to hear Nick saying things like, "that's why you need technical people involved in the design process".

There's a lot more to it than the input I was able to give during the design phase though which was highlighted at the point we brought a second developer, Max, into the team. By being involved in all the conversations around why a certain process should be a linear, multi-stage flow and why it was important to have a button here and not there, I already understood things that initially seemed arbitrary and unimportant to him.

This was when I realised how much I had picked up by being part of the process. There is huge power in having the people responsible for building a product involved in designing it. Partly because of what they can bring to the process and partly because it gives them a thorough understanding of what they're building not only in terms of detail but also scope. Have you ever worked on a technology project that overran its estimate? Were the developers involved in the design stage?

My conclusion is that it all comes down to decisions. Every part of a design is the result of a whole string of fleeting, seemingly unimportant decisions that aren't apparent once the design is finished or documented. Often the designer won't even realise they've made the decision. How can a developer seeing those designs for the first time really understand them?

So, is it reasonable or affordable to involve the dev team in the design of a project? If not, whose responsibility is it to educate the developers about all these important decisions? Is it actually more cost effective to have them involved all the way through than to have the designers involved throughout the build to flag up errors or misunderstandings once they've already been built?

I'm reminded of the Field Notes brand of notebooks whose slogan is "I'm not writing it down to remember it later, I'm writing it down to remember it now". The same is true of design documents. Their primary goal is to enable the designer to make sense of their design. Once they're handed over, even the most clearly annotated designs will not fully convey the process and the decisions that have gone into making them.