WHAT I LEARNED FROM INADEQUATE PROJECTS

(and what they didn't teach at school)


BREAK EXPERIENCE DOWN INTO ATOMs

Working with other designers remotely, I often got jobs like "take a look at the product and let us know what you think". What I found was that suggestions based on expert review, even usability testing, are not enough -- the finished design is misleading. Design reviews need to breakdown to the most fundamental level of use cases.

It may sounds intimidating as indicating to step out of the scope of incremental improvements. This does not have to be true. Consider each component within the task independent from each other -- a perspective I learned from product requirements -- and every change results in only little modification on the UI. This keeps the workload manageable, while is able to capture problems systematically and prioritize those most important.

The automation of one single component could lead to a "butterfly effect" in final experience.

The automation of one single component could lead to a "butterfly effect" in final experience.

It is possible that a good documentation is missing: The work is often left out due to its obscure nature for presentation. In this case, it worths the effort to recreate them. It sounds counter-intuitive for designers. However the basic format eliminates all distractions and hence maximizes the value of our output. (And remember that this document will be used for another time.)

The table of use case comparison elaborates every step of action and helps find the most simple solution.

The table of use case comparison elaborates every step of action and helps find the most simple solution.

SOLVE PROBLEMS WITH MARKET VALUE

I've had the benefits of a prestigious user-centered design program from IIT Institute of Design (ID). I still regard defining problem as one of my strong suites.

However, I learned hard that even defining the right problem and solving it well doesn't guarantee business success. If customers do feel the problem being significant enough for money, time and effort investment, they are likely to keep how things are now. The only way to know if people want to use the solution is to launch the product for authentic feedback.

Before, I looked at every problem as a design challenge -- how we sprinkle some fairy dust to help users understand the product better. Now, here is another goal -- design a product that users understand, naturally.

 

UX OF DEVELOPMENT PROCESS

Students may get hands on a full design process from research to even marketing plan. It was a "cultural shock" when I first came to my current employer, who adopts a waterfall model with little autonomy for designers.

Here are two things I learned:

  • Even when using the waterfall development method, different projects have different demands. When needed, I must stand up at an earlier phase for optimal user experience and work efficiency.
  • The product requirement and design documents are like products; Development and QA team are the users. I sat down with my coworkers to learn their needs and designed documents that best suit them.
A flow-based collaborative specification for QA

A flow-based collaborative specification for QA

Want to have an honest conversation about what I did wrong and how I'm fixing them? Contact me!