Designing App Information Architecture

Phone photo by Canva. Beach photo by Nancy Wierzbicki. Logo property of the City of Milford, Connecticut

Cognitive psychologist Herbert Simon wrote that “a wealth of information creates a poverty of attention and a need to allocate that attention.” In other words, a large amount of content combined with a lack of organization causes a horribly unfocused user experience. Luckily information architecture (IA) design is here to help allocate users’ attention well and solve this problem.

IA design involves creating an organized structure in a website, app, or product that helps users navigate and understand where to find what they need easily and quickly. Informed by the cataloging and categorization of library science and the understanding of human behavior through cognitive psychology, it considers elements such as menu navigation, labels, tags, page hierarchy, visual hierarchy of content, user expectations of an experience, and user familiarity with site components.

Information architects are less concerned about the user interface (UI) design of a site than they are the underlying bones of it. An ugly site that is easy to navigate and helps users meet their goals can elicit more positive opinions from users than a disorganized beautiful site that wastes a user’s time.

There is no central set of rules for IA design as exists in other design areas. It can be different according to a website or app’s purpose, users and their goals, or content requirements. Information architect Dan Brown, however, has attempted to outline 8 guiding principles for IA:

  1. Objects: treat content as a living, breathing thing with a life cycle, behaviors and attributes
  2. Choices: create pages that offer meaningful choices to users and keep the range of choices available at one time focused on a specific task
  3. Disclosure: have only enough information to help users understand what kinds of information they’ll find as they dig deeper
  4. Exemplars: describe contents of categories by showing examples of the content
  5. Front doors: assume at least half of a website’s visitors will come through a page other than the home page
  6. Multiple classification: offer users several different classification schemes to browse a site’s content
  7. Focused navigation: don’t mix apples and oranges in your navigation plans
  8. Growth: assume the content you have today is a small fraction of the content you will have tomorrow

Brown admits, though, that even these 8 principles are not set in stone. He simply outlined them to offer a foundation from which to build a standard approach for this area of design. How you approach defining a website or app’s IA is a more standardized practice to learn. Nielsen Norman Group lists the activities an information architecture must undertake to design IA as:

  • Content inventory: examine a website to find and identify all existing content
  • Content audit: evaluate content usefulness, accuracy, tone of voice, and overall effectiveness
  • Information grouping: define user-centered relationships between content
  • Taxonomy development: Define a standardized naming convention to apply to all site content
  • Descriptive information creation: Define metadata that helps users search and discover content

USERS INFORM IA DESIGN

Photo by fauxels at pexels.com

Another thing I would add to the previous list that is an overarching activity is to always keep users’ needs in mind when making IA design choices. IA is a foundational part of user experience (UX) design. UX is guided by the principle of design thinking which believes design should always consider users and help to solve their problems.

Research such as interviews and observations help UX designers gain insight about their users and make better design decisions. IA design is not exempt from benefitting from user research insights. Sometimes users’ behavior may indicate the need to make a design decision that isn’t strictly best practice. Allow user goals to guide you. They are what IA is built to serve.

In a previous post, I explored the process I used for redesigning the IA for my home city of Milford, Connecticut’s municipal website. In terms of government websites, users can mean many things—residents of all backgrounds, education levels, and technological familiarity; business owners and employees; visitors and tourists; prospective residents and businesspeople, and government employees themselves.

As I was going through this process, I asked myself who makes up the majority of the users who interact with a government site. Although I do not have data to prove it, there are good odds city residents is the right answer.

Here are residents in my city, including myself, dumped on to a site that’s trying to do everything for everyone and made to wade through a mass of content to complete what are usually simple tasks like paying taxes or learning how to request a copy of a birth certificate.

What if information most pertinent to residents could be isolated away from the rest of the noise on a government website? In my IA redesign, I did make “Residents” a category in the global navigation, but in such a large site there’s still the opportunity for residents to accidentally get lost and waste time getting to what they want. So, I decided to design the IA for a resident companion app for my city’s municipal website.

My App IA Design Process

Beach photo by Nancy Wierzbicki. Logo property of the City of Milford, Connecticut.

There are pros and cons to whether an app or a mobile website is the way to go. On the one hand, not everyone wants an app for everything on their mobile device and creating an app is an extra cost compared to just designing an overall website with a mobile-first approach. On the other hand, though, government websites contain information that is often vital to residents who have the least access to the internet and depend heavily on mobile devices.

Apps are designed exclusively for use on mobile devices, compared to websites that sometimes must balance between mobile and desktop views. Apps also tend to be quicker to load because they store their data locally and information stored on them can often be accessed whether or not a user has an internet connection. These pros for creating more equality in information access amongst residents are the reasons I believe an app for a city’s residents could be warranted.

The site map above represents my proposal for the IA of the Milford Resident Companion App. Site maps are visual representations of the IA of a website, app, or product that use symbols to represent the hierarchy and navigation of content. This bird’s eye view can help designers better understand the paths users take when they interact with a website, app, or product and how they access information. All of this can have an impact on users’ overall experience.

The app in my site map will function as an on-the-go resource for residents to be connected with their city and conduct common government-related business, such as paying taxes, placing public works service requests, learning election or voting information, and contacting their representatives. The app will attempt to integrate these government-related functions with more community-related functions, such as events, transportation needs, recreation activities, and supporting local businesses, as this is the way residents view their experience of living in a city.

Some of the content categories visible on the site map were sourced directly from the government website while other categories came from local organizations, services, businesses, and tourism efforts. The app, though, is not a 1 to 1 replica of the government site.

For example, the site contains a general contact form but also the individual contact information for each department and each member of the government from the mayor to every board and commission member. Most users do not need quick access to this detailed information on a daily basis on a mobile device. The app would include the same contact form but instead of a list of phone numbers, users would have an option to live chat or text simple questions or concerns to different government departments.

All of the information explaining each department and board or commission along with copious subpages has also been left out of the app. In its place are categories related only to actions residents are likely to take.

Instead of needing to go trhough the “City Clerk” page for record related pages or the “Tax Collector” for tax payment related pages, residents can just click “Requests & Payments” and choose the subcategory they are looking for in order to get straight to the point. That subcategory will include instructions on how to achieve the desired goal, whether it be in-person or within the app.

Although the “Businesses” category on the website’s global navigation mostly related to the business community, some of it, such as lists of local restaurants or businesses is information residents are often interested in as well. This was one point I marked for a possible external integration. Mobile devices have built-in features such as GPS and accelerometers that apps can take advantage of when designing functions that regular websites are not as able to.

Interactive Google maps could be embedded within the “Restaurants” or “Shop Local” pages that show you businesses within a certain radius of your current location. If you’re looking for something to eat you could open a restaurant’s website from the map, view the menu, and then use the map to direct you there, all without ever leaving the app. This could be a way to help those most interested in supporting local businesses break effort barriers to actually doing it. A one-stop shopping solution if you will.

The same could be true for helping to maintain the city. Public Works people cannot be everywhere at all times. My city already has a form to report problems such as potholes or burned out streetlights, but it’s in a couple of locations on the website, one that is not super intuitive and the other that is buried 4 tiers down.

Residents are much more likely to make the effort to report something if it’s as easy as whipping out their phone, opening an app, and clicking once of twice to get to the form. This is the reason I included Public Works as its own category. That and the fact I must check at least once a month to see if a holiday affects my trash pickup day, because who can remember that off the top of their head?

The other advantage of apps I realized while designing this site map was the ability to send notifications. Websites are just not equipped to do this. My city already has an emergency alert system that residents can sign up for. This app could offer the ability to deliver those alerts to everyone who downloads the app without them having to make the effort to go online and sign up.

The app can also serve as a way to deliver lower level push notifications, such as reminders about events. Apps can allow users more ways to customize their experience compared to websites so, this app could allow residents to opt-in or out of certain categories of non-emergency alerts. That’s why “Alerts” is allocated precious space on the footer menu of the app.

Reflections

Beach photo by Nancy Wierzbicki. Logo property of the City of Milford, Connecticut.

Although apps are a different medium from websites, the base process of designing the IA for my resident companion app and creating its site map was very comparable to what I did for my local government website. The largest difference, besides the additional features and integration options an app offers, was how particular I had to be about the number of pages and amount of content I included on the app site map.

I have more items in the global navigation of the app than I do the website, but there is much less content underneath each category on the app compared to on the website. Each category on my website global navigation felt like the tip of a massive iceberg.

For every page I considered placing on the app site map, I asked myself if it was necessary for helping or clarifying the experience for a good-sized group of residents. When you challenge yourself to question the importance of every piece of content rather than make an excuse for its presence, you start to see how much is superfluous.

I’m sure there’s still pages and content I could eliminate from the app IA to make it better. With good IA, websites can allow for a little extra content or content that must be present for political or bureaucratic reasons. Life on a web browser is still expected to be fast and should never be cluttered to the point of hampering this, but user expectations for apps are that they cut right to the chase at lightning speed.

Optimally, I would have liked my app to have been more limited in the number of pages that just provide written information. I’d love for every page and category to be focused on directly taking an action on the app itself. However, that’s just not how my local government has many processes set up.

There are still many government-related actions in my city that must be undertaken in person so, the best an app or website can do right now is provide clear information on a process quickly. Perhaps with some coordination, these in-person processes could be conducted differently, maybe through a video call feature within the app. For now, though, just offering a more direct route for commonly desired resident information would be an improvement.

Depending on the project, the goal of IA design can be to wield the blunt force of a wrecking ball, tearing down and building up content in a completely different form, or to artfully use the precision of a scalpel, incrementally improving an experience for users. Both are equally useful. Both are equally needed.


Reflections

Arhipova, A. Information architecture. basics for designers. Tubik Blog. Retrieved from https://blog.tubikstudio.com/information-architecture-basics-for-designers/

Babich, N. (2020, January 12). An introductory guide to information architecture. Adobe XD Ideas. Retrieved from https://xd.adobe.com/ideas/process/information-architecture/introductory-guide-to-information-architecture/

Brown, D. Eight principles of information architecture. Bulletin of the American Society for Information Science and Technology, vol. 36, no. 6, August/September 2010, pp. 30-34.

Cardello, J. (2014, June 22). The difference between information architecture (IA) and navigation. Nielsen Norman Group. Retrieved from https://www.nngroup.com/articles/ia-vs-navigation/

Deshdeep, N. (2020, march 24). App or website? 10 reasons why apps are better. VWO. Retrieved from https://vwo.com/blog/10-reasons-mobile-apps-are-better/

Holliday, M. (2018, November 16). The eight principles of information architecture. Medium. Retrieved from https://medium.com/@hollabit/the-eight-principles-of-information-architecture-6feff11f907a

Northcott, D. (2012, August 21) The difference between information architecture and UX design. UX Booth. Retrieved from https://www.uxbooth.com/articles/the-difference-between-ia-and-ux-design/

UX Booth Editorial Team. (2015, December 22). Complete beginner’s guide to information architecture. UX Booth. Retrieved from https://www.uxbooth.com/articles/complete-beginners-guide-to-information-architecture/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s