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

  • 2
    The reasons for bundling or unbundling that you gave have little to do with UX, and a lot to do with business strategy. – JohnGB Feb 3 '15 at 17:51
  • Thanks JohnGB. I'm asking about how bundling relates to the user experience. – UX Guy Feb 3 '15 at 19:01
  • @JohnGB I totally disagree. This is one of the many places where business strategy and UX overlap. – plainclothes Jun 13 '15 at 5:28
  • I'm curious about your statement about the many users who don't know how to use tabs. Is there any data available on this? – Vitaly Mijiritsky Jun 13 '15 at 5:38
  • 1
    I saw this a while back & thought I'd commented how I HATED that FB unbundled Messenger - it was an awful user experience because they removed expected functionality & booted you out to a 2nd app. After I deleted the FB app entirely (too much time-suck), I came to appreciate how Messenger let me retain the ability to reach FB contacts w/o all the noise/distraction - that task now stood alone. So how exactly do people use your products? Do they require a bundled multi-product workflow for inter-related tasks, or can tasks stand on their own and perhaps benefit from separate apps? – mc01 Jun 18 '15 at 20:02

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.

  • I really like this answer as it posits a set of clear threshold questions one can use to make sure the decision is the right one. Although oversimplification is sometimes a hazard in design, it's also often a great help and asking a simple question like "does it make the user's job easier?" has a great way of cutting through a lot of red tape and debate to frame an issue at its core. I picked another answer because I felt that it aligned more closely with what the OP (not me) was asking in terms of method, but I found your answer really thoughtful and zen-like in its simple principle (+1'd it) – tohster Jun 19 '15 at 4:17

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.

  • +1 thanks for the response. This is good solid common sense methodology that is easy to overlook in design. It's powerful in the sense that it unifies design, development and business, but as such I decided to pick another more UX-oriented answer. That should not detract from the value of your thought process here because this approach is actually correct for the overall product decision. – tohster Jun 19 '15 at 4:20

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.

  • +1 +100...I awarded this answer because although I am not sure about the initial regard to product backlog and roadmap, I thought this was the closest answer to a clear, UX-oriented answer to a decision process. You're right to bring up Information Architecture, and the user-centric approach of epics, stories and arcs is a great way to answer the question systematically and deliberately from a user's point of view. Well done! – tohster Jun 19 '15 at 4:22
  • Great answer. I think the backlog can be misleading unless it's managed well -- just to highlight that it needs separate focus. Not sure about this either > "creating separate code bases in web apps can make it harder to integrate things". If you separate your view from the app logic, it's not a big deal. I've spec'd notification center features that cross apps and rely on the same service in the end, it's just used by multiple apps on the front end. – plainclothes Jun 19 '15 at 5:18

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.

  • +1 As always @DaveAlger your answers are thoughtful and just quirky enough to provide insight that others overlook. Google Drive is a fantastic example of a very complicated, multi-app separation that has been very successful for Google. It's such a great case that I want to think about it quite a bit further, because it resolves a lot of complications like how to share data, unify UX styles and interactions, and handle overlapping feature scope. Thanks! – tohster Jun 19 '15 at 4:24

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.

  • +1 and thanks @Jamezrp! I thought this answer was focused a bit more on examples and less on how to make a decision (the OP's original question) so I didn't award it, but the MSFT (one-app) vs Google (multi-app) dayplanner approach will be pretty interesting to watch going forward. – tohster Jun 19 '15 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.