Nat Buckley There are lots of really nice things about the project in Mexico. What we did was collaborate with Smithery and Buró–Buró on delivering three days of workshops for the British Council. The whole project came about because in Mexico there’s a project called Laboratorio para la Ciudad (Laboratory for the City) where lots of small and medium-sized organisations do interesting bits of work about how to make life better in Mexico…
Dan Williams “What is the future of cities?”
Nat Yeah, and “How to get citizens to connect with the government”, “How to build your own the city”, “What spaces should look like”, and all sorts of really interesting design challenges. This was part of that larger project.
Dan What was this project called?
Nat Apps for the City.
Dan What kind of apps did they want?
Nat The Mexican government decided that children in Mexico needed a better chance at having a high-tech education, so they decided to give everybody of a certain age an Android tablet that they could use for school. But once they committed themselves to that idea, they realised that they would need software that would help kids use the hardware to its full potential.
The workshops that we were involved with were designed to take the existing expertise in Mexico and use it to come up with some ideas for what that software could look like and how it could be developed.
Dan So we didn’t sit down and design an app, or build an app ourselves.
Nat No. We served a dual role. Part of our role was to be the people with technical expertise who could answer questions. The other part of the role was, as designers/developers, to help facilitate the idea generation.
Dan To make sure everybody could contribute, and get it done in the timescale, with the right fidelity. Solving the right problems rather than getting software working.
Nat We were there to help facilitate the group, which consisted of Mexican teachers, some experts who specialised in pedagogy, and some PhD students. People whose work crosses over from education to technology and vice versa. They were paired with designers and developers who could lend a hand with implementing design processes and answered questions about the feasibility of certain things.
People were divided into groups, and collaboratively came up with a bunch of ideas for apps that they could prototype. Our role was helping people figure out what kinds of tools they could use, and what kinds of processes they could use, to make it quick and easy. We did a short presentation about what prototyping is for, what tools there are, and how to approach it. Then we spent time with each group in the room, helping them think about what they could do and how to make it happen.
Dan What kind of things did we do with them? They weren’t writing software.
Nat No, they weren’t writing software. It was mostly about encouraging them to not worry about what’s possible, because a lot of their ideas presented no technical challenges. It was all about trying to get them to put their ideas down on paper: write them down; sketch them; present different screens of the app on different pieces of paper that they could move around, shuffle, hang up on the wall and reassemble.
It was really about helping them to realise that sometimes sketching stuff out on paper is the most efficient prototyping method, especially when you work as a group. Once you put an idea down on paper you can talk about them with other people, you can show what you’re thinking and get a little bit of feedback.
Smithery are really good at facilitating groups to help them give one another really good feedback. By the end of the third day there were lots of contenders for apps that could feasibly be developed: they conformed to the curriculum, they were interesting and engaging, and they fitted with the ideas of the pedagogy best practices.
Nat The teachers in the room really took the lead, and they were just incredible. They were really engaged and really cared about making it a success, and I think that was the biggest contributor to how good the ideas were.
Dan They managed to bring all the different perspectives together. What was the end result, at the end of the week?
Nat The groups presented their prototypes to one another, and to a panel of judges. Some of the ideas were mocked up in a digital form, so there were clickable PDFs or short presentations that could be shared over the web with other people. Three of them were taken further to be developed, to see how difficult it would be to turn them into reality, with the aim of potentially getting some support to make one of them—or a few of them—real.
Dan The idea was that these workshops brought all the different bits of knowledge together in the room. That way when they do make something they make the right thing, instead of making the wrong thing and then showing all these experts later.
Nat With events like this is that there’s sometimes an expectation that working software will be delivered at the end. It’s very easy to get sidetracked and excited about the technology, and forget what it is that you’re trying to do.
Writing software at an early stage like that is sometimes a roadblock. You have somebody doing it who’s really focused on it, and the rest of the people who are participating — who can’t write software — are cut off from the really creative bit of the process.
The challenge is always to help people explore ideas really broadly first, and only once they’ve done that, to start honing in on the detail. Preventing people from writing software too soon is part of that.
Dan We’re software developers who tell you not to write software.