So, it’s a new year and I’m working on a new project for a client. Once again, working alongside Mr.Visser.
This time, we’re tasked with redesigning and rebuilding an existing application for a client – “doing it right” was one of the ways it was explained to us. Of course, we’re up for it ..
When we initially started the project, one of the first expectations was that we would create a “design document” – a document that would describe in detail how the system should look and behave. I’m a big believer in the idea that the beginning of a project is the point of most ignorance. Design documents tend to be a bit too waterfall.. and have a tendency to leave the actual users out of the conversation.
So, we proposed creating a functioning mock up instead. We would build the front end in a couple of days (no longer than a document would take) and provide a clickable demo to garner feedback and ensure that our understanding was correct and we were headed in the right direction.
We set off using yeoman, bootstrap, and angular js to build a demo, along with some mock data to aid in simulating what the actual users could expect. After a few days, we were ready for our first demo.
We demoed first for the person charged with managing the project. After seeing the demo and giving us a bit of feedback, he brought in a user for another demo the next day. As we continued to refine, a couple more users were brought in. We knew we were on the right track when we saw that users who had seen the demo already were smiling and waiting on the expressions of the people who hadn’t yet seen it. But one of the users of the old system quickly noticed that we were missing an important field.
The old system had a list of images that the user could select and re-order. The main user complaint about the old system was that the list of images was very cumbersome to work with. To re-order them, the users had to remove all of the images and then re-add them again in the order that they wanted.
We thought we could easily come up with something much more elegant. Drag and drop! You could do that? We sure can. And we would make a conscious effort to keep the interface beautiful and uncluttered.
We had mocked up the simplest thing that we liked :
But as our demo had allowed us to communicate with the users and get almost immediate feedback, we were quickly aware of the limitation. The photos needed captions! Monkeywrench! How do we add a text box to this list for every photo without making the interface suck?
Well, it would satisfy the business requirements. But. UGH. That looks like barf.
Designing interfaces is hard. We want people to be happy when they use the stuff we build. It’s something that needs to be iterated on just like the rest of an application. You need to think and then re-think, and then continue to re-evaluate as you learn and keep coming up with better ideas. Bad interfaces make users unhappy and waste their time. For a business, time is money, so software that wastes time is incredibly expensive. We didn’t just want to throw something on to meet the requirements. We wanted to keep it elegant.
And so we thought about it, tried a bunch of stuff.
Dialogs for editing captions? That keeps the list clean, but now we have hidden information. The user actually can’t see all of the important stuff when they look at the page. Bad.
After much thinking and experimentation, we eventually came up with something like this:
Finally, something that we were happy with. It still looked nice and satisfied all of our requirements. Captions were generally a very small amount of text, so showing a large box was unnecessary. Using CSS transitions and angular js directives, we could easily make the currently selected box smoothly animate to full-size while the others fade into the background during edit. An HTML placeholder makes it obvious what the box is for when there is no caption.
So glad we didn’t compromise and tack the box on .
And so, the first couple weeks of this project have got my brain thinking about certain things as well as learning some new tools.
These are the things I’m thinking about right now:
1. Functioning demos are way better than static ones for building excitement and getting the right kind of feedback. If we hadn’t built that initial interest, the right users might not have been pulled in so early and we wouldn’t have caught the missing element so soon. We’ve made a point of doing this with our last two projects and both times this approach worked extremely well. Demos have a way of attracting people to give feedback and generating excitement, while detailed documents have a way of boring them while they wait to see something real.
2. Design needs to be iterated on just like the rest of the solution. You rarely can fully understand all of the technical problems, user frustrations, etc. up front. And your first idea is usually not the best. Iterating on something gives you freedom. If you spend a month on a design up front, you’re going to have a hard time convincing the customer that doing something different is a good idea. After a month (or week) of work, they expect it to be right. Without investing too much in a specific idea, you keep the freedom to throw it away and replace it with something better. With freedom, you don’t have to compromise. You don’t have to tack things on to an existing design to meet new requirements. Continually re-visit the user interface design as requirements change.