Here is one the of the best presentations I came across when I was initially searching for an introduction to UI design for programmers.
Ryan talks about how UI is not a separate layer but is a part of the software and the most important from a customer perspective. For a customer the UI is the application!
Ryan talks about the key elements of design which helped me streamline my thought process about a design.
1. Modeling
2. Screens (Inside-out Method)
3. Flows
4. Templates
I believe programmers in your companies would definitely appreciate a perspective on UI design and it would only help your future interaction with them.
Thanks for sharing the video, Teja. In the web department I'm a part of, I've always found the "contrast" that exists between programmers and designers to actually be a very productive one.
ReplyDeleteLike you mention, I definitely think there is a benefit to having programmers be more informed of good, UI + usability principles when they are tasked, for example, with developing interfaces from a loose base of requirements.
However, I think there is a programmer "back-end" mentality that simultaneously helps designers when producing more specific interface specifications. Recently, I was working on designing a blog "widget" for use across the cfr.org site that would pull the RSS feed of a CFR-related blog and display certain information from the latest post, e.g. title, date, author, image, number of comments, and latest comments... all in the name of freshness and creating incentives to follow through to the blog post and discuss. According to my specs, the feed would be requested using a PHP DomDocument load function... in a nutshell, the way I had produced my specs would result in a final widget that loaded the RSS feed upon every page view. Unfortunately, this would put a lot of stress on our server, particularly on days of higher traffic. The principal programmer in my department pushed back against this particular part of the specs when he saw them and instead suggested caching the feed and integrating feed content, for a set amount of time, into the database so as to reduce the amount of requests going on. What occurred here was the setting of an equilibrium between design-instigated "freshness" in the widget and technical "safety." Although this is a pretty basic example, and although I perhaps should have been paying more attention to the back-end requirements of the design, I think this anecdote emphasizes the fruitful relationship that can exist between front-end/UI/UX staffers and more back-end programmers... with the ultimate goal being merging technical expertise in the department to create even more seamless working relationships.
Good insight, Teja. I was introduced as the first interaction designer at my company a year ago and have had to "introduce" myself to the process with several different engineering teams. They each have their own ideas about design and I tend to find my comfort zone with each in matter of a couple weeks. There is nearly always a time when I have to argue science with them to trump a poorly placed component. Once I gain their respect and they feel comfortable relying on my expertise for the interface, I believe it takes some of the load off of them. I have my favorites that like to do UI and I generally give them much more credit when they suggest changes or alternative controls. Otherwise, I'm looking for feasibility and timelines and not generally suggestions about the UI, though I love to argue heuristics and test results. If I can't win an argument that way, I will generally concede to the highest ranking employee.
ReplyDelete