Many of you are making consumer web interfaces. I'm guessing you like me, get very critical feedback on them since anyone can easily be a critic. Having done several sites in the past, and worked with / and without "bootstrapping" I've taken different approaches: DIY, hiring experts, etc. One issue i've found is that only YOU really know your application and designers often want to "change everything". I think working with designers has been of limited help whereas getting more userfeedback and iterating quickly myself has driven better results. Anyone have PROCESS tips, tricks, suggestions or other thoughts about effective UI improvement?
[+] [-] duopixel|15 years ago|reply
> I'm guessing you like me, get very critical feedback on them since anyone can easily be a critic.
Handling critical feedback is one of those soft skills that are honed by time. You must learn how to separate useful from pointless feedback, and you must not associate it to your own person, as in feeling worth less over negative comments.
Most design feedback is irrelevant, if you implemented it your product wouldn't be any better or worse. A little bit is beneficial or harmful, and it is important that you are able to identify which is which.
You might think that people with more experience are able to give better feedback, it's partially true, but it all boils down to having solved similar problems before. Trust advice that starts with "I once did something like that and..." or such.
> One issue i've found is that only YOU really know your application and designers often want to "change everything".
In the end, what matters is that your users get it, not you or the designer. Programmers often design systems that closely represent the structure of their application, or take shortcuts because something that makes sense to the user is difficult to implement so they scrap it.
> Anyone have PROCESS tips, tricks, suggestions or other thoughts about effective UI improvement?
Hallway usability testing is your best bet. But don't ask people what they think, assign tasks and watch them complete them. Clarify that what is being tested is the interface, not the users. It's hard, but suppress urges to direct them.
[+] [-] gallerytungsten|15 years ago|reply
When working with an "amateur" client who doesn't understand much about design, it's helpful to prepare a design brief before beginning any work. This is a written description of the goals of the project. When you meet with the client initially, they will probably have a lot of vague or even contradictory ideas. It's your job to sort through the ideas and write up a design brief. Show it to the client, and either get them to sign off, or revise as needed.
Going forward, when reviewing comps, try to steer the conversation back to the goals you set in the brief, and discuss how well the comps are meeting the goals (or not).
Try to avoid letting them offer solutions like "make this font bigger" or "make it blue." This transforms you from a designer into a computer monkey. Clients who treat you this way are disrespectful at best, and are best avoided entirely.
To append to that answer, your insight about "only YOU really know your application" is analagous to the concept of the "design brief." Design is not only how it looks, but how it works. The brief should explain this, so that when working with a designer who is focused on the visual, you can always bring them back to the brief, and ask how their visual changes support the brief.
[+] [-] delano|15 years ago|reply
http://blog.bumblebeelabs.com/the-5-guerrilla-user-test/