aparna sanaka — Tue, 08 Dec 2009 03:15:18 GMT

Thanks Anthony for the article.
Although, you wrote this article a year back it is very relevant especially given the dynamic nature of the UI design teams.
The talent / creativity, the range of expertise, the requirements themselves everything make / break design teams. No matter what people say – design teams are tough to manage especially for the long haul.

For the “innies” working with the “outies” in situations where there are multiple vendor scenarios – so much more complex, similarly in an offshore-onsite model / virtual teams (given the distance factor) these challenges are ten fold.

As a manager in a large Bank leading an “innie” UI design team as a ‘vendor’, working with an offshore team (in a virtual team model) plus working with “outies” at times – I find the need for the right “personalities” the most crucial point to “run” the team leave alone make it a “dreamteam”. I completely agree on the “toxic” personality mix in a team – it is an absolute pollutant to the atmosphere be it for creativity, growth, collaboration or plain functioning as a team on a day to day basis.

Challenges:
1. What if as a ‘vendor’ one does not have the luxury to choose it’s team – be it ‘hire’ / build the team with in-house resources?
2. What if one is saddled with a ‘toxic’ resource – the political scenario not allowing ‘jettisoning’ the toxic resource?
3. What is the best way to make things just “work”?? A dreamteam is a still a distant pipedream at this point?

My question to you Anthony is – is there a rationale solution to this problem?

aparna sanaka — Sat, 05 Mar 2011 05:53:44 GMT

Thanks for the article Aaron. A very good depiction of comparisons amongst current tools in the market – very informative.

In my experience, over time I have used several different ways to create wireframes – right from Word (cons – formatting issues and would crash every now and then), Excel (seems weird but tabs helped – downside cannot print it all in one go!), Visio (did well for most part) until clients bought newer products – Axure, iRise being some of them. ‘Wireframes’ are more detailed followed up with interactive javascript based HTML prototypes or HTML outputs from Axure / iRise.

Although, I sketch a lot like Maria in notepads one of the best ways that worked really well with the ‘clients’ was a quick drawing of a succession of screens on flipcharts (to depict interactions) – great for discussing ideas, allowing the client, stakeholders, focus groups a ‘freehand’ to mark out the good / bad points on the actual ‘paper prototype’ – the immediate pros were that the client, stakeholders were more ‘involved’, would be more open about their thoughts – overall very interactive sessions and best of all actually had quicker sign offs.

The next thing that was a shade better than a ‘paper prototype’ in this context which worked equally well was ‘Balsamiq’ – a quick and dirty way of creating the first initial ideas – a sort of a kickoff session on ‘ideas’ at hand. A great tool to have in th realm of ‘sketchy wireframes’. The clients review the JPGs / images (saved using Balsamiq) and then go over their initial thoughts in a meeting.

I think what happened over time is that clients started “expecting more” from wireframes – to ‘see’ the closest thing to the real application – simulating interactions. Hence, the sudden influx of wireframing tools in this “sketchy wireframing’ space. By far what is important to know is ‘your’ work environment and what really works best for you to complete your task effectively and quickly. To ‘adapt’ and make the best of what’s available in the market and get the best results in the shortest time frame.

Boxes and Arrows: Comments by aparna sanaka