Monday, June 27, 2011

Project Management: UI

One thing I struggle with both as a developer and PM is UI. There are two particular examples for my history as a PM.

The first project was for an iPhone app where the client asked us to take their comps and make them more iPhone-friendly. Our designer took their concepts and made what I thought was a much cleaner, usable interface. Unfortunately the client didn't like the design and we went through several more iterations of updates, each side getting more and more frustrated as our ideas weren't converging. In the end it became obvious that the client always wanted their original concept/layout but were just looking for us to create nicer UI assets for the implementation.

The other project was a web application in which the client was extremely picky about the web site matching their comps pixel-for-pixel. The client did come up with a very nice design and provided us with very detailed comps so their pickiness wasn't completely unwarranted. As a PM and someone who doesn't easily pick up on UI design issues, I did not do a good job of vetting our implementation of the design before sending it on to the client. As a result a lot of time was wasted in back-and-forth communication to work out small UI mismatches.

So how could I have avoided these situations? In the first case I think it was mainly a matter of communication. I interpreted the client's instructions as giving us free reign to generate a completely different implementation of the client's concepts. In the future I will make a point to thoroughly discuss with the client what they are looking for when asking us to do UI work.

In the second case I think it's just becoming more aware of UI issues in general. It was obvious from the start that the client didn't want much/any deviation from their comps. But the web application was packed with functionality and as a developer, functionality is what I find interesting. In contrast, I can't just look at a label and tell what its font styles are and if they match the styles in a comp. In the future, I think I just need to consciously check for these type of issues, along with learning/practicing more design in my own side projects. I will also be more aware that a client that gives us detailed comps will probably be particular about how those comps are implemented.

One other step that I think would help in such a case is getting the general HTML/CSS layout in place and signed off by the client before beginning to implement any major functionality. Such a workflow would really make HTML/CSS changes easier rather than trying to force-fit changes later on in the project.

The folks at Herding Code recently had a very interesting podcast on situations like the second project I described here.

2 comments:

Rick said...

Hi Ryan,

Yes, someone is reading your blog! I will have to subscribe now that you are updating more often.

Thanks for the new-to-me links to 1) podcasts at Herding Code and 2) QuirksMode. I can walk to work most days and I listen to various tech podcasts. More than a little geek in me...

I sometimes read Rands and have the Managing Humans book. I will have to get back in the habit of reading his blog.

rmb177 said...

I'll do my best to keep writing :)

Some other good development podcasts:
- http://www.hanselminutes.com/
- http://www.dotnetrocks.com/
- http://www.thisdeveloperslife.com/

A very interesting podcast, though it's not developer related:
http://www.radiolab.org/series/podcasts/