connecting*the*dots

Building a successful UX team — the right mix of roles, responsibilities, method, etc. — isn’t an easy task. It really does depend on the DNA of the organization (size, politics, legacy issues, etc.) and the type of domain (application, information centric site, desktop software, etc.).

Here’s a visual outline that I tried to follow at Ameritrade — an extremely secure, authenticated trading platform, with unique opportunities for collaborative filtering, interface customization, sussinct client messaging and knowledge management (both on the unauthenticated and authenticated areas of the site).

If I had to do it all over again, here are the top three things I would’ve done differently:

Reduced the emphasis on methodology
Due to the placement of the team in the org, the legacy of design within the domain and the lack of designer input in modeling requirement documents, I pushed to implement a flexible, yet smart, IxD Goal-Directed methodology. I probably would’ve still sought to implement a similar methodology, but I wouldn’t have pushed so hard to get it.

Introduced blogging as a means for knowledge sharing
KM is such a terrible term. In essence, an outward facing blog with a solid search engine and a rich tag approach could’ve served as both a conversation point for speaking with clients and providing answers to non-client account related questions. Internally, we could’ve dropped our stiff, architected KM tool with central controls and replaced it with internal blogs for every employee.

Focused on research, behavior, information contextuality, design and presentation
Editorial is *such* a complience issue within the financial industry, collaboration with designers on interfaces was beyond difficult to manage. I probably would’ve traded that card for the client-side team, where the rubber of behavior and design explicitly hits the road of server-side code.

Live and learn ;-)