Kick-off meetings usually communicate key requirements. But before anything can be done about them, first they must be contextualized.
Informed design decisions come from contextual understanding of the product and its users.

The design team's arsenal of data can be bulked up by:
Speaking with Users
Before any meaningful work can happen, research needs to be conducted. By interviewing users of competing or similar products, and screening app reviews, an academic/statistical understanding of the user corpus can be deduced, affecting following design decisions.

To communicate this clearly, common user groups are visualised as “personas”, which serve as an affirmation throughout development.
Becoming the Users
To cater to any market, you have to identify it first. As good as preliminary research is to point you in the right direction, it's crucial to keep in mind that the market constantly shifts. Throughout the lifecycle of a product, there will be new learnings (such as from early testing) which will affect the experience in new and unexpected ways.
Identify Best Practices
The most common practices won’t necessarily be the best, but often prove to be far more approachable for development. Annotate competing products, take notes with user context in mind and use this to justify your design decisions.
The Post-It Method
If the product being designed has many parts that don't immediately dictate a clear information architecture, barebones sketches or even just words, can help correctly categorize the information and tell the first ideas around general UX layout. This is often the first prototype of the product 'skeleton'.
Information Architecture
Take a specific time to make sure that the content users seek is intuitively reached by organizing the content as data, correctly. Make it less work for the users to do what they came to do, never at the expense of intuitiveness.
Account for and organize all required components, including features with variable states. At this point, everything should be identified and matched with traditional display of information. If the product requires a departure from conventions, this is a good time to start thinking of available solutions and speaking to developers about potentially making use of and customizing them, before trying to invent solutions from scratch.
Common Practices
There are many ways to acheive the same goal, but not all of them are equal. System-level components are usually optimal for intuitiveness and efficient execution in development.
Practices informed through prior research still need to be contextualized. Sketch is an ideal tool for both the earliest digital wireframes, as they can be made seamlessly interactive and simultaneously lay down the groundwork for build specs for developers.
Functional prototypes are constantly iterated upon, allowing more intuitive and meaningful iteration and a better sense of stakeholders' feedback in context.
Best-in-class tool that saves designers tons of time be integrating with Sketch for easy updates and replacing the need for Zeplin or individualized spec sheets.
Collecting Feedback from Preliminary Testing
The interactive prototype is an ideal state of the product to further test any untested features that might've popped up since research. Internally, although teammates will inevitably have a biased perspective, testing with a small group on the success of specific features can be an early tell or decide the outcome of an A/B test.
Iteration is 60% of all UI/UX. While some of it happens before any prototype is made, most changes occur once the vision of the product clarifies through interaction. Eventually the team settles on MVP build features, system components and last-minute changes.
When sharing a common vision, it's not difficult to find affinity in your team, since you have something in common. Building a common language is crucial to the success of a product.
Two-way Street
No design is done well in a vacuum. Including developers on feedback loops allows better anticipation of development length and is cruial for a good sense of sprints and what is possible or optimal.
Detailed specs, for which Zeplin was the tool of choice until recently, were integrated into inVision, saving precious design time and allowing fewer distractions.
Even with pixel-perfect specs, the app may need a final nip & tuck make a straightforward, intuitive experience attain that 'wow' factor. With the help of a developer, identify areas where polish can be had without a lot of additional development time.


Now that you know about my work acumen, care to read about my experiences?