Our client came to us with a problem: They had paid for custom software that didn’t do what they wanted, and was frustrating to use. The design hadn’t been thorough enough to properly account for what they needed to do, or how they needed to do it.
What they really needed was a tool that could help them plan quickly and intelligently. How much more engineering work could they take on right now? Did they have enough people to complete all of their scheduled work in October of next year?
As always, my design process started with a user journey map. Who were the users? What goals did the users have in connection with the tool? What were the steps to achieving those goals?
I believe that a problem well-understood is half solved. That’s why user journey mapping is the most important part of my process. In the course of the mapping exercise, I discovered that humans were doing hours of tedious mental labor that a computer could do for them. The user journey map was our North Star throughout the design process.
With our map in place, we quickly identified the biggest challenge: Smart planning requires seeing the big picture and specific details at the same time. We had to show the user a lot of information at once and help them make sense of it easily so they could make smart decisions. There are lots of ways to do that wrong and only a few ways to do it right. I went through dozens of sketches before arriving at a solid direction.
Computers can do so much more thinking for us than we give them credit for. I knew that although the interface would have to be flexible, it would also need to lead the user to the right conclusions. By providing contextual tips, we could eliminate guesswork and make the user more efficient.
One of the biggest deficiencies of the old system was that it didn’t alert users to upcoming issues, nor did it offer any help solving them. In my view, that major omission defeats the very purpose of a planning tool.
Instead of making the user find problems on his own, I designed an alert system. Any potential conflict or discrepancy is obvious when the user first opens the product. (I’ve recommended that e-mail alerts be added.)
When working with dense data, I believe in visually stripping everything down to the essentials. It’s hard enough to see what’s going on in a windstorm of information without having to contend with decoration.
Often, still images are used to communicate screen designs. In my experience, clickable prototypes are non-negotiable; nobody really knows how a product works until they see it working.
(Design nerd footnote: This was the first project on which I used the Craft plugin to build clickable prototypes right inside Sketch. If you use Sketch and you haven’t tried this plugin, do it now. Congratulations to the team at InVision on a great workflow.)
As of this writing, engineering is still putting the real thing together. Preliminary testing has gone great and the stakeholders can’t wait to see it working for real. I’ll keep you posted.