May 5th, 2012
For many projects, self design works great. By designing for our own use, we can optimize the user’s experience to be smooth and seamless.
A while back, I wrote about the advantages of self design and the alternatives to self design. Of course, to be successful at self design, you have to use your design practically every day and you have to have a base of people just like you that’s big enough to support whatever business model pays for your work. That way, when something in annoying in the design, you’ll discover it quickly. And when you fix it for yourself, you’re also fixing it for a large enough user base.
A big problem with self design is that it doesn’t deal with things that you won’t do frequently with the design. One of those things is using the design for the first time, because, well, you can only do that once.
You see this in a lot of self-designed products: the initial user experience is rough, never explaining why you’d use any of the key functions, and hardly ever giving the user a great way to get started. Because self-designers rarely are working from a blank slate, the initial process of populating the application with data is not as smooth as the usage patterns once you get going. The entire getting-started process is really difficult.
While self design can help work out the rough edges of daily use effectively, design teams need to step away from the self-design approach to something more activity-focused for that out-of-box experience. Creating a process that usability tests with people new to the design will help keep things balanced.
With frequent and regular usability testing, you can answer questions like “Do people understand what this is for?” “Do they see how it can help them?” “Do they know how to get started?” “Are they overwhelmed by the functionality or choices?”
It’s ok to use self design to move a project along. It’s best to combine it with other types of decision styles, such as activity-focused design. This will keep the project balanced.Tweet