I have been trying to find examples on web for information architecture techniques specifically for mobile devices. I realize the steps in getting a IA for any tool mobile/desktop are card sorting, persona, user profile, affinity diagram, sitemap etc. but what I m really interested to know is the differences a designer should keep in mind while making a multi platform application. In other words if my application is going to be working on desktop, mobile and tablet, what are some points a IA should keep in mind?

  • 1
    Google "responsive design" and start reading up on it.
    – DA01
    Commented Feb 24, 2012 at 20:48
  • 4
    @DA01: Responsive design is only a part of the answer.
    – dnbrv
    Commented Feb 24, 2012 at 22:43
  • When project is starting from scratch, a researcher cannot just go in thinking responsive design is the possible information architecture solution. Moreover responsive design is a technique which addresses layout issues associated with a mobile device, when thinking of mobile information architecture I feel the traditional techniques of persona, card sorting, affinity diagram etc have to be re-thought with mobile context. Even before a person starts making workflows,what is the reason a certain feature will find itself in mobile and others may be left out?Layout is just one part of the answer.
    – varun86
    Commented Feb 26, 2012 at 3:06
  • Why do you feel you need such a large discrepancy between doing IA for desktop vs. mobile? I agree that if the site were designed for the desktop, built, and now you have to address mobile, you need to rethink some things. But Ideally you're not doing that...you're building the site from the get go to accommodate the spectrum of users and mediums.
    – DA01
    Commented Feb 26, 2012 at 3:47
  • 1
    mainly because of context of usage, I use gps on my phone and text on the go ( sometimes while driving). Desktop on the other hand is sitting in your home and the user has a more relaxed mindset when dealing with it. Desktop might be a share device whereas mobile is a personal device ( most of the times). I don't mean to suggest discrepancy in any proportion but I m trying to understand what is the thinking a designer goes through when making a prioritization call on requirements for mobile.
    – varun86
    Commented Feb 26, 2012 at 4:14

8 Answers 8


The core methods of exploring and creating the IA for mobile aren't different from a desktop project. The AI itself (the content and its arrangement) is different, mainly due to the (much) smaller screen size:

  1. Only what's important on mobile - The mobile app/site should only contain what's important to the user when using his/hers mobile phone. This doesn't necessarily mean he's out on the street! Some apps/sites are used more on the go (maps, phone directories) and some are used more inside in the house (TV show/movie info). You have to research your target users to understand the context in which they'll use your mobile service, and include only the relevant content for that context.
  2. Simpler, smaller content - Research show that users read less and understand less on mobile. This means you have to rewrite long and complicated content from the desktop site to make it shorter and more understandable. This also means that any secondary content (i.e. stuff that's not absolutely important for the user's current screen) should be differed to lower-level screens.

  3. Simpler navigation menus - Menus can't have too many options. Tabbed menus usually contain 5 tabs at most (e.g. foursquare's native app). MSNBC's mobile site got away with "more", which scrolls the site up, revealing the navigation area, with 21 sections and a search field.

A good example for everything I wrote here is Gap's website on desktop and on mobile.

Like on any UX project, user research and usability tests go a long way.

  • I agree that all 3 are excellent suggestions for mobile. However, they are also excellent for desktop. They are generally seen as good things regardless of the device one is using.
    – DA01
    Commented Feb 27, 2012 at 5:16
  • 1
    The 'core techniques' work for any kind of interface: desktop / mobile / kiosks / physical etc as they deal with 'how' not 'what'.
    – PhillipW
    Commented Sep 23, 2013 at 9:30

There are no techniques I am aware of specific to mobile. However, there are many constraints that should guide your choice of UI for a mobile application:

  • Your network usage is constrained. Avoid using constant network access. Network usage should be explicit (user action requested) or very small (checking for new mail headers). You cannot depend on constant network access, and your application should fail gracefully and silently in the absence of a network connection.

  • Your screen space is constrained. Narrow your use case to the most common and useful to the user. Define the minimum UI necessary to accomplish these use cases. Then cut the list down even further, because you probably are still not simplifying enough. Large fonts compensate for the extremely tiny point size of many screens. And flexible layouts allow you to provide an optimal layout on multiple devices, at any orientation.

  • Your memory is constrained. Loading datasets into RAM may not be an option. Pay attention to the choices you make between data efficient and processor efficient algorithms, because on a mobile device these choices really matter.

  • Your runtime is constrained. Your app may be suspended at any time. The battery could die at any time. Never leave your data in an inconsistent state, even in the middle of a task. You can be thrown into the background at any moment by a call or the whims of the user.

  • Your storage is constrained. Storage is measured in megabytes on a mobile device, not gigabytes. Reduce your application footprint as much as possible. One benefit of the flat icon fetish is a significant increase is graphic compressiblity.

  • Your input is constrained. Touch interfaces are imprecise, and typing is a chore. Don't make your users write an essay unless absolutely necessary. Don't expect them to hit a click target exactly. This, of course, ties in with the display constraint above on how you design and lay out the screen.

  • And of course, your CPU is constrained. As above pay attention to your algorithm efficiencies. Offload heavy processing tasks to the cloud if necessary (the the caveat of 'fail gracefully when the network is unavailable'). In business, time = money; in mobile, cpu = battery. Avoid unnecessary cpu usage that does not tangibly and directly benefit the user. Know your platform, and work to use the APIs available to avoid re-inventing the wheel badly; built in functions will almost always perform better and be more efficient than rolling your own.

Designing for the mobile space is all about being aware of your constraints, and designing your application with those constraints in mind. Make your defaults good so that users don't need to fiddle with a ton of settings. Make your user interface anticipate the users needs and have the most common use case require the fewest actions. If you have more than 10 buttons on the screen, you're probably doing something wrong; limit complexity.

I hope that helps.

  • 1
    Excellent answer,another aspect you should consider is the case of scalablity such that your site or app should be able to scale to different screen sizes.Another point which was not mentioned but is important is the provision for accessibility since the text on mobile devices is so much smaller,so look at that as well
    – Mervin
    Commented Feb 24, 2012 at 21:16
  • Good suggestions, I modified the comment on screen constraints to incorporate them. Commented Feb 24, 2012 at 21:51
  • I am curious about your statement "If you have more than 10 buttons on the screen, you're probably doing something wrong" ,windows phones use tiles and its not uncommon for them to have quite a few tiles ,can you explain where you came up with that number of 10?
    – Mervin
    Commented Feb 24, 2012 at 21:53
  • 1
    It's a great summary of constraints for developing for mobile platforms but it's almost entirely irrelevant to the question. Only screen size & input controls have significant impact on information architecture. Moreover, you are completely wrong on storage: even "dumb phones" are capable of extending memory storage to GB's.
    – dnbrv
    Commented Feb 24, 2012 at 22:47
  • 2
    Unfortunately, I don't like this answer, as I don't think it really addresses the question. The OP wants to know if information architecture changes - s/he isn't asking about implementation differences, or the need to reduce HTTP requests and whatnot. Commented Feb 24, 2012 at 23:50

There are two main IA implications I can consider (outside the purely technical ones):

  1. The screen is much narrower, which means limiting the topmost categories/navigation options and possibly encouraging search-first navigation (especially on larger sites)
  2. The user has a much higher probability of being mobile/away from home when accessing your site from a mobile device. That means prioritising things that provide value to someone on the road such as your contact and address details.
  • 1
    I'd argue #2 should be universal regardless of the device. ;)
    – DA01
    Commented Feb 27, 2012 at 5:14
  • @DA01: while I appreciate your point, notice that I said "that provide value to someone on the road". There can be many types of information that can be elevated in importance on a mobile device. Take Amazon: when on the road, you're less likely to be browsing the whole store for purchases, so they prioritise your wish list, your cart and your pending orders (which means they make logging in a more prominent action) and provide a search-first interface to access the store itself.
    – Kit Grose
    Commented Feb 27, 2012 at 5:31
  • 1
    And while I appreciate your point, I still say that's all important content regardless of how one is accessing the site. I think we make too many distinctions between the two. Often, the best mobile site is taking the time to simplify the current site. There are always exceptions, of course.
    – DA01
    Commented Feb 27, 2012 at 14:12
  • 1
    huh.arbitrary? Some of your comments were rather surprising considering you are a UXer :)
    – varun86
    Commented Feb 28, 2012 at 1:26
  • 1
    The second one is interesting if you think of a user story of a traveller who is boarding flight and has the boarding pass on mobile. I m sure there are many more use cases like that. Thanks
    – varun86
    Commented Feb 28, 2012 at 1:34

I believe it would be useful to distinguish between the "macro information architecture" (that is, the structure of the informative domain) and "micro information architecture", that is how to represent the information on a page (or, talking about mobile, on a view).

There is no doubt that the micro information architecture for the mobile should be somehow different from the one for the desktop. The approach of responsive design is the attempt to adapt the layout client-side, and this is often an acceptable solution. There are circumstances, however, where designing ad hoc views would be preferable (the mobile and native approach).

On what concerns the macro information architecture, on the other hand, it is not so obvious that it should change from desktop to mobile. When I made a short benchmark to see how some players dealt with the problem, I discovered that some of them (for example, BBC, New York Times) tend to simplify, and flatten, the structure of the information hierarchy, whereas others (Amazon, Ebay) tend to preserve it's depth.

Personally, i tend to agree with the latter solution, because I assume that the macro architecture should be based more on the users' mental models, that should be mostly device independent: I would be very surprised if the results of a card sorting for a mobile app would be that different from those for a desktop site.

If the structure of the macro IA were very complex, however, the designer should be very careful to represent it to the user, allowing her to navigate trough hierarchies, filters, sorting, facets, lateral navigation, and so on. And the navigation pattern should be adapted for the device.


I will probably describe this very poorly.

Aside from the suggestions already here. The mobile is a more personal device. The user accesses the device almost exclusively and changing the view so it more individual to them is more important.

So where as your website may be viewed as having a large website with areas that are personal to the user. The mobile is better thought as having a personal view with the website serving that view. I think a strong example of this is ebay. Look at the site and it is a large 'shopping mall' where you can buy anything and a little area of this is for you. Look at the app and it is all designed around you and what you last did and the exception that you want to pick up where you last left off. It focusses on that little area and gives you access to the 'shopping mall'.

As a side note this is potentially where responsive design does not handle the change in medium very well. It will improve the UI but not necessarily the user experience.

  • hmm, in any of these e-commerce models one can browse and search things regardless of platform or device. If you want to make a purchase they do require you to login. Your statement would be true if every app was asking the user to login first and then only browse, search and buy. I agree about the responsive design statement.
    – varun86
    Commented Feb 27, 2012 at 14:53
  • This is a very good point; most apps have you choose your login as a configuration choice. It may confirm your password before important events (password change, purchase), but a personalized view should be the default. Commented Feb 27, 2012 at 15:41

I believe this is what OP originally asked for.


Excerpt without graphics:


Mobile devices have their own set of Information Architecture patterns, too. While the structure of a responsive site may follow more “standard” patterns, native apps, for example, often employ navigational structures that are tab-based. Again, there’s no “right “way to architect a mobile site or application. Instead, let’s take a look at some of the most popular patterns: Hierarchy, Hub & spoke, Nested doll, Tabbed view, Bento box and Filtered view:


The hierarchy pattern is a standard site structure with an index page and a series of sub pages. If you are designing a responsive site you may be restricted to this, however introducing additional patterns could allow you to tailor the experience for mobile.

Luke Wroblewski’s Mobile First approach helps us focus on the important stuff first: features and user journeys that will help us create great user experiences.

Good for

Organising complicated site structures that need to follow a desktop site’s structure.

Watch for

Navigation. Multi-faceted navigation structures can present a problem to people using small screens.

Hub & spoke

A hub and spoke pattern gives you a central index from which users will navigate out. It’s the default pattern on Apple’s iPhone. Users can’t navigate between spokes but must return to the hub, instead. This has historically been used on desktop where a workflow is restricted (generally due to technical restrictions such as a form or purchasing process) however this is becoming more prevalent within the mobile landscape due to users being focused on one task, as well as the form factor of the device, making a global navigation more difficult to use.

Good for

Multi-functional tools, each with a distinct internal navigation and purpose.

Watch for

Users that want to multi-task.

Nested doll

The nested doll pattern leads users in a linear fashion to more detailed content. When users are in difficult conditions this is a quick and easy method of navigation. It also gives the user a strong sense of where they are in the structure of the content due to the perception of moving forward and then back.

Good for

Apps or sites with singular or closely related topics. This can also be used as a sub section pattern inside other parent patterns, such as the standard hierarchy pattern or hub and spoke.

Watch for

Users won’t be able to quickly switch between sections so consider whether this will be suitable, rather than a barrier to exploring content.

Tabbed view

This is a pattern that regular app users will be familiar with. It’s a collection of sections tied together by a toolbar menu. This allows the user to quickly scan and understand the complete functionality of the app when it’s first opened.

Good for

Tools based apps with a similar theme. Multi-tasking.

Watch for

Complexity. This pattern is best suited to very simple content structures.

Bento Box/Dashboard

The bento box or dashboard pattern brings more detailed content directly to the index screen by using components to display portions of related tools or content. This pattern is more suited to tablet than mobile due to its complexity. It can be really powerful as it allows the user to comprehend key information at a glance, but does heavily rely on having a well-designed interface with information presented clearly.

Good for

Multi-functional tools and content-based tablet apps that have a similar theme.

Watch for

The tablet screen gives you more space to utilize this pattern well, however it becomes especially important to understand how a user will interact with and between each piece of content, to ensure that app is easy, efficient and enjoyable to use.

Filtered view

Finally, a filtered view pattern allows the user to navigate within a set of data by selecting filter options to create an alternative view. Filtering, as well as using faceted search methods, can be an excellent way to allow users to explore content in a way that suits them.

Good for

Apps or sites with large quantities of content, such as articles, images and videos. Can be a good basis for magazine style apps or sites, or as a sub pattern within another navigational pattern.

Watch for

Mobile. Filters and faceted search can be difficult to display on a smaller screen due to their complexity.


First, we need to define IA. Are you asking specifically about Information Architecture, or user experience in general?

IA is a bit of a fuzzy term. Some use it to refer to the site map and content matrix. Others use it as a synonym for user experience.

In terms of content structure, being on mobile isn't likely going to be a whole lot different than on the desktop. You may segment things a bit more, but the user goals are often going to overlap quite a bit.

If were talking the entire UX, then Myrddin's answer is good.

  • I treat information architecture to be a part of a bigger concept of user experience. I disagree that content structure and content itself is similar to the desktop, I did a study to understand how different applications like facebook, netflix, amazon etc which are present on multiple platforms like desktop and mobile have different content and the user goals are more prioritized on mobile. So how does one prioritize this information architecture on mobile? How does one feature gets higher priority vs other, considering you can't really design or make prototypes in IA stage of UX process.
    – varun86
    Commented Feb 26, 2012 at 3:18
  • I had posted the original question thinking that people might have some other technique specifically for mobile but based on the comments I thought of clarifying further that I m not looking for layout related IA solution only.
    – varun86
    Commented Feb 26, 2012 at 3:21

In addition to the other answers about layouts, it may be good to consider the search/browse strategies employed by the mobile user. Some users browse to stumble upon items serendipitously whereas other users are looking for a specific item. The IA should account for both ends of the user behavior spectrum by allowing the flexibility for user to switch between both modes. For example, in the browse screens you can have a "pin" feature to save items that a user can later quickly find from a list of most frequently purchased.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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