WHAT I LEARNED FROM INADEQUATE PROJECTS
(and what they didn't teach at school)
BREAK DOWN SOLUTION TO ATOMs
Working with other designers remotely, I often got jobs like "take a look at the product and let us know what you think". I found that generic expert review, even usability testing, are not enough to capture all the details -- finished designs could be misleading. Design reviews must trace back to the most fundamental level of Use Cases.
This may be counter-intuitive for designers: Use Cases have an obscure nature for visual presentation. However their basicness in format eliminates all distractions and focuses on actual simple experience. At times where good documentation is missing, it even worths the effort to recreate them.
People may also interpret it as stepping out of the scope of a late-in-process review. This does not have to be true. If we consider each component within the flow independent from each other -- a perspective I learned from product management -- then changes on each component results in only little modification on the UI. This keeps the workload manageable, and help prioritize the most critical jobs.
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.
Want to have an honest conversation about what I did wrong and how I'm fixing them? Contact me!