Here's how you can recover from a failed Information Architecture project.

Failed is only when you stop. Just keep throwing money at it and keep it going, and call it “slipped”. That’s how the big ones seem to be doing it anyway 😂😂😂

Actually I agree with this notion of acknowledging failure, possibly that may lead to better processes for handling errors or avoiding similar roadblocks. I usually say you can acknowledge failure but not accept failure.

Remember to assess both quantitatively and qualitatively. How much did it fail; it won't be binary. Which elements failed, and how badly, which succeeded and how well (can they be improved further). Were the failures a consequence of design, implementation or adoption. Were there singular failures or cascading causes? Was everything right, except for the timing. Is blame appropriate; even if it is, is it helpful. Are the insights from the analysis actionable. If not, look and think again.

accepting failure as part of our job is essential but not without learning from it . Failing cheap is still a win as the gain from the knowledge acquired replaces that failure on the long run Identify failing parts and success ones Pin point the failing reasons, revisit the data gathered and research redo the observation and discovery phase and keep the successful part

Yes, I agree with the approach you've outlined. Acknowledging failure is crucial for growth and improvement. By recognizing that failure is part of the learning process and focusing on understanding the issues without assigning blame, you create a constructive environment for analysis and future success. This mindset helps in identifying the root causes and developing strategies to prevent similar problems in future projects.

1. Check if there is a process model of the core processes in place. Likely not... 2. Create one, analyze one, and assess the resources available. many, many other things ...

Como parte de eso, ¿Qué lo hace un fracaso? que indicadores no satisfizo para que sea considerado fracaso, y contra que elementos se esta comparando que si cumplen y que por darle prioridad a esos, se descuido los otros

Acknowledging failure in an Information Architecture project is crucial for recovery. Create a safe environment for honest evaluation without blame. Conduct a thorough post-mortem with all stakeholders to identify root causes. Document lessons learned, including technical and process-related issues. Identify any positive outcomes to boost morale. Communicate findings transparently to all parties. Develop an action plan for immediate fixes and long-term strategies. Embrace the failure as a learning opportunity, fostering a growth mindset in the team. This process sets a strong foundation for recovery, addressing current issues and preventing future ones. It also builds a more resilient team culture.

Own It first, Admit that the project didn’t go as planned. It’s okay; everyone makes mistakes. Be open with the team about what went wrong. Honesty fosters trust and team cohesion. Focus on learning, not blaming. Everyone's in it together.

Na minha experiência, reconhecer uma falha é um passo crucial para o crescimento e melhoria contínua. Houve um projeto em que trabalhamos na Alphacode, onde encontramos dificuldades com a Arquitetura da Informação. Inicialmente, houve resistência em admitir que havia um problema, mas uma vez que aceitamos essa realidade, conseguimos identificar as causas subjacentes e implementar soluções mais robustas. Esse processo nos ensinou que a aceitação é fundamental para a evolução. Não se trata apenas de apontar falhas, mas de entender profundamente os erros e usá-los como uma oportunidade de aprendizado e inovação. Assim, podemos evitar problemas semelhantes no futuro e fortalecer a resiliência da nossa equipe e dos nossos projetos.

In my experience recovering from a failed Information Architecture (IA) project begins with a thorough analysis of the failure's causes. Identify specific issues such as user confusion, poor navigation, or misaligned content structure. Engage with users to understand their pain points and gather feedback. Use this information to develop a revised IA plan that addresses these problems. Simplify complex systems and realign the structure with user expectations. Implement changes iteratively, testing each modification with real users. Seek continuous feedback and be prepared to make further adjustments. This iterative, user-centred approach helped in recovering and creating a more effective IA.

Understanding where the project went went wrong is crucial. Learn from past mistakes and find ways to rectify them. Lean on your partners and stakeholders to find the solution with best chances of success.

It's time to step back and try to figure out where you went wrong. Usually, the difference between the data collected and the data you expected will give you some idea of where you went wrong. Also, the erroneous data may still be useful for a different part of the project or at least remind you how things could go wrong.

genial, solo le agregaría los objetivos y metas esperados por la gerencia y el contratante, para asi ver los factores de no cumplimiento

Relevance realisation is hard to get correct. Users will always be tasked to take part in a continuous business process (with in the product and outside of it). In this dynamic context what relevance has to be hi-lighted in each screen and transition has to be aligning based on the dynamism of the business and its priorities. Empathise and imagine the process sequences and possibilities considering the dynamism will help you to visualize the hierarchy based what is relevant in that specific context for the end-user.

I agree with this approach as well. It emphasizes the importance of understanding the root causes of the failure and using this knowledge to make improvements, rather than merely recording the problems. This proactive and analytical mindset is essential for continuous improvement and successful future projects.

Analyzing causes of a failed IA project is crucial. Key steps include: Review user research and feedback Evaluate data architecture and content organization Assess IA development process Examine stakeholder communication Analyze alignment with business goals Investigate technical constraints Evaluate user testing methods Review resource allocation Focus on finding actionable insights, involve all stakeholders, use data-driven approaches, consider internal and external factors, look for patterns, and remain objective. The aim is to create a targeted plan addressing specific issues and preventing future failures. This analysis forms the basis for effective recovery and improvement of the IA project.

Start by Gathering Feedbacks, Talk to the team, users, and stakeholders. Understand their perspectives. Identify Patterns, common issues in the feedback. Dig deep to find the actual reasons behind the failure. Was it a process issue, lack of resources, or something else?

Creo que el ítem anterior (las causas) y la revisión de la investigación preliminar deberían darte una respuesta, aunque sea parcial, de lo que pudo haber pasado. Es difícil generalizar en este tema, pero cuando me he encontrado con este tipo de problemas, ha sido porque el cliente no ha podido explicar bien sus necesidades y nosotros no hemos podido entenderlas. Al equipo de diseño se le exige que comprenda todo tipo de industrias, pero los clientes muchas veces no colaboran o no pueden salirse del mapa mental de su industria. Otro motivo de fallo que he tenido, es dedicarle pocas horas al proceso de entrevistas y flujos de tareas, ya sea por el limitado tiempo y presupuesto del cliente, lo que terminará redundando en el resultado final.

This version keeps the core message while expanding on the importance of aligning IA with user research and ensuring decisions are data-driven.

Solo si de lo anterior se llega a un nivel de profundidad para que esto se requiera. No creo que esto debería ser lineal, Pensamiento de diseño, funciona un pequeño cambio¿? probémoslo, hagámoslo! y que otro momento, o equipo con más tiempo y recursos haga el camino largo.

One issue that can lead to the failure of an information architecture is misalignment with the mental model of users. Before wireframes or prototypes, consider high level concept diagrams that illustrate the boundaries between systems or processes involved. Validate these concepts with stakeholders and users. Iterate as needed until you have alignment. (I’m often shocked by how skewed the understanding of business objectives can become at startups and fast moving organizations before they mature.) These diagrams can also be helpful with training and onboarding new employees… Once you have these diagrams in hand you can consider which key flows will have the greatest impact on the business, and begin to wireframe and prototype.

Redefine goals using new insights. Restructure information hierarchy and improve navigation. Create wireframes or prototypes to visualize changes. Involve stakeholders throughout to align with user needs and business objectives. Consider scalability and future growth. Incorporate feedback mechanisms. Key points: Use data from analysis to inform decisions Apply user-centric design principles Ensure flexibility for future content Balance user and business needs Validate design choices through testing This phase transforms lessons into actionable improvements, laying the ground for a more effective, user-friendly IA. The redesign should address identified issues while creating a robust framework for ongoing optimization and adaptation.

Remember, there are almost never any perfect information architectures. Anything resembling true hierarchical taxonomies are almost certain to be flawed. The key to making this all work is identifying a workable compromise. Often this means realigning expectations of staff, who frequently don't understand IA at all well, or who fail to appreciate up- and down-stream impacts of their local needs or desires. Prioritise - compromise - persuade.

This version emphasizes the importance of using new research to inform the redesign, involving stakeholders, and ensuring alignment with both user needs and business objectives.

Acá me gusta mas que todo la actualización de los documentos. que quede en algún lado, que se hizo, porque se hizo, quien lo hizo, y que conlleva

Reframing Goals by adjusting objectives based on what we’ve learned. Be realistic and clear. Collaborative Planning by Involving the team in creating a new strategy. Their insights are invaluable. Simplify by breaking down complex problems into manageable tasks. Make the strategy lean and focused.

My experience for managing the redesigning the Information Architecture Strategy; 1. Define new goals - use insights from fresh research to redefine the goals and objectives that align with both user needs and business objectives for a cohesive strategy. 2. Redesign and restructure navigation - simplify and organise content to enhance navigation and accessibility. Engage stakeholders throughout the redesigning process. 3. Create prototypes - to visualise the redesigned architecture to help in understanding the new layout and functionality, making it easier to identify potential issues early. 4. Facilitate ongoing stakeholder reviews - regular feedback sessions can help align expectations and refine the strategy.

Test the areas that failed to confirm that the intended fixes/redesign/improved processes have addressed the issue(s). Then take a step back and look for other consequences of the change to confirm that you haven't pushed some other elements of the IA into failure.

In my experience, it's crucial to integrate these steps cohesively throughout the redesign process to ensure that the new IA meets both user needs and business objectives.

This is key. Test and observe. Add test scenarios, test and observe. Questions to ask yourself - Does it all still work? - Are you implementing work arounds to keep it working - Is it getting difficult to see what is going on. When trying to work out if your ideas work, pick the common scenarios then get more and more intricate. When does it get too hard? When does it not work and why? Then simplify, reiterate, test, and improve.

Cant stress this enough. The best way to make sure an IA is good is by testing and iterating repeatedly. Tree tests are quick to create and give results fast. Do multiple iterations of tree tests even before diving in low fidelity/wireframes. It will save you and the organization a lot of time and resources.

Create quick, low-fidelity prototypes to test new ideas. User Testing is vey crucial, Get real users to interact with the prototypes. Gather their feedback. Iterative design is key, Refine the design based on feedback. Repeat this process until we get it right. Stay Flexible, Be ready to pivot if something isn’t working. Adaptability is key.

All that has been shared in this article is spot on. I would not agree any less with point number 6, which is flexibility. Learning to expect failure and considering it in the planning phase is the new normal. The reason I say this is because the speed at which technology is adopted is different across user groups and there is a consistent pressure of ensuring the IA meets the right balance. Just like technology IA also needs to evolve and needs ongoing review and iterations possibly every quarter to keep up with the speed at which technology is changing. Track failures to learn and adapt! It is wise to adopt a technology platform which will allow rapid changes to IA and its implementation on an ongoing basis.

On top of the already mentioned perspectives, a very important question to ask yourself is the following: How much were the decisions in the project based on data-driven testing and UX research and how many gaps were filled by personal decisions? Similar to the first question, one always need to critically evaluate how general the UX research was, for example did the user base that contributed to decisions and tests, was fairly heterogenous? The number one pitfall is overreliance on "quick fixes" and users with very clear habitual preferences. Finally, if there is confidence in the process, the final question to be asked is: maybe the scope was too extensive? For example "we can solve everything with IT" is a very risky approach.