Design Thinking: 4 Steps to Better Software


As an interesting side note, I'm told that children do this best. They haven't yet had the creativity beaten out of them. I tried this with my six-year-old and nine-year-old, and it held true for them. I saw more interesting ideas faster than I usually see with adults, who seem to be more concerned about wasting time than anything else. Ironically, that concern about wasting time seems to result in their moving more slowly.

fig 2

Figure 2: My daughters and their smiley faces

The schedule is the villain in today's fast-paced software development world. When trying to solve a real-world problem, we're quick to stop brainstorming and start criticizing ideas—even our own. We may know academically that our best ideas are rarely our first, yet we're quick to settle on our first feasible idea. In business, being the first with an idea is usually considered a sign of competence. If we embrace design thinking, being the first with the most ideas is best.

The ideation stage is often considered a "widening" stage, in that we're increasing our field of possible solutions. A practice for ideating software UI design that's growing in popularity is design studio. First written about by Jeff White and Jim Ungar, the basic idea is to describe the problem we're trying to solve in the next product release and ask everyone to individually sketch his product ideas. It's a fast, collaborative way to involve the whole team in ideation.

Iterate: Combine, Test, and Refine Your Best Ideas
In software development, the word "iterate" may mean one of two things: repeat the same process, or make changes to software to improve it.

In agile development, an "iteration" (or "sprint" in Scrum) is the basic cycle of planning a small amount of work, doing the work, and then stopping to evaluate the work before restarting the cycle.

In design-speak, "iteration" means improving our idea by evaluating and changing it. Ideally, we'll evaluate the idea by testing a prototype of it and then change the idea to address issues found during testing.

In traditional software development, building and evaluating a prototype usually doesn't fit into the schedule. Remember, we often latch onto our first feasible idea. Why prototype and test it if we believe it's likely to work? Maybe I'm the only one with this problem, but once I begin implementing or using a software solution, I usually figure out I've got it wrong. In traditional software development, changing our design in response to what we learn usually carries the negative label "rework."

If we embrace design thinking, we'll combine and iterate the best ideas that came from ideation. We'll build simple prototypes that allow us to quickly evaluate and iteratively improve our design.

Over the years, I've relied more on simple, paper prototypes to validate software functional decisions. I'm not talking about the drawings of the user interface you describe to others to get feedback. While those can be valuable, what I'm really interested in is simulating the use of the software. That simulation is the difference between a prototype and a sketch or specification.

Using cut-out, cardstock components stuck to cardstock screens, I can ask someone to assume the role of a user of my product and to attempt to accomplish something. Since it's not real, working software, I'll move the paper in the prototype in response to the user's using a pen to write text and his finger to "click" buttons.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!