The “Golden Eggs” have been written down from Joe’s slides – I hope without big mistakes. The comments are my summaries from his talk.
The full version of Joe’s talk will be available at Parleys soon.
1 – The underlying data structure should not define the user interface
This is a topic Joe has been talking about in a few Java Posse episodes already. And it is simple: By looking at the UI, you should not be able to see already the data structure. The UI should be solely tailored to be easy to perceive and understand by the user. Users don’t think in data structures typically – don’t make them.
2 – The interface should not define the data structure
With the former rule at hand, some of us engineers tend to go out, design a view and make the data structure look exactly the same. This it not how it is supposed to be. We have layers in all of our applications to abstract away the data structure, for example in the database, from the user interface. So we should do it. Design the data structure to be efficient and elegant for storing. Not like in the user interface.
3 – Need must proceed technology
You never ever should user HTML 5 because it is HTML 5. You should not use anything for the sake of technology.
Think about the user, think about their expectations. What user experience do you want to give them? This should lead your technology decisions.
4 – Start the process with real use cases
When starting to design a UI, use a real use case. Not an abstract one, a generalized one. Use something the user will really do with the application. Use example interactions and data which are realistic.
5 – Identify distinct categories of people that will use your app
Identify which kind of persons will use your apps. Split them into categories and give them a real name like ‘Ben’ or ‘Anna’. Give them a personality – this is called personas in a design process. Attach one persona to each use case you want to discuss.
As a side note: If you have two very different personas, think about the trade-off for creating two UIs compared to making one configurable. It is sometimes cheaper to create two UIs.
6 – Think in flows not in features
For the user experience it is important to think in application flows. Meaning the process of clicking through an “Login Process” with all state changes and transitions. Don’t think about a login screen.
Similar – if you design a design prototype, make it functional. The steps going through the design is as important as the look on the screen.
7 – Prototype often. Abandom prototypes often
UI design is developed in prototypes. Create a prototype of your apps UI – and then throw it away. If you do not throw it away, it is not a prototype!
8 – Make the next step obvious
When you are inside a dialog of your application, the next step the user wants to do should always be very obvious. Make it never hard to find the login button, the next button or the create new user button if this is, what the user wants to do.
9 – Reduce the number of perceived things
To understand this, you have to understand how our brain works, when it perceives a user interface. There are always three phases:
In the emotional phase, the brain recognizes colors, layouts and images on the screen. It sets the tone of the interaction with the UI.
In the parsing phase, the brain figures out the purpose of every element on the screen. It prepares the user for the task.
In the execute phase, the user starts to interact with the first element of the UI.
The more elements are on the screen, the more elements have to be parsed in the second phase. The more elements, the harder it is to understand for the user what he should do. The more elements, the more time the user needs, to understand the UI.
10 – Leverage muscle memory. Be consistent
Our brain is a muscle. It can be trained. It reacts to common patterns. So make your UI consistent to use. Same things should always look the same. And they should align with the behavior the user expects from his operating system.
11 – Think outside the page load. If you can do stuff in-place
If you are inside the web, avoid complete page loads. Use the techniques offered by AJAX to load new elements or information in place. So the user does not have to re-parse all the elements because they are gone temporarily.
12 – Use transitions to change state
If your application changes the state, use simple transitions to make clear what is happening. For example, if you hide someting, fade it out so the user knows where to look if he wants to have it back.
13 – Iterate & Refine. Iterate & Refine
The process of designing a UI is iterative. You have to make a lot of proposals and be ready to change your mind. Extend them. Add new designs. Combine them. Throw some ideas away and use others to iterate further.
14 -Provide your customer with great experience.
Never break the experience of a user. This is not limited to the user interface of your app. It includes your support contatcs, your twitter feed and your homepage. Everything should be friendly to the user and provide him with the best experience he can have. The best customer experience.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.