Designing around people’s lives to unlock sustainable growth

Posted by Isaac Pinnock and Micha Nicheva, Made by Many. Presented at the recent Playtime event in Amsterdam.

What does sustainable growth mean to you? This year’s buzzwords or a complete re-appreciation of how we design and build apps? Is it about making users fall in love with our apps so that they never leave? Or is it about stepping back and leaving engagement entirely up to them? The truth is — of course somewhere in the middle. To build a successful long term relationship with our users we have to carefully switch between holding on and letting go.

This article is about finding a balance between the two. Some of the techniques you may already be using, but are so valuable they’re worth repeating. Others may seem counterintuitive but are a powerful way to strengthen a relationship. We hope all are thought-provoking and will help you achieve meaningful engagement by adapting to people’s lives.

Earlier this year, Google Play approached Made by Many to create a toolkit that would help app developers unlock sustainable growth.

18 weeks later and after fieldwork in three markets (UK, US and South Korea) and across five app categories (Health & Wellbeing, Dating, Education, Entertainment and Social Media) our work has been turned into a presentation for Google Playtime and a series of e-learning modules in the Google Play Academy for App Success. Our full findings and recommendations can be found there and you can check out the talk here, but our highlights are discussed in this article.

Engagement on the user’s terms

As developers, we often imagine our apps at the heart of our user’s lives — there are no interruptions or distractions — from real life or from other apps.

We do this because we’re understandably proud of the things we build and see them single-mindedly. We need this focus to create, but we also need to take a step back to see the bigger picture.

This was a theme we heard over and over again in our fieldwork: whilst users may share common ambitions (e.g. learning a new language or getting fitter) the paths they use to get there are unique, as is the speed at which they progress. All motivations are different.

This means we need to build apps that work on the user’s terms. Let’s take the example of an app that helps you learn a new language. It helps users identify the overarching reason they want to learn. It then helps break up large tasks into smaller, regular actions (making these goals tangible) finally inviting them to set their own schedule.

Some apps do elements of this already, however, it’s often overlooked as these features are seen as ‘add-ons’ or, in the other extreme, things that might introduce too much friction.

The push to launch a minimum viable product and the desire to make experiences effortless are both important, however, to have a place in our user’s lives we have to give autonomy. This is the basis of healthy long-term relationships and sustainable growth.

This works because it helps our users translate ambitions into goals and then plot a route to get there. Secondly, easy and well-defined tasks are more likely to be completed and not overwhelm users.

And, finally, this is something that we kept hearing from the people we interviewed — they expect apps to adjust to their life-style and schedule, not the other way round. We need to give them both agency and flexibility to succeed.

Helping users get back on track

I’m sure we’ve all seen this — a user’s engagement falling off over time or suddenly stopping. It’s easy to assume that this is because a user has given up on their goals (or worse, that they’ve stopped liking our apps!).

The truth may be simpler: life got in the way. Often when we break a habit it’s because of an unexpected situation rather than a conscious choice. We encountered it many times in our interviews: an external event (such as a phone breaking or an impromptu night out) triggered the end of a habit.

Given that stuff happens, how do we help users get back on track? Often, we try to win back users through discounts or a heavier pace of notifications. However, as we heard in our interviews, we need to adapt to users — not the other way round.

So, what content can we create specifically for lapsed users? We tested, for example 2-minute language quizzes as opposed to 15-minute lessons, or 3-minute stretch routines rather than 30-minute workouts. Users saw these as a useful and compelling way to get back on track and back into a habit.

These bite-sized pieces of content can be so effective because they remove barriers or friction costs. Alternative content shows the user that the app can offer different ways to help them.

We found this to be very effective, especially when combined with notifications that used non-patronising and guilt-free language.

Disengage to re-engage

If it’s important to find ways to let your user’s get back on track, we discovered it’s even more important to let them take a break completely.

This sounds counter-intuitive. Normally, we chase maximum engagement or time in-app as a key metric. However, our fieldwork told us that trying to maximise usage can be damaging to the very idea of sustainable growth.

We must have confidence that once we’ve let a user go they’ll come back. We call it disengaging to re-engage. We tested the ability for users to ‘pause’ an app for a set period if they’re not able to keep up with it.

It’s a powerful concept that worked well with our interviewees. Yes, it overrides the badges, nudges, streaks, trophies and notifications we often use to keep people engaged. However, these were things that our cohort told us could be hugely de-motivational if they missed a session or received a reminder they couldn’t respond to.

Allowing people to dis-engage works because maximum engagement is unrealistic and unsustainable. The consequences can be harmful and unhealthy. We need to give our users a chance to take a break when they choose.

This means that users don’t need to feel demotivated by a line of zero’s and broken streaks. After all, missing a day doesn’t mean that the previous 30 days of continuous use didn’t happen. Our goals should be to celebrate progress and success — ultimately a far stronger motivator.

Acknowledging that our users are complex human beings with lives and commitments that they have to prioritise over app use is the cornerstone of a healthy and respectful relationship. One that can develop over time, which is what sustainable growth is all about.

Good product management enables sustainable growth

These may sound like simple features that are easy to apply. However, we’re not suggesting that you sprinkle sustainable functionality over your app — they need to be baked into and appreciated during the design and development process. Here are some best practices that particularly resonated with us throughout this project:

Understanding users

This often gets talked about but not everyone does it well. We rely on quant data (sign-ups, drop-offs, daily active users and so on) but numbers alone will never tell us why a user has made a decision. Qualitative research offers this depth of insight — talking to our users and understanding the reasons behind their behaviours. Using an iterative process to regularly meet our users needs and have our hypothesis explored and challenged allows us to re-risk our product roadmap instead of building the wrong thing.

Leveraging brand values

The definition of branding is often limited to logos, fonts and colours. But beyond that, the features we release and the tone of voice we use are a big part of it.

For example, when testing different disengage-to-re-engage options for the dating app Bumble we gathered some interesting results. When giving a reason for pausing the app users are able to select “I’m prioritising myself” — when this was presented attached to the original context and brand message, it was interpreted as empowering. When this was presented in more plain text however, users felt this was a selfish or negative thing to say.

Only building functionality that truly fits and reflects what our brand stands for is crucial, and the messaging around a new feature may be as decisive as the feature itself. What works for one brand may not work for another.

Communicating change

Whether it is a new feature or a design overhaul, telling our users why we have done it gets them on our side. They are less likely to resist change and won’t end up in a situation where their app has changed overnight. It’s about being transparent and avoiding the shock of the new.

The above example for Citymapper illustrates this perfectly. On the home screen a small banner unobtrusively informs users that there have been changes, and users can choose to view the changes in more detail on a separate page that explains them clearly, with pictures and a gentle tone of voice.

Conclusion

Growing in a sustainable way represents an amazing opportunity to have a long-term relationship with the people using our apps.

However, if our research has told us anything, it’s that it’s not a panacea for truly knowing our users or having a strong proposition, built well. Sure, there are tips and tricks to help us but people are different and apps should be too. In fact, differentiation is a compelling reason for a user to use one app over another.

It’s also taught us the importance of measuring the right stuff. We should constantly ask whether the industry’s standard metrics are right or relevant.

Finally, at the heart of sustainable growth is a healthy relationship with our users — one of mutual value. We have to ask ourselves — are we helping our user’s meet their goals or are we simply meeting our own financial targets? If it’s the latter, how long do we think a relationship like this can really last?

To dive further into this topic and test your knowledge, try the Sustainable Growth course on the Google Play Academy!

Want to know more?

This article is part of a series drawn from Playtime 2019. You can find the full list of presentations here.

Apps that fit was originally published in Google Play Apps & Games on Medium, where people are continuing the conversation by highlighting and responding to this story.

A computer you can throw

Hackaball was conceived and developed by Made by Many, and at the end of 2016 was shipped to more than 2,300 backers and buyers in 51 countries all around the world. An extraordinary hardware project (with a failure rate of less than one per cent) which continues to sell and has attracted interest from major toy companies, Hackaball has won awards, thrilled children, parents and schoolteachers, and fascinated everyone who’s come into contact with it. It’s been written about extensively, but now also seems like a natural moment to trace its story all the way back to the beginning, looking at how it evolved, the problems that arose and solutions that fixed them, and the meaning of this object.

There are also four big lessons for anyone looking to make a success of IoT hardware projects, namely:

1. The IoT is waiting to be built — but build it in a user-centric (instead of tech-centric) way. Involving users in design will lead to better products.
2. Among the most exciting IoT spaces is where science, learning and play meet.
3. To make something real, get realistic about manufacturing.
4. Hardware challenges that were Samsung-sized a decade ago can now be done by small organisations.

We’ll get into those lessons in this article, which is the first in a series of stories on the object. But first we’ll travel Hackaball’s development arc and learn from the people who imagined, made, tested, designed, redesigned, de-cludged, configured, reconfigured, backed and shipped it, about how this enigmatic object came to exist in its current bleeping, glowing, vibrating, connected, hackable, chuck-able form.

It’s no simple story because Hackaball is something radical and simple at the same time. Simple because human civilisation has known spherical objects for millennia: we’ve played with them, and kicked, rolled, thrown and caught them, and much of what we know as “sport” has evolved from games devised with the ball. And radical because as yet, no-one had ever connected one the internet, technologised it and simultaneously transformed into in a device for learning, play and computing simultaneously.

And doubly radical because today it’s Hackaball’s users (and kids in particular) who are reinventing the ways the ball is played with, learned from and used to hack the idea of fun itself.

2013: Reinventing the ball

When Ben King and Thomas Nadin began internships at Made by Many’s London studio in the summer of 2013, they were tasked with exploring the space where play meets the IoT. They hit on the idea of reinventing the most primitive, enduring and versatile of objects: the ball. Later that summer, creative technologist Melissa Coleman joins and the team, and work begin on building a prototype using a 3D printer and Arduino to create light, sounds and movement effects. This side-project would eventually have a tangible outcome — a spectacular, ground-breaking, genre-bending one. But in the beginning, what was the vision?

tim malbon, Made by Many co-founder: “We were simply trying to understand how to design software and hardware at the same time, to build a connected experience and device. At Made by Many we’ve never subscribed to the idea of big design or big strategy upfront, and we genuinely didn’t know what the answer would be. However, one thing we have done successfully in the past is to think about what the world will be like in the next year, or two or three years, when we’d wanted to learn how to develop things in touch, or how to develop apps and experiences for smartphones. In both cases, we initiated projects that taught us those skills the hard way: by doing. So in the beginning we didn’t even know this would be a ball.

“The prototypes were extremely low fidelity — at one point a sock filled with a Raspberry Pi and some wires was a prototype.”

Hackaball could have been that most necessary of as-yet-uninvented objects, a “smart sports cone”.

Ben King, former Made by Many intern: “The idea of ‘Hackaball’ came about after two weeks of the internship. We ran a workshop about inventing games with sensors, formed six ideas, and then [Made by Many-co-founder] Stuart Eccles sent us out to explain the ideas to parents and children.

“Hackaball — which was initially called ‘Rule Ball’ (left) — stood out. At the time we had another idea about smart sports cones. It turned out that a ball is more fun than a sports cone.”

Since balls are meant to be thrown and therefore need to be robust, throwability became the central concern in development: this one would contain fragile sensors, circuitry and components. Gradually the object was beginning to look like something that most would recognise as a ball.

Melissa Coleman, Made by Many technologist: “It was spherical, at least. It was becoming something that looked like a product. We wanted to be at a point where we could test it and see how people respond, but it was traumatising to user-test early versions with kids because they would treat it like a normal product when really it was breakable. The 3D-printed parts would crack all the time.

“Some products can have a much lower-fidelity prototype in order to get to that step, but unless this was a ball that you could throw around, it wasn’t going to work. We could do some work on the app and game creation but actually seeing how people responded to an interactive ball, we had to make a functional prototype. It had to be something that kids could really use and wouldn’t be afraid of breaking. I sometimes accidentally threw early prototypes of Hackaball off the stairs and mezzanine in the Made by Many studio when we were testing — quite a good test of robustness.”

The final Hackaball comprises an internal electronics unit encased in a two-part shell with silicon wrapper, and a lot of work went into protecting its fragile electronic brain.

A new language of play

In parallel work was started by Made by Many designers Alex Harding, Mike Walker and Owen Thomas on the wider design needs of Hackaball, inclduing the customer experiencce of receiving, constructing and playing with the ball, and the necessary branding, tone of voice and gameplay elements. Among the biggest challenges was building the accompanying app. If users (and young ones in particular) were to be able to program their own games, a simple new language would also have to be written. This posed a further set of challenges.

Tom Harding, Head of Design, Made by Many: “We’d set ourselves the brief of connecting an object to a phone, so an app was the logical place to control the ball. We also knew that we’d have a series of inputs and outputs to create games, and the simplest way to program for non-technical people is to break these down into logical steps using straightforward English words. We researched basic programming languages like Pascal, visual languages like VisualBasic, we looked at the mad libs system, and the ‘choose your own adventure’ books we used to read as kids. IFTTT was also a big inspiration as a way of creating something from a few simple actions.

“The goal was to design the two so they felt symbiotic. One way to achieve that was to have subtle sound and light sequences indicating that the app had connected or disconnected — like R2D2 or Wall-E coming online.

“Initially we had to send games over Bluetooth to the ball to play, and then see what the outputs were like. Having realtime feedback when creating games was a big improvement because it meant we could get a feeling for a game as we created it. Kids especially love cause-and-effect: my son, who’s a bit young for Hackaball, will spend hours just changing to colours or sounds in the app.

“Visually, we wanted the app to look like the ball and the ball to feel like something you’d expect to see in the app. A ‘space’ theme grew out of the interface — individual games look like a solar system and actions are planets in orbit.”

Hackaball was to stay in the research & development cycle for around a year as a wider supporting team — including designers, technologists, and strategists — coalesced around this intriguing object with its growing repertoire of bleeps, rumblings and buzzings. Games were written (the first included versions of playground staples such as Hot Potato), risk analyses undertaken and big questions asked. Was it a commercial idea, was it feasible in technology terms, was it viable for a company the size of Made by Many? “It wasn’t easy to answer those questions with low fidelity prototype, and it took ages to get a good fidelity prototype,” recalls Ben King.

2014: Why hardware is hard

Hackaball was slowly getting real, in particular through rounds of user testing with kids in school and playgrounds, the proof of its features and limitations evidenced in their grins and scowls respectively. However, if it wasn’t already obvious enough, 2014 brought the striking realisation (visible in the growing pile of broken 3D-printed husks, malfunctioning PCBs and dead LEDs particularly) that doing hardware is hard, and perhaps especially for studio specialised in software.

tim malbon: “We knew it was hard, but we didn’t know it was very, very, very hard, this new discipline of syncing hardware, industrial design and interaction design. Partly that’s because the cycle of iteration in software is almost real-time, whereas with hardware you’re dealing with atoms rather than bits. At the beginning we naively thought, ‘We’ll use our lean, prototype-powered, user-centric way of doing it, and that will help us to get to the right answer.’ But in hardware what can go wrong is much more unpredictable, and eventually we realised that we were never going to get to industrial design and production on our own.”

Which is why Made by Many approached the award-winning industrial designers Map Project Office and work began in earnest by Jon Marshall, Julie Arrivé and their team to evolve the object into something that could eventually be produced in a factory.

Jon Marshall: “Our first impressions were that this was a great product — and why hadn’t anyone already launched it? It was a perfect combination of harnessing kids’ love of technology with outdoor social play. We felt there was an opportunity through the industrial design to make Hackaball appeal to a wide range of ages, which led to us making it able to come apart to expose the computer inside, which could potentially be taken out and used in other projects.

“The main challenge was creating a soft shell to protect the delicate computer inside from active play. Made by Many needed support on making the casings, and making it bounce- and shock-proof. We knew we could solve that, but what also interested us were the sensorial aspects which didn’t fall into the traditional physical world: the sound and lighting behaviours. We always knew we could get Hackaball to bounce, but the sound and light were just as important in terms of experience.”

Mock-ups were duly made in foam, card, drawing pins, elastic bands and lots of cut-up acrylic balls, with later models being constructed using 3D printing and vacuum casting. MAP suspended the ball’s internal electronics into a shockproof ring made from ABS and TPE plastics, and split the ball into two hemispheres fabricated in polypropylene, with a silicone outer sleeve to hold the assembly together.

Hackaball was beginning to look more and more real, viable, desirable and magical: a ball in name and form, but also much more than that: one with its own language of lights, sounds and vibrations.

Increasingly, Hackaball began to look not only feasible, but too good to avoid committing to.

But the question remained: how to make it really real?

William Owen, Made by Many co-founder: “at that point we were looking at three possible routes to take Hackaball from an early concept or working prototype to something that was ready for manufacturing. One was to go with a consulting company who would have taken around 25 to 30 per cent of the profits. Another was to work with a company to supply us with electronic component design and design, all for a fee which would have been very high. The third was to sell it to a toy company under licence. The first two options were too expensive and we weren’t very keen on the licence option — the danger was that we could sell the licence and then nothing would happen with it, which is often the case.

“‘So for a while we did nothing, thinking, ‘This isn’t possible; we should leave it’. That was until the idea of a Kickstarter arose: it kicked us into thinking we could take this to market.”

In the interim, however, there was still plenty of work to be done. In Made by Many studios streams of work continued on the app, firmware, hardware and industrial design, along with brand thinking and strategy. Working in Objective C and later Swift, Made by Many iOS developer Julian James picked up development of the app which pairs with Hackaball to enable owners to play games or hack the simple, code-like language of rules to make their own.

Julian James: “The app had the basic idea of If/Then rules, which we called Whens and Thens — and a way of laying them out. Next we had to map this user interface onto the new firmware, which itself was quite different from the prototype firmware. We also thought about how we represented the games themselves on the home view screen: the idea of having the nodes came in, with lines joining to another node, and so on; these nodes were the “Whens”. Around the edge of a node you have up to six of the “Thens” — for example, to make a noise, or flash a certain colour, little icons illustrating what each step does. All this was an evolution — an original idea taken and mapped onto what is actually in the app. We went back and forth between the app and the firmware.”

2015: Looking for the meaning of Hackaball

By the beginning of 2015 Hackaball had been through many iterations, and a certain atmosphere of introspection alighted on the project: the Fog of Innovation, we might call it. After round upon round of user testing, prototyping and head-scratching, the questions nevertheless came into greater relief: what could Hackaball do, become or achieve? What was this object’s real purpose in that perennially misunderstood dimension, the IoT?

What could Hackaball really mean?

When Kickstarter curtain call came on March 3 2015, it took Hackaball just 23 days to break its target of raising $100,000, in addition to almost breaking Kickstarter itself: Hackaball was launched at the same time as a new Pebble product, and Kickstarter.com briefly went down. Hackaball was also made Kickstarter design project of the week and by the end of its month-long campaign, Hackaball had attracted a staggering $241,122 from 2,312 backers spread across the world (read about how we ran the Kickstarter campaign here).

But investment wasn’t the only result of the successful campaign. Kickstarter would also help validate the project, establish a supporting community, and soliciting feedback from the world beyond the Made by Many studio. The process also illuminated two important insights:

William Owen: “The first was the reaction from people who’d launched similar products before — we got a universal appreciation from them that Hackaball was a much more mature product than most in terms of its hardware design, form factor, app and hardware design. And it had been very, very thoroughly tested with children and we’d brought in a very good hardware design company.

“The other thing it illustrated was the chasm that exists between a product that looks very mature and is ready for Kickstarter, and a product that’s fit for production. These are very, very different things. We were ahead of ourselves in one sense, yet nobody told us about quite how hard it would be and it was partly because of a severe lack of electronic engineering and firmware skills in the UK.”

On the nature of fun

Meanwhile, as public awareness and interest in Hackaball was growing, its supporting philosophy was also coming into sharper resolution through the rigours of learning while playing, testing and retesting, breaking and building, watching, listening and tinkering —being seriously scientific in the pursuit of fun. Which is how it eventually transpired that fun itself could be Hackaball’s grand narrative.

Melissa Coleman: “the product development process was about listening to feedback and adjusting our ideas based on that. We were making a modular product that people could mould into their own thing — some kids might use Hackaball for storytelling, others for playing active games. Hackaball was always intended that way, but in our heads we had very static games with the classical structure of a beginning, middle and end, and very clear rules of how to get from one to the other.”

“What we realised is that kids like stuff that is just fun. It doesn’t really matter how you get there because they decide what’s fun. They might come up with really crazy rules and as an adult I might say, “That’s not a game.” But the kids are like, “Oh no, that’s definitely a game.” So if something the kids make is about having fun, then who am I to judge? It’s mistake to assume: they are the judges of what’s fun.”

Hence Hackaball may been intended one way, but its truth was emerging in the way it could be hacked into something else: an alternative, kids-eye view on what fun could be, along with a direct, hands-on feeling of making and remaking the interactions with this most fun of objects.

Melissa Coleman:“Hacking is like coding without permission. It’s more naughty — and more and more that became our philosophy around Hackaball: a physical product that’s broken when you get it and you have to build it. Putting Hackaball back together is part of the user experience. It’s not this pristine product that you cannot touch.”

Observations such as these were as disruptive as they were enlightening, and they led to the realisation that the Hack as much as the Ball was what made Hackaball unique.

tim malbon: “earlier in the process there had been some much more focused propositions based on becoming fit or learning certain skills, but later we wanted the broadest possible concept, and a ball with some very simple rules that could be co-opted to do anything at all. The missing bit that we learned as we went along, was that hackable space: in the concept that allows the child to insert their own imagination, and to turn something that’s just “a ball” into a golden egg, or something that a dragon owns, or something extremely dangerous, rare, or whatever. We learned not to overdesign it. It’s surprising what kids really want to play with: pots and pans, wooden spoons, stuff in the kitchen. They want to use their imaginations on the stuff that you might think is really boring.”

2016: Getting really real

There were setbacks — plenty of them — and achieving the project to the satisfaction of those 2,312 backers wouldn’t be without its intricacies. To overcome them Made by Many had partnered with an agency in the Shenzhen region of China to manage the manufacture of Hackaball, but a further working prototype had to be developed.

Throughout 2016 activity focused on redesigning the electronics board, writing the bill of materials and functional spec while the industrial design, brand design and packaging finished were finessed further still. “Visually Hackaball looked like the same product as it had been,” recalls Melissa Coleman, “but its guts were very different: different hardware and different firmware.” For several months the Hackaball team were in close liaison with China over firmware releases but on August 26 2016, Hackaball was sent into production.

In Shenzhen the production lines went into action, the machines turned for a few days… and Hackaball was finally real.

Soon after, the first batch of Hackaballs arrived into the Made by Many studio where QA specialist Jamie Mayes ironed out the final bugs in the system and updated the firmware. The failure rate proved to be astonishingly low: just 0.59 per cent, against an industry standard of 10 per cent.

Hackaball was ready to go, but shipping it around the world wasn’t to be without complications: it meant synchronising a range of technologies — logistics, backer, pre-order and payments systems among them — to deliver Hackaballs into the hands of patient fans. It’s an endeavour that looks simple on paper, yet in Hackaball’s case proved to be complex, time-consuming and at times frustrating.

Matt Williams, Made by Many: “The clever way to work out the best way of shipping would be to test it on a really small scale: buy a box of something that’s a similar weight and size on eBay, ship them to your shipping partner, and then get them shipped to friends around the world. Work out what the best way to do it is, and of using bulk data as opposed to individual orders. Then see how it fits with your other processes and software, such as Celery for pre-orders, Stripe for payments, and Kickstarter for backer information. Getting data in and out of any shipping systems can be problematic, and you need access to support 24/7. Choose a provider based on the quality of documentation the website, the ease of input of data into the system, and the availability of support in your own timezone.”

2017: Hack to the future

Despite the complexities of shipping, Hackaball was out in the world and in the hands of backers by the time Christmas 2016 and New Year’s Day 2017 arrived. Delighted reactions were coming in (see the full story here): “Great unboxing experience. It’s alive! Thank you, @hackaball” said @ybakos. “We are acting like a couple of kids excited to try out this…” added pyuan of Silicon Vallet. Darrell Whitelaw was “stoked” for delivery day. “Thanks for making something rad Made by Many friends,” he went on. @ollylazbot coined the hashtag #moreexcitedthanagrownmanshouldbe to describe his feelings at the arrival of Hackaball, while @Miss_Birkbeck from the Penn State College of Education straightway took Hackaball to the place where it will probably mean the most: the classroom.

It was also instructive for members of the Hackaball team to cast back over the last three and a half years and consider how they object in front of them met with their visions back in 2013.

“Looking back from the very initial idea, Hackaball has changed a lot, says Ben King. “Very organically it came out of a first idea through iterating our prototypes and testing them with kids. We never shaped the idea so to be educational, it was about creating the most fun thing possible.”

“Hackaball looks simple, but is very complex,” adds Julian James. ‘It’s not just a multicoloured light bulb, and it’s deceptively simple. Hackaball shows how you can pull a lot of disparate parts together into a whole that actually works and if you can do it for a ball, you can do it for all kinds of stuff. But it’s been hard work.”

In the Made by Many studio, a period of reflection on this endeavour so far seems natural. Considering its uncertain genesis, the almost endless round of iterations, the complexities and intricacies of designing in the gaps between software and hardware, there have been some big lessons that any organisation thinking of embarking on hardware project could learn from:

1. The IoT is waiting to be built, and almost anyone can do it

tim malbon: “we know that many more objects will to have a degree of connectivity in them and talk to the internet, but which don’t look like phones or computers anymore. These objects that are going to surround us, and there’s a whole range of experiences that need to be worked out to make our interactions with them useful and natural. We were only going to learn how difficult these things are and how to get round those difficulties by actually doing it.

“What’s also exciting about Hackaball is the way you can reinvent the value that something has — an object like a ball. There’s an invisible layer of value that you can build on top of it. Balls are used to keep people fit, they’re used to teach people, Isaac Newton conceptualised gravity when a ball-shaped fruit fell on his head. Balls are really, really important to the way we think. So if we can connect them to a lot of the other intelligence and knowledge that we have, and the ability to measure and understand and model those kinds of things that make us human, then we can make those objects even more valuable, and that’s pretty exciting.”

2. There’s ground to be broken in the space where products combine science, learning and play

Melissa Coleman: “when you consider the Arduino and other modular electronics aimed at beginners, products that are aimed specifically at young people are generally very good for creativity and promoting science but as much as kids might have fun with them, it’s quite hard to make something of high quality. Hackaball is such a complete product that anything you do with it will be just as attractive, yet it still gives you the space for making. In that sense it’s a product that we haven’t seen much of yet. It has the quality of a gadget where you think, Oh I want it, it’s beautiful, but that’s just like the beginning of it: it’s not what it becomes. You build a different relationship with it through using it. It’s about how willing you are to dive into the guts of it.”

3. The “Fourth Industrial Revolution” is real, but companies need to get real about the process

Among the most important — if not the most important — aspects of running a project such as Hackball is the relationship with manufacturers in China: building the relationship, being on the ground, solving problems. Effort applied early in the relationship will pay off in the quality of the final product.

4. What would have been an Apple- or Samsung-sized problem a decade ago is today achieveable by a small-to-medium sized organisations

William Owen “What’s most remarkable about Hackaball is that would have been regarded as extraordinary 10 years ago for an agency the size of Made by Many — a mix of 40 product strategists, technologists and interaction designers — to have brought a product of this complexity to market. It’s not so extraordinary today. Nonetheless there are very few things around which can touch Hackaball in terms of coding, interactions, robustness, and wonderment for children in the toy and education market. It’s been hugely successful as a demonstration that you can take products like this to market at relatively low cost. Similarly, the quality of hardware and software a real testimony to made by Many’s test procedures, as well as to our Chinese partners’.

“What the project proves above all is that the research and development required to get a product like Hackaball from conception to market-ready product is in the realms of what a small-to-medium-sized enterprise can afford today. Once it would have been an Apple- or Samsung-sized problem. No longer.”

Text: Kevin Braddock

Facts & Figures

Hardware failure rate: 0.57 per cent
What Hackaball could have been if it wasn’t a ball: a “smart sports cone”
Downloads from the App store: 4,000 (and counting)
Number of Kids who played with Hackaball in testing: 354
No. of different factories used in manufacturing: 4
No. of kilobytes on Hackaball’s electronics board (housing games instructions, audio files, look-up tables etc): 32
No of countries shipped to: 51
Clients won by Made by Many as a result of Hackaball: 3

The prizes Hackaball won:

Best Inventions 2015, Time
Best In Book, Digital Category, 2015, Creative Review
Best of CES 2015, Engadget
Lovie Awards 2015, Connected Products
Lovie Awards 2015, Family & Kids
Core 77 Award, 2015
Gold IxDA Awards 2015 (runner-up)
Finalist, Fast Company Innovation By Design, 2015
Most Engaging UX For digital Education, Gold, User Experience Awards 2015
Design For Experience Award, 2014

Good Vibrations: was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

An end-of-year listicle in the form of an A-to-Z which, coincidentally, has 26 letters. Hence, 26 things done, said or made by Made by Many this most weird of years (*not all of them are objects):

A is for Abracademy

Rubens Filho’s magic startup has been embedded in our studios for most of the year. We’ve been learning tricks and our clients have enjoyed sleight-of-hand, prestidigitation and conjuring. Abracademy’s Big Hairy Goal is “to bring more magic to the world” which, given the general tenor of 2016, can only be admired. Buy some of Abracademy’s brilliant e-learning courses here, and follow them here.

B is for Bloop

Because side projects show what we can do without the restraints of a client brief. This year we built Bloop to create a new and more positive way of maintaining healthy control of diabetes. This free iPhone app enables people with diabetes to share blood readings with a friend, parent or trusted guardian. Find out more or sign up for the pilot at www.bloophealth.com

C is for Caravaggio

The exhibition that’s been on show at the National Portrait Gallery is worth seeing, since it reminds us how lessons from the history of art remain relevant in this ever-accelerating digi-present. Earlier this year co-founder Isaac Pinnock wrote this piece on how the Renaissance technique of chiaroscuro can be applied in contemporary design practice. (PS: the exhibition runs until January 15 2017).

D is for Digital Transformation

Disruption is happening. It’s real, it’s accelerating and businesses need to respond by meeting it with transformation. Yet no-one, it seems, knows what digital transformation really means. Here’s one way to think about it, from tim malbon’s story on the subject: “the most important change is one that happens within us — inside us as individuals, and inside the teams and businesses we work for.”
We’ll be focusing closer on helping organisations with their transformational journeys in 2017.

E is for Empathy

It’s important, in our work as designers as in our relationship as humans. We visited The Conference in Malmö in Summer, where empathy emerged as a central theme. But is it being misunderstood and misapplied? As “Big Empathy” is fast becoming A Thing, our in-house storyteller Kevin Braddock thinks so. Om Malik has also suggested that Silicon Valley “has an empathy vaccum”.
Here’s to actual as (opposed to fake) empathy in 2017.

F is for Fireworks

Every year we buy the biggest ones we can find, then go to a beach, drink beer, cook food, and and let them off.
Because explosions.

F is also for FEL

Also known as Front End London, where this year we heard talks on Voice UIs, HTTP/2 , CSS in JS, the Art Of Redux, IndexedDB, writing secure Node.js code and plenty more. Sign up for further tech-tastic meetups in 2017.js

G is for Games

Next year at Made by Many we plan to launch:

• A Segway for orchestras.
• An Uber for vending machines.
• A Skype for waiters.
• A Bitcoin for running.
And
• And a Foursquare for underwear.

Only joking; it’s just a game. But these are the kind of new business ideas that can be generated with Pitchdeck, the strategy tool-cum-card game we published earlier in the year. It is a fun way to encourage clients to think like startups, and even more fun game to play down the pub. (We’ve sold out of copies, though. Sorry).

H is for Hackaball

Our multi-awardwinning, first-of-its-kind, Kickstarter target-busting hardware project: a throwable computer, a connected toy, and an IoT way to teach kids the principles of coding, all in one. Hackaball is so clever, unique and valuable as a learning project that’s its already inspired imitators. Hackaballs are now shipped to backers (read what they have to say here) and are being unboxed. We’ll be publishing some great stories about the making of this spectacular object in early 2017.

I is for Innovation Labs

We published two reports on this vexed topic this year. Vexed, how? Because plenty of companies are running innovation labs, but no-one has quite formulated the secret sauce just yet. In Volume 1, “Asking the Big Questions about Innovation Labs”, we do just that, while in Volume two we offer the state of the art in innovation labs Best Practice. Download them here and here.

J is for Joy

Because the combination of design and technology can create it, but it’s easy to forget that fact.

K is for DJ Klassic

A friend of ours who often works in our office, who is also a junglist DJ. There’s more to life than work, after all…

L is for Levelling

On #EqualPayDay this year, our Director Of People and Happiness, CharlotteHillenbrand wrote this persuasive piece on the levelling potential of digital. On this issue as well as on the related topic of diversity we’ll be redoubling our efforts in 2017, but there’s something else to announce: Made by Many now offers employees four weeks’ paternity leave (versus the statutory one to two) and 19 weeks’ additional maternity pay.
We’re proud to say that we go above and beyond the minimum requirement.

M is for Minds@Work and Mental Health

Speaking of inclusion, Minds@Work Movement began a year ago here in the Made by Many studio as a meetup of 12 people with a shared vision to destigmatise mental illness in the workplace, and now it’s making headlines on the BBC, Telegraph and elsewhere, and will be going on the road nationally and internationally in 2017.
Want to get involved? You’ll be in good company: Minds@Work now has over 300 members active in speaking out about mental illness. Meanwhile in the spirit of openness, there’s also this brave tale by designer Sam Small on how he treated his own mental health problem.

N is for saying No

Regularly, often, firmly, on principle. And then sticking to “no,”

O is for Obsessions

They’re what make us human. Obsessions shared by people at Made by Many this year include, but are by no means limited to, split peas, Spitfires, aniseed balls, submarines, growing crystals, The KLF, porcelain, mid-century modern furniture, facial care, Iceland, the Icelandic alphabet (and the letter œŧħ or “ð” in particular), the books of Alan Watts, learning the violin, open-water-swimming, Diet Coke, bagel-cutting devices, Alpine and Pyrénéen cols, modern coffee techniques, mountaineering, the mechanisms of evolution, seaside shacks, Karl Ove Knausgaard… and many more. We plan to stay obsessive in 2017.

P is for Problems

In 2016 we did a lot of thinking about Design Thinking, about its limitations and about why, maybe (probably) we need “full stack design thinking” instead. Co-founder tim malbon wrote about “The Problem With Design Thinking” and then offered “The Solution To Design Thinking.”

What’s the solution? Making stuff:

PS: we like problems. Get in touch if you think we can help solve yours.

Q is for The Lone QA!

There is a man who sits in the corner of our studio who lifts weights every morning, can make a mean cocktail, and leads the Quality Assurance practice here. His name is Jamie and he is The Lone QA! Read about his expeditions deep into the machine here and here.

R is for Regent’s Canal

Still the best canal in north-east London next to which to have a studio in a former marble factory.

Here’s the view in summer (left).

Pretty innit?

S is for Sketching

Where design begins, and the skill no designer can work without. Downloads some tools from Tom White here, and consider Adam Morris’s evolution of the sketch here.

T is for Travel Booking

The way we do it is broken, and this year we’ve been involved trying to fix it with Finnair, among other clients. Our resident globetrotting travel expert, Fiona McLaren, explained the problem succinctly here.
We look forward to solving it in 2017.

T is also for Ten: really unfortunate things from 2016

•“Brainstorm island”
• Empathy as a Service
• Tay
• Airpods
• Brexit
• The Fellatio Café
• Mulled Spice Scented toilet paper (NB: might be fake)
• Seeing people fall into the canal
• Fake news
• Trying to appear cool by writing your name in the Metallica font:

U is for User

Who we’re doing all this for, and thinking about how to relate to them as a therapist might relate to a client: inquisitively, empathically, respectfully. We published some guidance here, by way of Carl Rogers.

V is for the Victoria And Albert Museum

The client with whom we made a major change in the way a modern cultural institution can build and manage its own digital channels. Did we mention that the work we did for the V&A won an IDCA award? Find out more here and here.

W is for the World Economic Forum

The client for whom we delivered a high-performance, responsive new website and a powerful bespoke content management system in the run up to the organisation’s key event in Davos — an adaptive and modern digital platform fit for its diverse global audience. Take look at it here, and read the story of how we built it here.

X is for “Exactly what is it that you do again?”

A question perennially asked of product managers, often in a pub, bar or club late at night, to which Fiona McLaren (one of Made by Many’s PMs) gave a thumping good answer in her talk at Front End London.
Includes “the triangle of ambiguity” :

Watch the talk here.

Y is for “Yes”

A contender for Most Popular Laptop Sticker Of The Year, 2016, thanks to a consignment from Wasted German Youth.

Z is for ZZ Top’s “Gimme All Your Lovin’”

While we eagerly await the EDM, dubset or grime remix of this classic rock song, the original mixes well into house and disco music, and was one of the standout tracks at our summer party on Bermondsey Street. See you on the dancefloor next summer?

Enough 2016, bring on 2017!

Merry Christmas and Happy New year from Made by Many.

AND ONE LAST THING

Made by Many’s history of 2016 in 26 objects* was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week we publish the second of our reports into innovation labs. While the last volume looked at the big questions facing these entities — the Why, What and Where — this one presents a broader collection of contemporary best-practice knowledge, gathered from our discussions with people who’ve been at the sharp end of this fast-evolving business sector

The volume also includes an essay outlining our own experiences in the field, and a series of experiments which, we believe, would enable anyone running an innovation lab to learn a huge amount in a short space of time.

Innovation labs remain a hot topic in business, and in the course of compiling this report we’ve discovered plenty of valuable insights and data: we’ve found our where the blockers to innovation are, what innovation lab talent looks like (and how to manage it), how to integrate with the sponsor organisation, and why innovation labs are to business what sci-fi is to literature. Above all, and perhaps most valuably, we’ve defined the key reasons why innovation labs fail… and what to do about it.

As with our last volume we present this in the spirit of enquiry and knowledge-sharing. After all, a hard-and-fast formula for running an innovation lab which can successfully scale products has yet to be defined, but we believe this report will bring it one step closer.

To receive a copy fill in the link at the bottom of this page in the link below, and get in contact with us if you have thoughts or experiences to share.

Innovation labs: best practice was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

Magic was the once privilege of only a few. But when the world is full of sorrow, anxiety, violence and loneliness, we can’t afford this privilege anymore — we need more magic.

Abracademy is a school of magic that was created with that goal in mind: to bring more magic to the world. A kind of magic beyond rabbits and hats: with power to help people and teams to grow. More participatory, inclusive and collaborative. The secret to this kind of magic is that it starts with each of us.

Impossible? Well, not for magicians.

Abracademy teaches magic to businesses and children to help them become extraordinary, or as we love to say: teach someone to do do magic, and they can make anything magical. How do we do it? We teach hands-on, experiential learning. A different type of wisdom can come from the ability to keep trying and reflecting after each experience, and that’s why practicing magic is a perfect medium for learning experiences.

So what can magic do for you? Plenty — here are a few examples:

Magic for Creativity

Almost instantly magic can conjure a creative mindset: creativity is the ability to see a situation in a brand new way by imaginatively combining ideas and objects into different entities. Magic can be instrumental in opening the mind. The process of inventing new tricks and performing magic is all about innovation — an iterative and experimental method of problem solving.

Magic can stimulate new ways of thinking and problem solving: magic brings with it a deep and rich collection of resources that aren’t readily accessible to most people, centuries old knowledge on suggestion, conviction and meaning. Seeing the world through the magician’s eyes can make you think about new approaches and unique solutions to old challenges.

Magic means dual-reality thinking: when you think about how an audience sees a mind magic trick and how you are performing it, you are engaging in dual-reality thinking. The magic mindset is smart and abstract, and draws on human psychology. It gives people from diverse backgrounds and disciplines a rare opportunity to observe a different style of thinking. Magic is about appreciating the marvels of the mind itself, regardless of what has been put into it in the past.

Magic for team-building

Magic has the power to reveal hidden connections in teams and enhance communication skills. It helps individuals flourish and teams create synergies that they can take back into the workplace to create real change. Participants come away with skills to communicate more effectively, engage their imaginations more readily, and approach their work with a newfound sense of awareness. Using magic in teambuilding can help colleagues develop trust, inspire them to try something out of the comfort zone, boost their morale and above all, leave them with the magic mindset: belief!

Magic for presentation skills

Magic can, in a unique way, help you understand your whole self and teach how to use the magician’s tools for making a magic moment. The hands, eyes, body, voice, and attitude. It also explores differents ways of listening to your audience and connecting with them, from empathy to improvisation to storytelling. Create an atmosphere around these skills and build a good personality, and you’ll quickly see how powerful you can be on any talk, presentation or stage.

Magic can grab and hold attention: simple mind magic tricks, performed in meetings, pitches or anywhere else, can grab people’s interest and stimulate curiosity in who you are and what you do. We are fascinated by things we’re uncertain about, so when you perform the impossible for people, it stimulates something deep that can’t help but attract others. Magic can help people overcome fears, such as the anxiety of public speaking. It can also teach the powerful mysteries of body language, and help you detect if someone is feeling discomfort or pleasure, or even trying to deceive you.

Magic for you

Magic fascinates every one of us: we love to watch mind-bending performances and search for rational answers for impossible questions. But that’s just part the story. Magic can work best when it’s something you do, instead of just watch. We can all benefit from its secrets and techniques.

It can be a great self-esteem builder because the necessity of controlling both trick process and the audience reaction transforms magicians into people who can deal with the unexpected and complex problems.

It builds confidence too: at Abracademy we give people the opportunity to become the owners of their learning process. We teach techniques and behaviours that generate a virtuous spiral of growth through reflecting on performances, feeding back and sharing thoughts. This empowers makers of magic to follow their own journey and never stop improving.

Magic only exists when there is a magician and an audience, which means that being in constant contact with others makes magicians experts in creating connection with people. How to relate, how to “read” an audience, how to actively listen and how to powerfully speak. If you want to improve communication skills you can hardly beat magic.

Those are some of the reasons why we at Abracademy believe magic should be for everyone. If you want to find out more — or experience some magic yourself, or in your business or school — drop us a line at rubens@abracademy.com.

This post first appeared here.

Magic for you was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being a QA professional can be quite difficult and stressful, particularly when you’re stretched across multiple projects. Some experts say it’s not possible to effectively QA multiple projects — but I disagree. I find working across multiple projects a great challenge, but thanks to agile development techniques, I find it entirely possible. Here’s how to do it.

By Jamie Mayes.

Work your tracking tool

First, you’ll need a project management/bug tracking tool. At Made by Many we use Jira, which is my bible for every project I QA: it gives me a quick snapshot of what state the project is in and what features/bugs need to be QA’d. Jira (or whatever tool suits your team) needs to be set up correctly, and most importantly, you need to have buy-in from the whole development team so that it is used consistently.

At Made by Many we also use an agile workflow to do planning, estimation and so on. Our Jira board is broken down into sprints, and the tickets are organised within the sprint board. Our Jira board consists of “To Do”, “In Progress”, “In PR”, “QA” and “Done” columns. Naturally, features and bugs don’t land in the QA column unless the developers are confident that the acceptance criteria of the tickets have been met. What also aids this is developers “pull requesting” their code. This enables other developers — who may not even be working on the project — to cast their eyes over the code to ensure it doesn’t contain any glaringly obvious bugs before it gets to QA.

Also, and this is probably going to cause a stir but… forget about writing test cases and scripts! Why? Because test cases are not the same as performing QA. Using the product, operating it, observing it and evaluating it — that is performing QA.

Watch the clock

Now, timebox your QA time on certain features. Some call this “session-based QA”. This is usually about 90 minutes on a certain feature or bug. Also ensure you are not interrupted in this time. Document your findings — I use my notebook to document what I’ve tested; sometimes I just jot down simple flow diagrams of what I’m thinking. This is important in case you need to revisit a certain feature.

There will also be lulls which occur on every project where you are, for example, waiting for a build. This gives the QA time to move on to a different project, and it also serves as a reset for your brain and memory. Focusing too much on one item can cause a QA engineer to become too familiar with the feature they are testing and therefore become blind to potential issues. If QA is blocked for any reason — which can happen — this is a great opportunity to rethink and go over your testing strategy to ensure that QA has captured most issues and covered most scenarios.

Explore, explore, explore

As I mentioned, I use Jira as my bible: this is the foundation from which to start the QA process on a particular feature. This enables the QA engineer to do lots of exploratory scenario testing, giving them the freedom to think of realistic user behaviour and create multiple scenarios.

QA is almost like a heuristic search — by which I mean that there is no sure way to find what you’re looking for, and no optimal way of searching for it. To be a QA you must indulge your curiosity, open your mind to playing with a product, and open yourself to the unexpected. Without this as a QA engineer, you almost become a robot and a lot less like a human interacting with the product as a human would. No single person will use the product in the same way, whereas a robot will always be predictable and use the easiest path.

Stick close to the development team

This is hugely important and powerful: by being in and amongst the developers that you are working alongside, they are able to see any issues and bugs first-hand without the need for bug reports and replication steps. That’s not saying you shouldn’t write bug reports — you should! — but if a developer can see first-hand what the issue is, this acts as the best form of bug report. Sometimes developers can fix the issue immediately, which aids the velocity of a project. This is also the case with designers being in close proximity: it allows the QA to voice concerns regarding any small design changes, which can add a lot of work for QA to get through.

In the end, remember: you may be the lone QA, but you’re not the gatekeeper to quality. You are part of a team which — using the above techniques — is responsible for ensuring the product is of a high standard from start to finish.

To the lone QA!

How to survive as a lone QA engineer was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Jamie Mayes.

Economic theory suggest that people are rational — the reality is, however, that they are not, which is probably why economists are so often wrong. In fact, people are predictably irrational, following thought processes and actions that can usually only be understood by another human being, albeit an empathetic one.

Traditional software testing processes have often fundamentally misunderstood people and the needs of testing. By approaching it as a tick-box exercise that follows repetitive and set user paths, they assume a level of rational predictability that is rarely present in human behaviour. Technical tests, especially those that are automated, don’t replicate the desire of users to click where they’re not supposed to, and can’t accommodate irrational human behaviours. In other words, the more structured and logical we are, the more likely it is that we will miss the opportunity to improve usability and remove the bugs that actually impact real users.

Of course, technical testing should be used as a hygiene factor during product development, but it needs to be supplemented by an empathetic and realistic approach to the user experience. In other words, Quality Assurance, and a QA expert to act as a user champion by injecting some irrational realism into the development process.

That might sound blindingly obvious, but it is often missing in development processes. What follows here are some of the ways we think about the differences between testing and the more powerful QA:

Being Conscious Of The Irrational

Testing treats users as a single, homogenous group but QA adopts different user personas in its process.
Users are varied and have differing needs and demands. A robust QA process will use a variety of user personas and groups but a mechanical, logic-driven process is incapable of doing so.

Starting QA At The Beginning

Testing is the last step in the development process, whereas QA runs throughout it.
Here at Made by Many QA involvement in the first stages of concept development means it can create expectations of what the user will experience. This also means it can act as the voice of the user in the design process and keep the work grounded.

Being Realistic About Innovation

Testing checks if functionality works, whereas QA measures whether functionality delivers.
Sometimes creative, innovative solutions make perfect sense in the design process but can be confusing to an end user. Testing has no opinion on this matter — it merely checks whether technical requirements have been met. But QA has a holistic view on usability and can help intercept confusing product features before they get to user testing.

Challenging With Empathy

Testing is an audit report, QA is a supportive conversation.
Submitting a long list of fixes at the end of a sprint feels like a process designed to punish developers by highlighting mistakes and errors. A better idea is to work alongside developers as they code to highlight user-improvements so that QA becomes an integrated part of an agile process.

Making Marginal Improvements

Testing has no view on the impact or importance of a bug. QA prioritises legacy fixes into a list ordered to maximise the user-benefit.
Development time and resource is limited. Therefore the focus is on getting the best return on that effort by focusing fixes on what will have the biggest impact for the user. Testing is communist — it treats all bugs equally and has no concept of return.

None of this is to say that we don’t use automated testing: executing pre-scripted tests on the system. We do — but some of the techniques we use alongside it include exploratory testing.

A simple definition of this is test design and test execution at the same time. Unlike scripted tests, exploratory tests are not defined in advance and carried out according to any particular plan. This is a more human, hands-on approach whereby our QA team vigorously test the system under examination using actual devices and browsers, thinking more like a user to uncover bugs and usability issues.

Above all, exploratory testers take the view that writing down test scripts and following them tends to disrupt the intellectual processes that make testers able to find important problems quickly. The more we can make testing intellectually rich and fluid, the more likely we will be to hit upon the right tests at the right time. That’s where the power of exploratory testing comes in: the richness of this process is only limited by the breadth and depth of our imagination and our emerging insights into the nature of the product under test. It serves as a complement to automated testing in helping to establish greater confidence in the software by ensuring more defects are found early in development.

That’s an overview of how we see the differences between testing and QA here in the studio, and how we deploy testing.

Get in touch if you’ve got a further interesting perspective to add.

Irrational Realism: on QA vs testing was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read our new report — then come and tell us your thoughts

Innovation Labs are a hot topic in business at the moment — but what’s the best way to launch and run one? What are the biggest challenges to success, the best practices, and the key measurement metrics? We ask these questions because at present, nobody seems to have the same answer.

Here at Made by Many we’ve been looking into innovation labs in the last few months, and we’ve compiled our findings into a new report which we publish today (get a copy here).

Some of the findings might be suprising, and perhaps quite challenging too: we found that the innovation lab model often promises a lot without delivering quite so much in terms of tangible success. How should success for these entities be defined?

We’re as keen as anyone to see innovation labs make a real difference, from both user and business perspectives, and that’s why over the coming weeks and months we’ll be steering the conversation towards defining best practice in this area.

We plan to host an informal dinner around this topic in our office soon — so if you’re interested in attending, fill your details in here and we’ll be in touch very soon.

Asking The Big Questions About Innovation Labs was originally published in Made by Many on Medium, where people are continuing the conversation by highlighting and responding to this story.