4

Where is the intersection between Information Architecture with Software Architecture?

When you start a new project, usually the software architecture starts its development and UX designer begins his.

But when it ends both the information architecture needs to connect with the software architecture, but it is necessary to know the ideal point of this interaction.

There's this sweet spot, where there are teams of parallel development and UX available for all these teams?

For complement: What is the difference between System Analysis and UX Designer?

  • Hi Monica, welcome to UX exchange. This sounds like more of a project management question and would require more detail to answer. It sounds like you are referring to a conceptual application and you are referring to UX as it applies to front end development, is this correct? – Johnny UX Oct 23 '14 at 20:40
  • Hi @JohnnyUX thank you. Yes, it is about project management. My doubt here is how the UX Designer communicate with software engineers, where are parallels teams and there is only one Designer. – MPossel Oct 24 '14 at 12:12
  • Hi @MPossel before you begin, you should have a scope document that explains all the requirements. There should also be a content audit that explains in detail all the information to be included. However, if it is indeed a conceptual program, they may be looking to you to "figure out the details". You could also determine when is the best time to have communication points. Are you the project manager or the designer? – Johnny UX Oct 24 '14 at 14:44
  • in this project I'm designer. – MPossel Oct 24 '14 at 16:07
  • A good project manager should be way ahead of you as far as when the communication points will occur. I would just ask. – Johnny UX Oct 24 '14 at 17:54
9

Short Answer:

They never intersect, as described, at a single "hail mary" point. They are different elements of the same process and should coexist together as part of that process. In the cases where one may be dependent on the other, the most ideal situation is that Information Architecture would guide the Software Architecture.

Long Answer:

When you start a new project, usually the software architecture starts its development and UX designer begins his.

First things first, this is hopefully not what happens when you start a project! A short list of things that should be happening when you start a new project (in an ideal world you can add a whole lot more):

  • Product strategy
  • Field research
  • Face to face interviewing
  • Requirements writing

In the very least, you should be defining a product strategy and defining your requirements. This should involve everyone: UX, software devs, management, marketing, other stakeholders.

If we just take a situations where just a product strategy and requirements definitions are done, what you end up with a clear roadmap for both the Information Architecture and Software Architecture efforts. It is not a question of "when do we intersect so we know we're going to sync up", it is "we both started knowing exactly where we are going, so we're going to sync up".

But that's a pretty simplified process. When you develop your application with user centered design in mind there is a much greater process that makes sure that you match the needs, wants, and limitations of end users at each stage of the design process.

When you look into different illustrations of UCD you will see many variations, but all getting at the same point. Here is one simple example:

enter image description here

... which I will oversimplify when I point out the following:

Strategy is where your product strategy is defined (among other things).

Analysis is where your field research, face-to-face interview, and requirements are all completed (among other things).

Design is where interaction design, information architecture, with low- and medium-fidelity prototypes are all done.

Software can begin architecture at this point too, because they have clear direction via the Strategy and Analysis stages. Being sure to include the software architects in the IA process helps them to understand how the system will be experienced by the user, so they can begin to scope their process accordingly.

Development is where high-fidelity prototypes are done, with full on software architecture and to the point where you are ready to release.

At no point did we send people off to do their own thing and hope they intersect at just the right moment. You've reached the end with everyone knowing full well were the others have been, where they are, and where they are going.

But, what if your UX and software teams have gone off and started doing their own thing -- despite your best effort. Well, hopefully you're developing under a Model-View-Controller architecture. There are several variations on the theme, but they all basically break down to the same notion: separation of the model (aka: data, vis-à-vis software architecture) and the view (aka: the navigation and flow of the user interface, vis-à-vis information architecture).

enter image description here

If UX comes back and wants a certain design, flow or interaction, it is the controller's job translate those intentions into the model. It is also the controller's job to translate data into the layout defined by the view.

If you wanted to shoehorn the two process you describe into this architecture, and run their development in parallel:

  • Model => Software Architecture job
  • View => Information Architecture job

The controller glues them together and can't exist until both a defined. So, in a perfect MVC world the two still never had to worry about intersecting because the application architecture properly separated them and allowed them to be bound together via the controller.

The Process Has Begun, Now What?

We always know the world is not perfect, and the UCD process does not always fall into place. So, what happens when things are already underway?

Based on comments below, it appears we are:

  • Already underway with Software Architecture
  • Just starting, or early in, the Information Architecture process
  • Using MVC

So, where do we intersect? Ideally, immediately. Take the "perfect world" above and just bring the software architects into the Information Architecture process right away. Let them be a part of it and illustrate to them how the user's see the world. This will do a few things:

  1. Allow them to change their architecture as appropriate.
  2. Allow them to get a glimpse into how they will go about glueing your view to their model (MVC).
  3. Allow them to offer alternatives if your IA suggestions just doesn't fit and updating the SA is just not possible.

By including them immediately you avoid butting heads at the intersection and everyone gets to feel a part of the entire process.

If we're a little further down the line, or SA doesn't want to participate with IA, where do we intersect?

We're using MVC (per comments), so the intersection is when the controller is written. The power of the MVC (or similar) architecture is that the view and the model are separate. Because SA put "this here, and that there" does nothing to dictate how you organize the IA of the final interface. The controller figures this out for you.

The controller is perfectly capable of translating "A into B" and "2 into 3". Mappings can become confusing and code can become more difficult to maintain, but this is never revealed to the user. The software developers hate you (they normally do) but the users love you.

Reducing the complexity of the code is why communication should be constant from the earliest possible step.

A Quick Term Breakdown

Another comment leads me to believe there is some confusion in terms. So here is a bit more...

Software Architecture and Information Architecture are processes.

Model-View-Controller (MVC) is a software architectural pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user. (from Wikipedia)

The model, the view and the controller are all components of that pattern.

The model is a product of SA (and other details). The view is a product of IA (and other details). The controller is a product of getting the model and view to properly interact with each other.

The components of MVC are not "part" of any process, they are the ultimate end results. So, the controller is not "part" of "interaction and flows". Interaction and flows are defined by the IA process and are implemented into the view.

To double back and focus on some key points.

  • Communication should be constant.
  • IA and SA should never diverge to require "intersection".
  • If they've diverged, regain communication ASAP. The absolute last rationale place for an intersection (in my opinion) is when the controller is developed to glue the view and model together.
  • Good answer... minor typo, the phrase is "Hail Mary". Tried to fix it but SE wouldn't let me make a change of just 1 character. :-/ – ElBel Oct 23 '14 at 21:43
  • Nice answer. However, model (system model in Norman's terms) is also partly defined by the information architecture. I tend to say (as a former Technical Architect), that "UX is how the system is experienced by the user" - which involves its internal skeleton as well. For me, IA should start a bit before we even let developers think about how to implement it, like, either bringing them to the research trips as a first act or meet them at the first research presentation. – Aadaam Oct 24 '14 at 8:44
  • Hi @EvilClosetMonkey thank you for your answer. But I still have a doubt. You wrote that there isn't the intersection : "They never intersect, as described, at a single "hail mary" point. " But, here you explain that has : "Software can being architecture at this point too, because they have clear direction via the Strategy and Analysis stages. In the very least, they should be included in the information architecture process, so they can be seeing how it is working and begin to scope their process accordingly. " Where you show at the UCD Methodology. But my greater doubt isn't... – MPossel Oct 24 '14 at 12:52
  • the Methodology. 'Cause I use it, but is where there are many engineers teams and only one UX designer. Where the development team already started their job. This is not a ideal world, but it happens here, at my region, where doesn't have the conscience about UX, this is very new, and aren't all the people that know what the benefits that has with using UX. – MPossel Oct 24 '14 at 12:53
  • @Aadaam, I totally agree. A "top-down" architecture where UX and Software Dev. are both involved is my preferred approach. The second paragraph in the "Design" bullet under the UCD picture tried to get at this. I'll read it over again and try to make it more clear. – Evil Closet Monkey Oct 24 '14 at 15:16
0

I disagree that this is a project management question. To me, this is more "defining the damn thing" or DTDT, as we say in the UX/IA world. We are forever trying to decide on labels, which can be exhausting but is important.

For most of my 18 years in UX and IA work, I've called myself an information architect. That's partly because much of my work has included modeling structured content, defining it, and naming fields to be created in a to-be-installed content management system. Then the developers know what fields to create, how they should be set up, and what the content entered into them should do. It's also partly because I invent (or repurpose existing) taxonomies to set up automated relationships between structured content behind the scenes.

That's all in addition to designing site structure and navigation. I also do traditional UX work: stakeholder interviews, contextual inquiry and other user research, task analysis, prototyping, usability testing, etc. Also, all the interaction design at the page level.

There are many ways to define "information architect," so the answers you get are going to vary widely. In my world (which is almost all very large websites 10k-60k pages), the overlap between IA and SA is biggest in these task/skill areas:

  • Identifying & designing all unique display templates for a site or application.
  • Designing & documenting how data templates feed into/build display templates.
  • Modeling structured content for a content management system.
  • Creating taxonomies for content reuse & specifying/documenting how taxonomies will be used.
  • Designing & documenting how the site's structure on the back end (e.g., pseudo folders? site tree? all-in-one db?) feeds/builds the navigation and any other wayfinding controls, like breadcrumbs. Ditto for the URL.

I do all of these things. But I've worked with development shops that prefer to do all this. I've also worked with dev shops that don't even know these things are necessary until the 11th hour and then fly by the seat of their pants. It just depends on the culture, process, strategic goals, and leadership of the shop in question.

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.