In my top 10, I have resisted the urge to cover everything I thought was important or it would probably have become a "Top 326 tips".
That said, here are some of the core things to think about; the thought process, modern paradigms and so on.
1. Understand that design is about how things work, not just how they look
As Steve Jobs puts it: "Design is not just what it looks like and feels like. Design is how it works." Whether you like him or not, you can't deny the fact that this single-minded focus has made Apple one of the most valuable companies on the planet. Too often I hear people talk about design only in graphic design terms.
Let's get this straight, graphic design is not UI or UX design. UI/UX design is about usability, productivity, learnability and many more things that add bottom-line value to your app. If you can't assign value to your applications, I'd have to say that you should step away from them! Now that's a strong statement but how can you create a good app for users if you don't consider how they actually use it and examine their work flow? I've argued this with some people for years and they would say "Well anyone can get a 13 year old kid to add styling via CSS". While CSS can control layout to some extent, it cannot modify the flow of the screen as set out in the HTML. As a developer you need to understand optimal flow for data entry and look up. The position and context of information dramatically changes how users learn apps. Yeah sure, it's possible to learn to use even the most badly built app, but people have a choice and if you ' do it the right way your users / customers may vote with their feet. The methodology involved is not some ethereal skill learned by meditating in the high plains of the Atacama desert, there are logical rules and principals that can be applied.
2. Design with the device in mind
You can't apply the same rules to a desktop, browser, tablet and smartphone. You need to understand each device's strengths and weaknesses. Design your interface to work around issues and play to the strengths of any platform you are deploying to.
Desktop apps are rich and have a full set of capabilities for communication and access to the host operating system. In the case of IBM i apps you will need to consider things like keyboard buffers and type ahead, to ensure that users coming from an emulator are not slowed down by new technology (browsers can't do this by the way). So given the choice, I would usually point an existing desktop user to a desktop app. They'll get more functionality and productivity from the value you can add to this platform without being slowed down by a loss of features that they had in their old system. For tablet users, you need to think about the 10" screen and the fact that users will typically interact via touch. Don't assume however that this will make tablets a content-consumption device only, as users are now very familiar with the touch UI and extremely productive using it. There are a generation of people in college today who use a tablet as their primary device.
3. Different design for different needs
Are the users comfortable with the existing application (i.e. are they carrying baggage)? Are they experts in the subject matter or do you need to guide them through both the application usage and the subject matter? What level of mastery is required, do you need a simple system that is easy to use or one that caters for both first-time users and experts? You might want to revisit the role of function keys if you have expert desktop users. It amazes me that developers are often reluctant to use function keys, perhaps they are perceived as being an old-school emulator function. (Adobe Photoshop is the most graphical tool in the world yet in order to use it to its full capability you need all the function keys and most of the keyboard shortcuts. I regularly use about 50, it's not a fudge or bad UI, its incredibly productive). Moral of the story is: don't be scared of F keys for experts, just avoid them for average users and definitely for touch devices - hint, they don't have F Keys :-)
4. Pay attention to what users do, not what they say
This is about understanding how people work. Many users may be experts in the subject matter but they are not necessarily experts in app design. They can have individual preferences about the UI which may result in a reduction in productivity. Human preference is often skewed by experience and a fear of change. Design should focus on how it actually works. There are many cases in UI design where users express preferences which are counter-productive. One such example is text length. Research shows that, while users prefer to read lines of text at full page width, they are actually faster reading thinner columns of data.
5. Aesthetic has value. Deal with it, it's not going to make anything worse
While much of what I have already said focuses on how stuff works not just how it looks, there is no reason for it to look terrible. Firstly there is a strong pyschological advantage to making things look good i.e. If it looks good users will assume it works well and is of high quality. They are much more likely to forgive minor issues. Every app has to be 'sold', either to end users or for cash. If you have a great system why not package its usability, productivity benefits and user-focused tooling in a great look and feel? (Honestly I'd still love to know why 90% of the people I talk to are happy leaving this bit out.)
6. A little study goes a long way
7. Prototype on paper
This is a fundamental stumbling block for a lot of developers. If you begin prototyping on screen, you will almost certainly be constrained by what is in front of you and unlikely to think outside the box to solve any issues that might arise. Start with a pen and paper. You can scribble, throw it away if you get it wrong, jot down alternate ideas and prevent yourself from getting bogged down in too much detail (like changing the color of a button). If you have to start again, it's just a piece of paper that you are tossing aside. Research shows that people who prototype in their development tool rarely delete their work and start from scratch, they are too constrained by the work they have already done. Paper is also great when it comes to showing others your ideas as it forces the viewer to focus on how the app will work and not what it looks like (everyone can see it's just a sketch). It also sets realistic expectations as no one will expect the final version the day after you have presented a sketch (except perhaps at looksoftware).
8. Iterate to fine tune
Always, always, always work quickly. Get your design out to people for feedback then refine it. If it's a large app focus on a single module or just bare bones functionality to get something out quickly. You'll get feedback much faster and it often stops you from putting effort into areas that have little value (which is all too common). I usually aim at getting a bare bones system out in just a few days with a couple of value adds, perhaps one of each type. I use reaction to the value adds and feedback to focus the second iteration on areas that I know will add value.
9. Consistency is good
During my years in IBM i it amazes me just how creative developers are. This is both a good and bad thing. Good when they are solving business problems and bad when they refuse to follow a standard. Users love consistency. It enables them to learn one app and apply their knowledge of that to the next. It minimizes the learning curve and requires a smaller mental app model. This is why I try to mimic, as much as is possible, popular mobile or desktop applications. This is not because I am too lazy to come up with an original design, it's because 'the familiar interface' is a powerful tool. Don't be put off if you are criticized for mimicking popular applications in your design. If it helps your users work more efficiently then you have met your goal.
10. Be a user
To ensure that a mobile design really hits the mark, every developer should grab a smartphone and/or tablet and use them in the same way that users would. Don't just test your app lightly, really test its usability. Get some real jobs and enter / update them - see if your design enhances the actual process (research up-front makes this much less painful). Never be afraid to be wrong, its a natural human thing, we can't be right all the time (well at least I can't).
I've often talked to companies who start with 'we want a browser-based solution'. While this is all good (I LOVE CSS and any excuse to get in there and do a cool demo), and we have a great tool for that, it's important to stop and ask why. Why a browser? Are the users remote end-customers only occasionally accessing the system? Are they traveling and need access from any PC on the planet? Typically the answer is "we don't want to have to deploy an app", and often the users are internal everyday staff. In IT it seems like a simple decision to make life easier but if you step in your users' shoes for a day and really evaluate the productivity of both options you may make a different choice.
This list could be endless and contain very specific items that may not relate to your work, I hope that the list above sparks a few ideas, confirms or questions your current approach or helps you to plan your design projects. What would your top tips be?
UI/UX Expert, looksoftware