FileNet ECM Administration
Building a fully accessible web application to administer FileNet ECM.
Allow people with disabilities to use FileNet ECM
IBM FileNet ECM is consistently ranked as the market leader in Enterprise Content Management. However, IBM was experiencing some resistance selling to government agencies because the FileNet ECM administration system (built on Windows) was not accessible to people with disabilities, per Section 508.
Administration Console for Content Platform Engine (ACCE)
ACCE is a fully accessible web application to administer FileNet ECM. Government agencies can now purchase FileNet ECM without hesitation, knowing that the product can be used by all of their employees.
I was the UX Designer on this project, responsible for all user research, interaction design and usability testing. My methods and deliverables included:
- Stakeholder interviews
- Competitive analysis
- User interviews
- Contextual inquiry
- Task analysis
- UX strategy and planning
- Information architecture
- Design workshops
- Interaction design
- As-is/To-be scenarios
- Low to high-fidelity prototypes
- Functional specs
- Usability tests
The design team within
Building a multidisciplinary team of designers and fostering collaboration
I realized early on that the scope and complexity of the design task was beyond what I could do by myself. Sure, I was already a member of the project team, but the team was too big to effectively discuss design issues. So I rounded up our team leads and deputized them as official UX Designers. I even gave them certificates. And this was the smartest thing, because over the course of this project my "design team" met every week and we came up with some fantastic ideas together.
Understanding the legacy admin system so we can improve it
The legacy admin system was a sprawling beast that no one on the team fully understood. In order to wrap my arms around it, I reached out to experts who helped me document its overall structure, navigation, key objects, and relationships between objects. This document (excerpt below) was invaluable as a quick reference throughout the project.
There were many elements of the legacy system that would not be needed in the new web app.
I brought a group of our target users (FileNet Admins) together so the team could hear their experiences using the legacy system.
Our users told us about their tasks
These tasks can be expressed simply in terms of creating and managing objects
Scenarios for creating and managing objects (based on how users do this today)
The scenarios below show that each object in the system is created using a wizard, each is accessed via a list and a tree, and each is edited in a form. Understanding these fundamentals of the legacy system helped guide our design decisions moving forward.
Observing users leads to key insight
While observing admins use the legacy system, I noticed they sometimes stumbled when working with child "pop-up" windows, particularly when the windows were minimized.
- Users forgot which window pertained to which object.
- Users forgot that windows contained unsaved data.
- Users pace of work slowed when dealing with the windows.
Every object in the system was jammed into one of these windows, resulting in a cluttered and confusing experience.
The design team sketched different solutions to the "child window" problem.
A winning design emerges
We decided to embed the child windows in the parent window as navigational tabs. The tabs would collect in one very visible location and the system would indicate which tabs have unsaved changes. Problem solved.
Not so fast
On closer inspection, we saw that simply navigating the system would generate lots of tabs, cluttering the screen and adding to users' cognitive load. We saw that the tabs would become more difficult to use when the tab labels were truncated. And we saw that users would have to close tabs that were no longer needed, adding to their work.
We agreed to move forward with the design, but without the tabs.
Our research told us that the legacy system relied heavily on a few UI elements, i.e.: lists, wizards, forms and a tree. For the new web app to be successful, it would need to adapt these elements to a web look and feel, as shown in my wireframes.
Here's how I fit the elements together.
I conducted usability tests (lab-based and remote) at various stages of development. My early tests confirmed that our design was intuitive and even cheered by users.
What the new design accomplished
Our new window-less design improved on the legacy system in many ways.
Circling back with users yields new insights
We had removed lots of windows — which was a big win — but this limited how users navigated the system. They liked being able to open multiple objects and “bounce” between them. For example, users liked that they could enter data into a wizard, then leave the wizard, grab data from another object, and return to the wizard without having to start over. This functionality was a huge time-saver and we didn’t want to lose it.
In order to make the navigation more flexible, I suggested adding a “Recent” feature so users could easily return to recently viewed objects, including work in progress.
I worked closely with other UX and UI designers throughout this project to ensure that the finished look and feel adhered to IBM guidelines while staying true to the original design.
- Built a multidisciplinary team of designers.
- Collaborated with experts to understand the legacy admin system.
- Interviewed users as a group and individually.
- Conducted contextual inquiry leading to key insight.
- Iteratively sketched and wireframed solutions.
- Created prototypes.
- Conducted lab-based and remote usability tests.
- Noted many improvements over the legacy system.
- Talked with users and discovered new insight leading to addition of "Recent" feature.
- Released on schedule.