Most software product managers (aka: referees) that I’ve worked with are sensitive to both the creative and technical natures of  UI projects.  They can help teams mitigate the misunderstandings that happen when humans work with each other, such as:

• Questions about requirements could feel like alien invaders probing for weaknesses
• Constructive suggestions might be taken as a good slapping with heavy criticism
• Exciting ideas might be heard as threats of new gnarly work if approved
• The needs of the end user could be seen as hilarious problems for another day

So product managers, this one is for you.  You see the user acceptance gain with the internal pain, even though the balance of the perceived heavy slapping may be in – or completely out of – your hands.

But it also turned out, that the majority of the client stakeholders were puzzled as to what PixelMEDIA was providing. They didn’t understand what Information Architecture was, and hadn’t even thought about the overall user experience for the product. Yet, they had requested an IA. How odd.

The understanding was that we were to immediately dive in and create a series of wireframes outlining the key screens for the application. This proved a difficult place to start, as we didn’t have (a) a clear design objective (b) we didn’t know what the users needed to do or (c) how the new product would help them do it better and more easily than they imagined possible. At our request we rewound a bit, and after a few meetings, all parties agreed on the basic design objective, which enabled us to ensure the customer’s needs, the brand, and the business objectives were balanced and clearly articulated.

Next, PixelMEDIA took the initiative to craft a set of task flows. This was an interesting decision, because we didn’t think we’d need to create such documentation for the project; but taking this step provided everyone a deeper insight into how we could craft a new experience as the design process continued. We focused our efforts on outlining the user’s primary goals and how they would achieve them in order to form the core of the application’s design. This allowed us to focus on the features that matter most to the customer. The task flows provided a visual mechanic that showed gaps in the requirements documentation, as well as providing a way to further the vision and understanding of the application.

Once the task flows were completed and approved, PixelMEDIA began designing the experience’s basic framework. We kept the requirements focused in a set of wireframes that outlined a typical scenario, to visualize how the customers would walk through the application and achieve their goals.

The client has been exceptionally pleased with the work to date, and PixelMEDIA has developed a more strategic partnership by bringing the project solution to completion. As the wireframes portion of the project nears completion, all parties feel that the resulting solution provides a more elegant, simple and streamlined experience for the customers.

Or in the customer’s own words:

We are obviously very new at some of this stuff and a large part of why we chose to go with PixelMEDIA is because we were confident that you wouldn’t just throw a design over the wall; rather, you would work *with* us, regardless of the fact that we would slow you down. We’re all learning quite a bit from this experience, and I for one am very impressed by what you guys have done and how you’ve helped our team figure out which direction we should try to head in.

By thinking less tactically and more broadly, PixelMEDIA has been able to educate the client on the importance of Information Architecture, and helped the client identify what their customers needed most from the application.