I recently had a conversation with a friend about the things I’ve
learned in regard to building software over the last 7 years. She found them to be helpful so I
thought I’d post them here as well.
I’ve organized them into two posts – Design & Usability Testing.
Design
1. Users are not designers.
Don't let them be.
If you knew as much as your doctor would you bother making a
visit? There is a reason you’re
making software and your users are doing their job. Each user will have a different experience level when it
comes to using software. Many
users will offer suggestions and some of them will be good. It’s important to listen to all of them
but also to be cautious and not take the suggestions literally. Instead, figure out what it is they’re
trying to accomplish. A user telling
you they want a new page with a purple button that does “X” is not
helpful. Understanding the objective
of “X” is.
2. Take the Vegas out of it.
Cascade Web Development, a great
partner we worked with to make the ShiftWise web site has a phrase that I’ve
adopted – “Take the Vegas out of
it.” Basically it means that not everything can be a big glowing button in the middle of the
screen. You have to balance things
out. If everything stands out then
really – nothing stands out.
People get carried away wanting to highlight all the components of their application. There
isn’t always a perfect solution for highlighting all the elements you want to – particularly for a multiple use
interface. Just be as selective as
possible with the areas to which you want to drive your users.
3. Simple applications are for simple things.
Today, software is all about simplicity. Some
companies build very successful business models making simple applications. The predominating
thought in software design right now is that everything needs to be as simple
as possible. Let me be clear that I completely agree
with this thinking. However, if you simplify things too much you can run the risk of your application not allowing users to
complete their objectives.
I’ve seen users make “simple” apps very complex because of the
workarounds they create in order to achieve their objective. Not only is
this painful for the user, it becomes hard on the business end to understand your customers and your data when there are so many inconsistencies in usage of your application. Further, if the application is too
simple it may create the necessity for users to work with multiple
applications to achieve their goals. If this happens you
run a significant risk of being displaced by a competitive product with a broader offering that
adds similar/same functionality of your application.
If done correctly, users can tolerate a little complexity and multiple features if it means
they can accomplish their goal and do so with one product.
4. It’s not a zero/sum game.
Some functions within a feature may have more friction points than
others. Focus on identifying and
fixing each of these friction points as opposed to scrapping the
entire feature.
In the past, I've discovered that we had some features in our application no one was
using. We almost removed them from
the application completely.
However, after getting some feedback on the features we discovered that most users wanted them, they just had some issues with using the features. After improving specific components
of the features they became widely adopted.
5. It’s ok to say no.
Sometimes, users are just wrong.
It’s true. Not you of
course. But other users. Adding everything your users want can
be costly in terms of time and money.
In addition, you risk unnecessarily complicating your interface. I’ve certainly been involved with
situations where adding too many feature requests yielded low feature adoption and
overly complicated other useful features.
Sometimes, “no” is the best answer.
6. Build and test in short iterations.
You can’t design perfectly from the get-go so don't over analyze and
don’t over code. My theory
is this – you can spend months planning and analyzing in an attempt to get the
feature or new product perfect.
However, aside from being expensive, you significantly delay time to
market and most likely aren't going to get everything right anyway. This delay can produce
competition as well as cost you revenue and create unhappy customers who become impatient waiting for upgrades or new products.
Instead, layout the general functions of the feature and the design, code
these specific functions, test, release, get feedback, refine, and repeat. As you gain insight generated from
testing with each new iteration, you’ll find the magic if you’re
willing to hang in there. In
addition, you’ll get easier to analyze results if you limit your tasks to only
a few and your users will feel they’re being heard as they see their requested
changes being added faster.
7. Users hate change.
I’ve found it rare that users really want change. Look at how much flack Facebook gets
every time they change their interface.
Whole groups form to protest (real and virtual) and apps
have even been built allowing people to vote on the changes.
I’ve been in situations where we released a feature that was a
dramatic improvement over the previous version. However, we had major user push back post release. After tracking down the issues we discovered the real problem was that our users simply didn’t like the fact that the feature was
different and we didn’t do a good enough job preparing them for the change.
I’ve found the best way to avoid this is to inform your users of the
upcoming changes previous to the release.
Post images, hold training sessions, send email blasts or communicate
however you can in order to get word out of the upcoming changes. Doing so keeps the users from being
surprised the next time they log in to your application.
Further, if possible, beta test everything. Often times you will receive major push back from users if
you don’t. Users start to feel that they own your product and if you don't communicate with them about changes
or provide them with feedback channels they can become quite upset. Quickly.
8. It’s never “just a
checkbox”
Or “just a dropdown”, or “just a text field” or “just a report.” Again, most users know very little about
software. I constantly hear things
like – “It’s just a field/text box/report – it can’t be that hard to add.” It’s important to be honest with your
users so their expectations are properly set and to help educate them on the
process of building software.
I like to use house analogies.
It might look like “just a sink” but believe me, there is a whole lot
required to properly put in that sink. Adding
something like “just a checkbox” can come with other functionality that touches
multiple pages, requires user rights, notifications, event logs and new
information on a report. Further,
in addition to designing and coding it needs to be tested and the changes need to be communicated internally and externally. All of these things take time – just
like putting in a new sink.
9. Modularize
If you’re going to build a large application capable of handling
multiple functions and processes, don’t build it as one big application. Instead, build each section as a
separate, stand alone module that integrates with all the other modules. Doing so allows for more flexibility and
better revenue opportunities down the road.
If all of your customers have to use the same large application,
invariably there will be some features or components of it that some users
won’t like or need. This will
cause friction and dissatisfaction with the product. It could even cost you some sales.
In addition, by modularizing your application you have the option of
continuing to add new features and functions in the same way. This will allow clients to pick and
chose the components that work best for them. Adding components can afford you opportunities of pricing
each modular separately, dramatically improving your revenue.
10. You get what you design for.
Many companies make the mistake of overlooking design and
usability. They see it as a luxury
that matters only after the code is written and the function perform as specified. This leads to one thing – horrible software
that no one wants to use.
The companies I’ve seen skimp on design and usability end up paying
more for training, support and the loss of revenue from unsatisfied
customers. Of course the software needs
to work and be bug free as much as possible. However, it’s all for nothing if you can’t get people to use
it or go broke hiring support and training employees.
Design and usability should be the place you start with and constantly
improve upon.
Recent Comments