Philosophy & Process

To get to a good product or at least a successful one, I see that team members must understand their problem from the experiences happening in a real-world context. This is the foundation for delivering a product people actually want to use.

Philosophy

My key strengths lie in a “desire to understand.” I try my best to assume nothing and remain in a place of learning and empathy. Any problem that is being solved, will never be fully understood. With each product iteration, new things will emerge to learn from. Validating our own ideas sometimes undermines the critical need to understand.

My role in a project is to:

a) Translate learning: clarify and communicate key ideas through language, UI, visuals, info-graphs, and/or storyboards
b) Be an ally: act as a support for all team members… stakeholders, end-users, development team, and the designers.
c) Stay focused on the vision: maintain clarity of both the forest and the trees at whatever phase of the development cycle.

Process

I haven’t experienced a single process that is so tried and true that altering it would lead to a breakdown in success. Sometimes it is good to bend the rules and leave room for innovation in the process to be revealed.

However, the foundation of any project should be at least somewhat structured with design thinking because it provides an excellent framework to innovate with.

Traditional Design Thinking:

Design Thinking Illustration

Origin: Nielsen Norman Group

My Modifications in Design Thinking from Concept to MVP

1) Unpack the dream
Be idealistic and dream of a solution that lives in possibility.

2) Understanding through empathy
Observing with genuine care and concern for users is how we understand their pain. This pain is the source of revenue, as it is ultimately what people may be willing to pay or do in order to experience this task differently.

3) Synthesize and ideate
Gather insights and reframe learnings. User personas and customer journey maps can be very helpful here.

4) Redefine to serve: Define the ‘Killer Value Proposition’
From empathy, we explore and determine a win-win-win statement. This is the MAIN THING and will be the focal center of the objective at stake.

5) Prototype solutions
How might we…. achieve [the value proposition]? This is where a lot of exploration of the solution and team feedback on prototypes can unveil a lot of challenges and successes.

(Iterate and return to step two)

6) Share, test, observe and revise
With a prototype that the team believes will brings real value to the industry or the life’s of the users, it is time to see it in action. At this stage, it is important to make mindful notes of design shortcomings or flaws in user flow.

(Iterate and return to step five)

7) Explore business model avenues
When the prototype is intuitive and delightful, determine how much value it is really worth and strategic ways to price it.

8) Plan a lean development roadmap
Gather requirements based on user stories, derived from user flows, journey map, and prototype. Break down user stories into requirements and build iterations, beginning with the most critical and foundational components.

(Implement, test, and return step two)


Cake Wrecj

Assume nothing of your end-users

What not to do 

After leading the research and discovery phase and heavily involved in product management of multiple software and websites over the years, I have learned a few things. There are good-things-to-do and not-so-good-things-to-do. I also have learned, that I will always be learning and improving.

Here are a few not-to-do things I learned the hard way:

  • Focus on “how to build something” before understanding “why” and “what” we are building.
  • Wireframe without empathy-driven user research.
  • Develop without user validated research.
  • Make decisions based on only what users or stakeholders say.
  • Assume that your team members think the same way you do.
  • Believe that a long list of features will make a better product experience.
  • Advocate for features by using reasons based on assumptions.
  • Write instructions for how the software works.
  • Claim to know the best answer or solution.
  • Prioritize design aesthetics over functionality.
  • Manage, design, or develop in a vacuum.

Mixed Methods:

  • Commitment to understanding through questions, observation, and multi-sensory listening
  • Value proposition documentation (Matching Customer Profile to Value Profile)
  • Break down goals as clear KPIs
  • Facilitation methods, such as appreciative inquiry and user story mapping
User story mapping session

User story mapping session

  • User research summaries
  • User personas
User Persona

User Persona

  • User story mapping
User (Patient) Story Map

User (Patient) Story Map

  • Customer Journey Mapping
  • Sketch-noting
Bodystorming

Bodystorming a bathroom stall kiosk experience

  • Bodystorming
  • Wireframes – from paper to Sketch App
Mobile Wireframe Samples

Mobile Wireframe Samples

  • Prototypes – Sketch, Craft, and Invision
  • Information architecture maps
Simplified Information Hierarchy

Simplified Information Hierarchy

  • Screen flow maps

  • Requirements gathering and development forecasting
  • Comprehensive product or website proposals

Software Tools and Platforms

 

Have thoughts on my process?

Let’s Connect.