embracing our goals together

[Thomas Pfeiffer]

On Thursday 29 March 2012 14:16:43 Aaron J. Seigo wrote:
> hi...
> 
> listening to the various people involved in the creation of new bits of UI
> in the shell, it seems that people concentrated on or were distracted by
> various issues and "let's make a pleasing and elegant UI" got lost.
> 
> here's the hard and uncomfortable reality: when i first saw the new UI
> changes, i instantly realized i could not show it to others and be proud.
> it was not up to the standards we had shown ourselves capable of in the
> past. it was, in a word, embarrassing.

Could you please indicate what other UI parts you are referring to? We have 
improve all of them, then. Imo it would be ideal to discuss each problematic 
UI separately, though.
 
> this is not limited to the Activity Settings UI, but when looking at the
> result of the work on the Activity Settings UI and then listening to various
> people involved, here is what i noted :
> 
> * there was a lack of consensus around the implementation
> 
> * the reasons why certain things could/could not be done was not well
> understood by everyone (both technical requirements as well as UI design)

+1
I know that I don't completely understand the technical requirements and I 
suspect that some developers did not completely understand the reasons for 
some of our design decisions. Not because anybody is ignorant or stupid, but 
because we didn't explain them to each other well enough.

> * there was a feeling of conflict between the different people involved, a
> feeling derived from the belief that different people had different goals
> that could not be harmonized

I can only speak for myself here, but I don't believe that members of the team 
have different goals. Different priorities, maybe, but personally, I don't 
perceive an actual conflict of goals.

> put bluntly, people focusing on UI design did not fully appreciate the
> technical hurdles and those working on the technical requirements seemed to
> view those working on UI design as obstacles in the path to implementation.
> 
> 
> 		the result was something nobody was truly happy with.
> 
> 
> this leads to a shocking question:
> 
> 		if no one involved in the creative process was truly happy with it,
> 			how did it become the result of our efforts?
> 
> it would be easier to understand if someone in our team thought it was the
> best UI ever; but was anyone truly, deeply proud of that result? did anyone
> feel that "awesome!" feeling when it was finally completed? or did everyone
> feel they'd compromised somehow, producing something dominated by the
> weaknesses of the compromise rather than by the strengths of an answer the
> team came up with together?

It does look like a product of compromises to me as well. And compromise is 
rarely a good thing in UI design. Yet it's something likely to happen when 
people grow tired of discussing and just want to "get it over with". And this 
is what seems to have happened for many - or all - of us here.
Or, to use another term: What we did here was design by committee, which is 
pretty much always a bad thing.

> we need to remember that we have a shared goal here:
> 
> 	to make an elegant user experience that supports life's activities
> 
> that trumps everything.
> 
> 					EVERYTHING.
> 
> there is no implementation principle that is more important than that, there
> is no design concept that deserves attention before that goal is
> understood.

+1
And that requires *lots* of effort in creative thinking from all those involved 
to overcome technical obstacles while minimizing the impact on the user's 
experience. 

> technical issues and design decisions are the tools to reach that goal, but
> they are not the goal in themselves. we each have unique tools which we
> bring to the team so that we can reach that goal together. our individual
> skill sets are not to be used in conflict, but to create a coherent
> direction that brings us to our shared goal.

Yes. And this requires lots and lots of communication, as direct as possible, 
and coordination of efforts. And maybe - I barely dare mentioning it - some 
kind of processes. Lean and flexible processes, of course, but it seems to me 
that "wild-style" does not work here.
And I have an idea for that (or, to be exact, I present someone else's idea) 
which I will post in another email.

> that was seemingly lost in the creation of this particular UI component, and
> it showed starkly in the results.
> 
> having thought about it some more, i regret having proposed a set of
> improvements as i did.

It was good that you pointed us to the need of improving the dialog.

> it would have been better if i had first asked you if you were truly happy
> with the result, and if not what you would do to improve it. once
> improvements had been found by working together, we could then have
> reflected on the differences in process that got us from "nobody is 100%
> happy with it" to "something that is elegant"

+1

> i squandered that opportunity in my desire to "simply fix it", but we still
> have an opportunity to reflect and learn.
> 
> i invite each of us to think a little on how it came to be that lines were
> drawn between "the UI designers" and "the people doing the implementation",
> how undesired compromise overcame elegance.

I think this is not that uncommon. Designers and developers naturally have 
different perspectives on things. This is supposed to be a blessing, but if 
there is not enough _effective_ communication between them, it can become a 
curse. And too little - or, probably more likely inefficient - communication can 
happen easily if the only medium used for communication is a mailing list.
A mailing list is great - and actually crucial - to keep everyone informed, 
but it is not a good medium for designing things collaboratively.

> this is not an invitation to blame others. instead, let each of us consider
> our own contribution: how did i chose to interact with others? what
> opportunities for consensus were missed? how did communication between
> requirements and design broke down?
> 
> and remember: the problem is not the result. the result can be improved on
> through iterative input and effort.
> 
> the problem is the process. we know how it can work, because we've done it
> many times already with really good results.

So true.