Review Principals

Note: As we review more products, these principals will evolve. What we deem important now may change due to emerging technology or new ideas from the design/development community.

For our reviews, we will not be clicking on every button or link, that's not a reasonable or practical goal. We'll be reviewing real flows a user would take while using the product 1 in addition to the overall design 2. But before we start digging in and reviewing products, we need to have some sort of baseline on which to review. Arbitrary comments such as “I hate red buttons” lead us nowhere fast 3. Constructive criticism is what we are after here and we'll start by establishing some simple principals.

Principals

When building products we often have a scope of features which we implement to help users achieve their goals. Our (users & software creators) goals are somewhat aligned, in that we want more users to use our products successfully. An increase in users helps the company grow and a growing company can add more features. But how do we measure success? We use performance metrics. Reviewable metrics will vary based on the media we use and the goals of features we are reviewing, but the idea is the same: Were our users successful? Metrics are statistical, but we won't have statistics to know how successful these products are. We'll have to use principals of design and usability.

For some basic principals, we will start at the beginning of interface design with ideas set forth by Jef Raskin, father of the Macintosh project 4, in his book The Humane Interface. Jef came up with 2 basic Laws for Interface Design 5:

A computer shall not harm your work or, through inaction, allow your work to come to harm.

A computer shall not waste your time or require you to do more work than is strictly necessary.

These are fairly straightforward. Fellow designer and developer, Diogenes Brito, outlines some great examples of these rules in his blog post Three Laws of Interaction Design6. We could write entire research papers on these 2 laws, but for our purposes, we'll keep it simple:

Proactive - did the software keep the user and their data safe? Either by prompting the user that data may be lost by a specific user action or by creating backups of data. Was it responsive to user's needs? Did it anticipate actions?

Design - was the user able to do what they needed to in a reasonable amount of time?

This boils down to: “Can I accomplish my goals with little to no friction and enjoy using this product?”. For our last principal let's look at Steve Kurg and his book Don't Make Me Think. We are going to borrow his definition of Usability7:

Usability: A person of average (or even below average) ability and experience can figure out how to use the thing to accomplish some desired goal without it being more trouble than it's worth. Source

Not much can be added to make that point any clearer. He sums it up pretty well. However, there is debate as to whether usability and design are the same. This is a larger conversation to have, but for now I will point you to this Slideshare from Josh Levine & Jordan Lustig. Briefly, they are not the same, but they do work together. A design can help (or hurt) usability. This may be confusing, but it will make sense once we start reviewing.

Conclusion

We now have some basic principals which we can use as a base to review fairly and responsibly:

Proactive

Design

Usability

These are not set in stone and many can argue there are others we can and should be using, but these are merely a starting point, over time we may add, alter or remove them. Additionally, we have only scratched the surface of what each of these principals means and what subcomponents they are made up of. As we review, we will unwrap each of them with some concrete examples of things you should or shouldn't do.

Thank you for reading.
_W

Walter Colindres, is an experienced and opinionated UX designer and developer. If you have comments or questions, you can reach him by email.

Does the design help achieve the user's goal in easily and in a reasonable amount of time ↩

Comments will not be a part of this site for now. In looking at other sites, comments tend to be overtly negative and offer little to no solutions. We don't know everything that went into the creation of an app or experience so let's not ignore that a lot of decisions are made by people outside of design and development. ↩

Started in 1979, the Macintosh project was the first attempt at getting a machine to understand human intentions Source↩