As a freelancer, I am often brought in to design one version or one tool of a suite or redesign some portion of something to incorporate new features. I come in, learn as much as I can about the domain if it’s a new one, talk to whoever’s closest to the user (if not actual users), play with the existing software, if any. I might read stacks of requirements or just talk with the decision maker (project manager, product manager, engineer, or sometimes the owner of the company) and agree on problem areas or focus areas. When I’m done, I leave them with prototypes or Visio drawings. Rarely is there functioning code, working product, completed software.
|Ellen produced an extremely elegant, simple and useful web-based UI for a large, complicated event tracking system under development for a government client of Bear River. She was handed a very large and unorganized set of client requirements documentation for this project and quickly made sense of it all… The UI design that Ellen produced for us not only was overwhelmingly approved by our client, but served the basis for the engineering teams development work that saved us countless hours. I look forward to working with Ellen in the future as our needs arise. – Paul Wise, Bear River Associates.|
Some of my designs never make it to market due to lack of funding prior to release and the company slips quietly away or gets bought and I lose contact. Other times by the time the software is released, the person who hired me has left the company and moved onto other pastures. So it’s always a treat when someone calls me back to say “Would you like to come in and see the software? We’re nearly done.”
I got to do that with a project I worked earlier this year. The software is not complete but major portions are and I could see how it all really worked in real-time.
Workflow. How good were the requirements? How good was I at seeing what was missing and filling in the blanks? How good was I at predicting things? Being able to sit down and go smoothly from one screen to the next, watching data that you created in one application show up in another (or under another role) is priceless. It’s especially good after a few months’ break. In the rush of a project it’s hard to step back and look at things anew.
Timing. Particularly with a web application timing is something I can control only part of. I can be aware of and design around too many server hits but at some point the data must be brought back and the performance is dependent on many things in addition to the design. Since this can have a huge impact on usability, it’s always a concern to me. I was pleased with the speed and performance of the application I saw earlier this week.
Rich data. Particularly in complex applications with a lot of many-to-many relationships, I am dependent on how well whomever wrote the requirements and I thought through the relationships and how best to display them, work with them, modify them, show various states and properties. We try to work with a reasonably rich set of test data but until the data is created by the actual system, there’s a wee bit of uncertainty and the hope that we’ve created a rich and varied enough set of sample data. So far so good on this one, but the real test will be out in the field.
Real life tradeoffs: schedule versus features. In this case, I had designed in something the client was initially very pleased with and their client was very happy with when they saw the prototypes. It was something that was not explicitly called out in the requirements but served the larger purpose very well and improved the usability. But when push came to shove and the schedule started slipping a bit, it got cut. I’m hopeful it will make it into version 2 because everyone agreed it was good–but it was going to eat up too much development time right now. Ah well.
Users. Having software used in real life by real users is always the litmus test. I’ve seen it working in the development environment with a functioning database now but am eager to hear back again once it’s out in the real world. Working with real data in their own environment, users push things to the limits–and beyond. If they get interrupted in the middle of something, can they pick up their task easily? If they make mistakes, can they fix them? If someone makes a mistake earlier in the workflow (associates something with the wrong item, for example) does this get caught and can the guy who spots it fix it and move on? When the initial training is over and done with and a new guy gets hired who does not get the training and the documentation has been lost, what happens?
Real life. What did Roseanne Roseannadanna say? It’s always something. Requirements are often someone’s ideal world, what they wish were so rather than what is. When (not if!) something unforeseen happens in real-life, did we build a flexible enough system to manage? In real life, papers get torn and taped back together with a small piece missing, coffee gets spilled, and someone loses the original. People break the rules all the time (which were spelled out so clearly in the requirements!), write sticky notes to explain discrepancies, write out by hand what doesn’t fit in the little boxes on the form, misspell names, forget to get a signature, and make a special deal on pricing for a one-time situation. That’s real life. Unpredictable and messy and richer than any set of test data you could build in a lab.
Software that can’t handle real life is what scares most users I think. Programmers (and managers of the users!) want things tied into neat bundles, relationships pre-defined, and nothing unusual to happen. Exceptions are often the norm, like it or not. Design for them as well as the ideal world.