Archive of Interface Design Articles

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Read the rest of the article…

Your company is building out a toolkit to support third-party developers.  You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc.  You’ve got a long list of desired controls from your customers.  You’re agile.  What do you build first?

Read the rest of the article…

Perpetually intermediate (competent) users.  Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them.  Competent users have different needs and different expectations than novice or expert users.  How do you know your user’s competency levels, so you can design for them?

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

Read the rest of the article…

Ever scratch your head and wonder why you can use your favorite application for free?  How can a business actually make money (and stay in business) when they offer their product for free?  This article looks at the freemium business model, to see when it makes sense for a company to offer it.  The freemium model is one where the company offers two (or more) versions of a product.  The basic version is free to use.  You have to pay for the premium version.  The goal of this article is to answer the product management question, “Should you create a freemium business model?”

Read the rest of the article…

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

Visualizing complex data can be very difficult. There are almost as many ways to visualize data as there are data to visualize. The Ralph Lengler and Martin J. Eppler at the Visual Literacy Organization collect many of them for us in a periodic table.