Americas

  • United States

Asia

lamont_wood
Contributing Writer

Mobile apps get the crowdsourcing treatment

feature
Feb 11, 201611 mins
MobileSmall and Medium Business

Savvy organizations are using social media tools to tap the brainpower of their staffs, and they’re using the feedback to build more innovative mobile apps.

mobile apps crowdsourcing via social media network [CW cover - October 2015]
Credit: Thinkstock

When developing mobile enterprise applications, there are two basic options: Plan the process in advance in exquisite detail or listen to user feedback and iterate as you go. The latter approach, by all reports, can speed things up dramatically. But don’t attempt it without a strong social media framework in place, experts say.

Dynacare, a Brampton, Ontario-based provider of medical laboratory services, used customer and staff feedback gathered through social media to produce an app that allows users to check the wait times at the company’s clinics and labs, and add themselves to the queue.

The developers then continued using feedback, culled from Twitter, emails and phone calls, throughout the development process. “We created a very small prototype, let the users supply feedback and then evolved it through the feedback,” says CIO Daniela Crivianu-Gaita. “You see common themes in the feedback and then deliver the next release with the features that address those themes.

“[Developers] fear that [crowdsourcing] will take them longer, since the [process] is not spelled out on paper,” she adds. “We found that’s not true — it takes significantly less time. And it was a success story, in terms of the number of downloads and the feedback.”

At Code.org, a Seattle-based nonprofit that promotes expanded access to computer science education, the development team relies on feedback made possible by the companywide exposure that projects get via internal social media, says software engineer Brendan Reville.

“When someone is building a new user interface screen, you’ll notice and add an idea,” he says. “It gives you an ambient awareness and lets you spectate what’s going on — that’s where you get value and creativity.”

By relying on this type of feedback, companies report that in-house app development projects can be completed six to 10 times faster than they could with traditional methods. Usually involving the use of internal social media or collaboration tools, the feedback process begins with idea-gathering and continues through development and testing — and then it restarts with the next iteration.

Social media helps drive the conversation

“The traditional way [to develop apps] is to build a set of requirements, go away for 18 months and then give the finished app to the user, who says, ‘Oh, we don’t need that anymore,’ or ‘This is not quite what we need, so tune it,'” says Gartner analyst Richard Marshall. “That’s literally what happens with the waterfall [method]. But feeling your way through the process and identifying what works — that is where social collaboration tools come in.

“Most organizations are stuck in the waterfall [method],” adds Marshall. “The CFO expects to be presented with a project plan and schedule, and told how much it will cost. Here, with the digital transformation, you have an idea, but you don’t know how much it will cost, or how long it will take, or what it will look like, and you’ll get dynamic feedback along the way. The approach requires a significant change in the way you think about things.”

Gautam Agrawal, director of product management at Sencha, which sells the Sencha Touch mobile development framework, agrees. “Five years ago, the methodology was that somebody sat with a business analyst, created a lot of documents and sent them to the developer organization, which turned it into an app,” he says. “It took about 18 months, and toward the end the users would get some access to what was being built and get to review it.

“Today the users have access to what is being built,” he adds. “Feedback is ongoing as it is being created, and that takes away a lot of waste, as the developers know what’s wrong on a daily basis.”

Agrawal says a small to midsize application, usually involving data access, can be completed in a few weeks, while a larger enterprise-level workflow app might take six months to complete.

Some enterprises hope to cut the cycle to two weeks, “but four to eight weeks will be as much as most can handle,” Marshall says. “If they were faster, they would be putting out updates constantly and feedback would dry up as users got sick of the new versions.”

Tools abound for tapping employee feedback

Dynacare is using public social media for feedback, but most organizations are focused solely on internal tools intended for collaboration, such as Atlassian’s HipChat, which Code.org uses.

“There are dozens of them,” says IDC analyst Vanessa Thompson. “All are better than mass emailing. Maybe you’re more task-driven, or conversation-driven, or bug-killing-driven — whatever your main event is, that is what you should lean toward. How to choose? They offer free trials.”

At Getable, a San Francisco company that runs an online rental marketplace for construction equipment, CTO Daniel Erickson wanted a collaboration tool to use in mobile application projects so developers wouldn’t have to deal with long, cumbersome email chains. “We were answering the same questions over and over,” Erickson recalls. “We wanted to communicate in the open.”

What he found was a range of collaboration tools, mostly chat- or topic-based. Discussions were easier to retrieve with topic-based tools, but Getable adopted both kinds, using topic-based Yammer from Microsoft for longer questions, and chat-based Slack from Slack Technologies for yes-or-no questions.

Erickson says Getable now uses internal social media in three phases of a development process. “In the start, we use it to get new ideas and toss them back and forth. Then, when we’ve decided what we are actually building, the engineering and design teams use it as an interface to each other. They post everything in Yammer, get answers in the open, and they don’t have to go out and get the answer again,” Erickson says. “The third part is the QA process, where everyone hammers at it to find bugs and flaws and post them on Yammer. It lets us efficiently gather feedback from the entire team, and from there we go to bug-tracking tools.”

These tools are often described as old-fashioned chat channels with added features. Any user’s input is immediately visible to the others, who are all logged in to a single site in the cloud. (Some vendors offer server-based versions, for organizations dealing with regulatory compliance issues.) Text is preserved and available for subsequent searches, and it can be augmented with files, links or graphics.

In HipChat, content is displayed in what are called rooms. “When working on a new version of the software, we’ll have one room for the old version and one for the new,” says Steve Goldsmith, head of engineering for Atlassian’s HipChat team. “A room’s use will follow the product life cycle, with initially a few people there talking about its inception. Then the number of users expands as they do the development work, and then it contracts as they leave for other projects.”

Goldsmith adds that in his experience, most users have two to four rooms they participate in during a given day — one or two for their specific projects and another one or two for general discussions. The contents are searchable, so users don’t have to stay in a room to remain current, and the system notifies users if their names are mentioned in other rooms, Goldsmith notes.

With Slack, a competing collaboration tool, topics are arranged in channels. As developers begin working on a new feature, they open a new channel for it, explains Merci Grace, Slack’s head of product development. “All the brainstorming for the feature happens in that channel, and you can see the building of the feature in real time,” she says. “Later, if you need something, such as a photo of a whiteboard or a logo, you can limit your search to that channel.”

Going all-in with open discussions

Corporate culture is an issue that has to be taken into consideration when deploying collaboration tools. Membership in a channel or room can be open to the entire organization, or restricted to a few, so companies have to decide how much openness is desirable.

“There is often a concern about how much conversation to have in the open, where others can see it,” says Mike Stone, a vice president at Salesforce.com, which has a collaboration tool called Chatter.

Some companies “want to create a bunch of private groups and keep it compartmentalized,” he explains. “But the most successful efforts are the ones that are the most open. The most amazing benefits are from the ideas you did not expect. That benefit far outweighs any potential risk from open communications. The risk is not going all-in.”

Meanwhile, when feedback is solicited, it often comes from people who are unhappy. But that’s no reason to ignore it — just the opposite, says Jeff Haynie, CEO and co-founder of Appcelerator, a maker of a mobile app development platform.

“People can send direct requests [for new features] on Twitter, and I will reply to them,” says Haynie. “I can’t guarantee that we will do what they want, but they know a voice is listening to them.”

The pitfalls of too much or too little

But most experts agree that the biggest danger in relying on collaboration tools and feedback is that the users often won’t say anything. “People can be shy about posting,” says Erickson. “I find that it takes a month or two, and a little training, to get them out of the private communication mindset.”

Marshall agrees that giving feedback may not come naturally for the rank and file. “You have to empower the users to give feedback — people have to be educated to do things that they did not previously do,” he says. “A lot of people are scared to make comments on things they think are finished.”

But another problem arises if crowds rush to participate. “There are some projects that should be handled by five people,” says Agrawal. “Having too many cooks is a problem when there are deadlines to meet. Seven participants is the optimal number.”

And if an organization accepts feedback through social media, it ought to do something with that feedback, says Johan den Haan, CTO at Mendix, a maker of an app development platform that has social media functions, including a feedback widget that can be placed in the app itself, enabling users to post comments and ideas that can be added to the work cycle.

“If you introduce social media capabilities and then you fail to do anything with the feedback, people will be disappointed,” den Haan says. “They will [give feedback] maybe three times and then decide that nothing has changed. You need to be able to process the feedback, and that may take a lot of resources.”

Den Haan cautions against adopting an internal social media tool but then carrying on as before. “If you do not change the process or the people who work with it, then you will not have the success that the technology promises,” he says. “You need cross-functional teams that work in short iterations.”

Avanade, a multinational technology consulting firm, used Microsoft Intune to create an in-house app store, says Eric Cameron, director of hosting and collaboration. “We did leave on the rating feature. We always want more feedback,” he says.

Marshall notes that many enterprises use in-house versions of app stores to circulate app updates, and those sites often have tools that allow users to rate the apps. However shy users may be about giving feedback, they’re often quick to give low ratings in app store reviews — and that type of response can be painful for developers, he cautions.

“You have to be comfortable with negative feedback,” Marshall says. “You can typically turn off the rating facility, but you shouldn’t.”

Finally, forget the word project, says den Haan, because it implies that the development process has an endpoint, presumably defined in the original plan. These days, the idea isn’t to plan a fixed agenda, but to proceed based on feedback.

“It’s an application life cycle, not a project,” den Haan says. “The group working on it may grow bigger and smaller, but it will have life until you remove it from your organization.”