How to make a UX decision to bundle or separate applications

Question

I'm contributing to an open source project and there's the question of features and scope.

Right now I noticed in my daily work flow that we use a kanban board and hipchat. So the idea is to add chatting as a feature to the kanban board.

Facebook tried unbundling its service by separating the messenger and regular facebook features.

Microsoft recently tried bundling its calendar, mail, and cloud service together in one app.

This question is about approaching the scope of an app and deciding whether or not to bundle. What do you need to take into consideration. In what situations is it better to have 2 features on the same interface vs having two tabs open on the browser?

Argument for bundling: A lot of internet users don't know how to use the tabs feature on their browser

Answer 1

Great question! I'm in the midst of addressing an application suite that is being divided from a sales and marketing perspective but more tightly integrated from an experience perspective (for those that buy the whole kit).

It's a question of activities

Obviously, every added feature in a view complicates info architecture. But when users regularly access more than one function in the course of an activity, bringing them into a single view may actually simplify the workflow.

My bottom line criterion:
Whether or not it makes your job harder, the user's job should get easier.

Conversely, these factors are good indications to split things apart.

1. The user's job does not get any easier.
2. The functions don't logically relate.
3. Bundling slows workflows and/or system performance.

How to address the strategic aspect

This is a complicated subject in no small part because it crosses the lines of business strategy, system architecture, and user experience is very deep ways. I believe that UX is the best place to begin assessing this question (not just because I'm a UXD ;-). The business can still sell components distinctly, even if the experience dictates a single view. And system architecture is rarely a limit these days. The choice has to depend on the user's experience of the features.

Answer 2

Actually, I think the same principles involved in the decision of creating an application can be applied to make decisions about whether or not to combine or separate applications.

1. The first step is to list the requirements from the business, technology and user perspective.
2. The second step is to assign a weighting to each of the requirements.
3. The final step would be to make a decision based on what the priorities are.

So for example, there might be a number of business requirements such as the cost and benefit of maintaining one application or creating product teams dedicated to each application and how that affects the operation of the business. There might be some competitor analysis that affect how much you want to differentiate your product from the competition, etc.

Then there are the technical requirements such as how easy it is to develop the applications separately, and the technical stack that supports the different features of each application, the in-house or outsourced expertise available for the design, development and maintenance.

Of course, there are also user requirements such as those based on the users population/demographics for each application, and whether there is enough difference to create separate products or if the users see it as one application.

I think the 80/20 rule is good to apply to the decision making process as well as weighting each requirement. You also have to anticipate how much these requirements will change over time for each of the three areas, so it is certainly not an easy decision to make, but the more factors you can consider, the more likely it is for you to make the optimal decision.

Answer 3

The best UX criteria should be dependent on an analysis of the product backlog or feature roadmap from a UX perspective. It’s basically an information architecture exercise. I’ve worked on a number of large product suites over the years for companies like Siebel and Autodesk. With modern web applications it’s important to think about how you’ll enable features based on user roles (Role Based Access Control) and the tasks or workflows associated with their login credentials.

Usually the same RBAC model can enable feature sets in a way that make it easier to reuse code to achieve UI consistency and decrease cost of development. There are other technical considerations that have an impact on UX. For example creating separate code bases in web apps can make it harder to integrate things later like notifications or dashboards. Putting stuff in two browser tabs often creates issues because the security model of browsers is designed to prevent one page from interacting with another (see https://en.wikipedia.org/wiki/Cross-site_scripting)

Practically speaking what I do is put all the user stories or features in a spreadsheet in the first column, and group them into epics or themes based on an analysis of the workflows that they represent. (Mike Cohn explains epics and themes well on his site.)

You typically do not want to split the epics into separate apps, because the stories in them depend on each other. You also need to consider if the epics or groups belong together in a similar way (same app) or are relatively independent of other things.

Finally, I create columns for each persona/role we are designing for and check off in these columns what stories the persona will have access to. I’ve written a blog post on this at http://boxesandarrows.com/integrating-ux-into-the-product-backlog/

Ideally you start this effort with sticky notes on a wall, just like any sprint planning session working with the team. I just tend to use the spreadsheet to capture the output for later reference. Most Agile planning tools do not do this very well. The whole team will see a lot of benefits from the final analysis if it’s done correctly as it will improve sprint planning, feature development and testing efforts.

Answer 4

Here are a few UX reasons to bundle or separate applications / functions / interactions.

Bundle things that are complementary

Imagine going to a grocery store that only sold liquid items such as milk, juice, and soda and a different store that only sold boxed items like cereal, and crackers. This would make buying a breakfast of cereal and milk very hard. Obviously it makes sense to bundle cereal and milk into a single store because many people eat them together.

If one component in your application helps highlight or enhance the qualities of another component then by all means keep them together. Users will connect better to both.

Bundle things that provide context

Showing someone a red badge with a number 2 is a great way to let them know that 2 people have sent them private messages. Making them switch to another app to read them is a slap in the face.

Users shouldn't have to go out of their way to access the content they need.

Separate out things that few people use

Improve the user experience by only showing things that most people use.

Every time you add something to an application it increases the cognitive load on the user. The amount of cognitive friction depends on a number of factors but if nothing else users have to see it and wonder why it's there.

Admittedly, the few people that do use the component might not like that you moved it but this can be mitigated by improving the UX of that individual piece and letting them know where to go before removing the old version from the main application entirely.

Separate out things that have different target audiences

A good example of this is how the Google Drive app allows users to view any type of document but a different app is required in order to edit one. This is good UX because depending on the device I may never actually need to edit anything so less resources are consumed. The primary function of reading all my documents on any device is still in tact and more responsive. The choice is mine in deciding which device should use additional resources to edit either a document, spreadsheet, or both.

---

The real answer to this question is that it rests solely on your users so before making any final decision be confident in saying...

This change will make life easier for most of our users.

Answer 5

I've recently come to the conclusion that making the user's life as easy as possible is a bad thing. It forces extreme design, interface, and development limitations on projects for the sole purpose of making a product idiot proof, often losing the purpose of the product altogether.

Considering that, the case for bundling should be as follows: does it simplify the product to bundle? Not significantly, but does it reduce the number of steps necessary enough to make a noticeable (or perhaps only a subtle) impact? OR, does it combine services together in a way that makes sense, potentially making the process more complicated but conceptually simplifying the user's life/general experience?

One product I worked on was a digital dayplanner for mobile. You can imagine how difficult that is; scheduling, calendaring, task management, contact management, and notes...all in a single mobile app! That was 3 years ago, and today most apps with any of those functions only do the one thing. But there's a strong case to bundle them together: you may want to schedule a calendar event with a number of contacts surrounding a set of tasks and notes. This happens every day.

Our challenge was clear: create a mobile app (since your dayplanner goes with you everywhere) that is easier to use than a paper dayplanner, with all of the expected functionality. Scheduling was excessive; all web-based calendaring tools provide that today, but it was also one of the company's selling points. It failed, and the biggest reason (based on customer feedback, analytics, and our own analysis) was that it was too much. Or, at the very least, we didn't make it useful or beneficial enough for users to continue with the product instead of using an assortment of apps in tandem.

That's why Microsoft, in the last two years, purchased Acompli, Sunrise, and Wunderlist. Acompli (now Outlook) handles email, contacts, and files, and also has calendar support. Sunrise handles calendaring extremely well. And Wunderlist handles task management really well. They all now work with the Office suite, each it's own app. Because as Microsoft is doing it, the focus on major use cases is clear: email often requires calendaring; calendaring is also standalone (though perhaps won't be forever); task management is standalone; and they all revolve around major productivity tools like Word, Excel, and Powerpoint.

So is bundling better than not bundling? Depends on a lot of things, but most importantly...it depends on how you build it, and how deep the functionality is. Further, it depends on the platform; I don't want Slack integrated into an app on my iPhone in a half-assed way when the standalone app is extremely powerful. But who knows, maybe there's a good case for it that people need/want.