One of the things we’re constantly working on at Global Cloud is the stuff we do before we code. We’ve found that good things happen externally (great experiences; happy customers) and internally (less bugs, lower cost, faster development) when we do our design homework. This is a kind of yin-yang; if we design well, we can put better tools into our clients hands faster. If we give our clients better tools, they will be able to improve more lives.
A quick (and nerdy) aside:
Capers Jones has researched and written about software development for a long time and his findings on the cost of a defect over time have been widely reported. If you’re not familiar with Jones’ research, he’s basically proven that a software bug gets more expensive the longer it goes undetected (duh). Recently, he expanded this research to include the ten most costly types of bugs. The illustration below depicts the cost of a bug over time and the top four most costly types of bugs.
Notice a pattern? The most expensive stuff can be caught before you code and directly relate to user experience.
This is why we’ve developed a rigorous, client-centric design process. Here’s how it’s usually done:
Design is Everyone’s Job
At Global Cloud, we’re broken up into teams comprised of product managers, account managers, application developers, interactive designers, QA and customer support representatives. During the design process, everyone’s involved. We’re all exposed to our clients and their stories. We’re all responsible for sharing ideas and uncovering important details.
1. Interview the experts. What problem(s) are we trying to solve?
Any mechanic will tell you that it’s better to hear “there’s a wonky sound when I speed up” than “I think I have a bad ball bearing.” The description of the wonky sound is far more helpful in diagnosing a real problem and how it might relate to other problems. So the first step for us is defining what problem (or opportunity) we’re trying to solve. We start by interviewing the experts — our clients. These interviews are pretty simple and go like this:
“We’re investigating X. Can you tell me about your world related to X?”
From there, our job is just to listen and ask a lot of questions. At the end of the interview, the goal is to clearly state what problem we’re trying to solve. When we’ve done this with enough customers, we not only understand the similarities and nuances of the problem, but also have real customer stories to back it up.
2. Conduct usability studies
Another way to define the problem is through usability studies. If we’re revising existing functionality, watching or hearing how current customers work through a given process can be really insightful. We typically ask a number of people to perform a task. Whenever possible, we watch them as they do the task. We always ask them their feedback: How simple or hard was it to do? Did you find anything awkward or frustrating?
3. Survey competing sites and sites with similar processes
Once we’ve defined the problem, we review competitive and other sites to see how they have approached similar issues. It’s important to be able to admit when the competition does something well (this is hard). We find it as important to look outside of our industry for new ideas and examples. For instance, when we were recently designing our Theming functionality, we reviewed leading Blog software to see if there were things that we could glean. When we were working on revising our registration and donation processes, we researched great ecommerce sites.
4. Review Usage Patterns
Another great source of insight are usage statistics. We use Google Analytics extensively on our software to track a number of aspects. What paths are users taking to do a task? Where are they aborting tasks and at what frequency? What are there common screen resolutions, browsers, etc. This information is very helpful when making nuanced decisions. For instance, we were recently discussing whether we should continue to support a browser that some team members thought was obsolete. If we could stop supporting the browser, we’d be able to use more sophisticated technical approaches. We went to the analytics and found that that the percentage of our users using the browser was still significant. Supporting the browser, was therefore, not an option and our designs would have to be re-thought.
5. Report findings and brainstorm solutions
Once all of this information has been gathered by various product team members, we synthesize it into a report and discuss. We then brainstorm solutions as a group. We’ve found it really beneficial to have multiple perspectives in these discussions. How hard will it be to design? Code? Test? Train? Support? Ultimately, we’re all trying to boil ideas down to the most elegant solution.
7. Design rapid prototypes, review and refine
Even with great communication, a lot can be lost in translation. Being able to see and interact with a solution — even in rough from — tends to uncover new ideas and questions. Once we’ve had a chance to brainstorm solutions, our designers get down to rapid, low-tech prototypes. The key is to see a solution as fast as possible to help evolve the discussion. We work fast and dirty while prototyping, often on paper or white boards. We then rinse and repeat quickly, getting more and more detailed with each iteration.
8. Return to customers with solutions and prototypes
When we’re all happy with the solution, we split up and call the experts back, explaining our ideas and walking them through prototypes. This can be a humbling experience if customers point out, as they sometimes do, that we’ve missed the point entirely. In that case, it’s back to step 7. In most cases, our clients will come up with new insights and details based on their experience that would not have been possible for us to think of.
9. Develop formal concept
Having incorporated client feedback, we develop a final concept and run by the team one last time before coding.
10. Integrate code into the system
Our interactive designers and application developers collaborate closely to integrate the designs into the code and technical design. Often, unforeseen details come up at this stage. When this happens, we stop the process and sit down with the team to discuss and revise. In some cases, we have to return to clients again to help resolve debates.
At this point, we’re ready to write code, thoroughly test, roll out and train our clients. But the design process isn’t complete.
11. Conduct usability studies
Once the new feature or enhancement has been out for a while, we conduct usability tests again to make sure that we’ve solved the problem we set out to solve. It’s often the case that we find there is more work to be done after these studies. In this case, we just return to step 1. That’s OK — the goal for us is constant improvement
“We worked closely with Children’s Miracle Network over the past year to meet their strict requirements for online fundraising. It’s motivating to collaborate with an amazing organization like Children’s Miracle Network. To help improve children’s lives with our software and services feels great to the entire Global Cloud family,” said Paul Ghiz, Co-Founder, Global Cloud.