Tools & Process

While every project, budget, and scope is different, and adaptability to those variables are more important than any one process; Here's a general overview of my approach.



But briefly, who am I?

I started my career as a developer, landing my first paying freelance gig over 18 years ago. Since then, I've transitioned and evolved my skillset to focus heavily on product ownership, user experience strategy, and product design. I enjoy small to medium sized agency and startup environments, as I'm passionate about helping businesses grow, and entrepreneurs to realize their vision. But I have been known to take a break from the startup scene to lead design teams at large tech corporations, such as PayPal.  

My previous life as a developer, has taught me the importance of understanding every aspect of the technology that I'm working with. While I haven't been a developer for many years now, I feel strongly that in order to design, strategize, or plan software or systems of any kind, it's vital to understand as many of the moving parts as possible. As a result, I still spend a lot of my downtime researching and learning languages and methodologies that have, will, or might impact my current or future teams. I've found this improves my ability to deliver holistic technology products with a comprehensive approach to everything from documentation to deployment strategies, but also provides me with the experience necessary to see the big picture, and the foresight to see technical hurdles or design challenges before we run into them.

I believe my holistic approach to product realization and development is presented pretty well in my kind of long-winded (sorry about that) process below. Any questions, just shoot me an email.



1. Discovery

Who are we? What are we doing? Why are we doing it? Answering these questions is the first step in the discovery process.

Discovery is about getting on the same current — the same path to ground. Going through the project as a concept, identify the fundamental features, what the project needs to achieve or what problems it's solving, and lastly focusing on the vision, the "30,000 foot view" of the project (it will change later, I promise). Spend most of this time taking turns on the whiteboard and asking broad, limitless questions. Avoid getting sucked into pitfalls over things like technology, timeline, and budget. Focus on the positives and the big-picture dream. Remember, this is the "why", not the "how".

Personally, I like to have as many stakeholders, collaborators and thinkers from as many backgrounds and roles involved as possible. This is not only to prepare each department for the potential workload, but also because each of these humans are doing different jobs that require different types of thinking. The more types of thinking you have in the room, the better the questions and discussions are.

Tools I like to use for the discovery phase:

  • Whiteboard
  • Pen/paper
  • Camera for taking shots of the whiteboard
  • Caffeine


2. Market Research

With the broader product vision now being shared between all of the stakeholders, market research needs to take place to establish who really needs this, and why. What's the demographic like, how are they currently approaching this problem if at all, and how would they expect you to solve this problem? This is also a chance to find out if there's already a player in this space, how they've approached it, and if their approach is working. If it is working, how can it be improved on? Are they a competitor, or are they targeting entirely different groups with a similar product? Figure out exactly how you're different.

How are users acquired for this market? Examine how information design, interactions, and workflows are used to get users from point a to point b in similar or related products. Screen shot *everything*.

As a technologist, I like to research the technology that's needed during this process as well. What do you think your development stack might look like? Do APIs or services exist that you can leverage? If you have competitors, what are they using? What are their limits?

Tools I like to use for market research:


3. Ideation

With the core product being identified (with Discovery) and qualified (with Market Research), the design and initial development cycles can begin. This could easily be broken into 3 more "phases", but I'm combining a few pieces for the sake of the agility (and brevity).

For myself, a conceptual thinker and a person who likes to push technology as far as they can, this is the most exciting part of the process.  Ideation is about creating user journeys, mental models, interactions, moments of joy, and overall product experiences that get a person from "I have a problem" to "I have solved my problem" in a way that was easy, intuitive, and rewarding to the user. This process includes many iterations of sketching, wireframing, barebones visual design, interaction prototyping, and various other things that can put the team in a position to decide three things: What's required for MVP, what technologies do we need to build, and what's the full scope of the final v1 product.

I like to bring developers in toward the end of the ideation phase, to begin building out core functionality as atomically and as agile as possible. This takes a slightly different approach to writing requirements and setting development expectations, but most of the core functionality, at a lower level, should be established by now. This starts development and design off at almost equal trajectories, and then design should be able to pull ahead by at least a full sprint while development gets the baseline work done.

Tools I like to use for ideation:

    • Sketch + Craft for wireframing, visual design, and building prototypes
    • Adobe XD not my preference, but some clients/agencies prefer Adobe's ecosystem
    • InVision Studio - TBD, but very excited
    • Abstract for versioning and management of the project's Sketch files
    • InVision to display and review barebones prototypes
    • Principle for high fidelity mobile animation prototypes
    • Framer for higher fidelity mobile or web prototypes
    • Music for inspiration and focus


    4. Test & Re-Qualify

    Now that the initial user journeys, happy paths, storyboards, wireframes, and various other prototypes and assets are put together in a cohesive and thought out manner, the first iteration of testing needs to happen before cycles are spent on the more finalized versions of design concepts and development planning.

    A lot can happen during ideation period. Stakeholders see new things and get new ideas, the design thinkers introduce new ways to do things and discover problems and edge cases, and the developers start to formulate ideas on how things need to be built and what limitations might apply. As a result, now is a good time to take that testing data in combination with your assets from the ideation phase, and re-qualify what we're really doing. Are we still building what we set out to build? Did testing confirm a need in the market we initially assumed? Is anything missing at the core of the product?

    Depending on what happens during testing and re-qualification, the ideation and research phases may both need to be repeated and tested multiple times.

    While dedicated user researcher professionals have their own suite of very complex and advanced tools and processes for testing everything from eye tracking to blood pressure, and ranging from thousands of dollars to hundreds of thousands of dollars... my list of tools is a little more focused on getting quick feedback from users (internally and externally) on specific flows and a general understanding of how they're interpreting the product through feedback and interviews.

     Tools I like to use for testing:

    • Sketch + Craft for building prototypes
    • InVision to display and review very basic user journey's in a clickable form
    • Principle for high fidelity mobile or web animation and/or interaction prototypes
    • Framer for higher fidelity mobile or web animation and/or interaction prototypes
    • Supernova Studio for building native iOS-specific prototypes
    • Abstract for versioning and management iterations for testing
    • Google Sheets to compare and share results
    • Google Docs or Evernote to document and share comments
    • Various devices for platform testing -- iOS, Android, Windows, Mac OS, tablets, phones, desktop, etc


      5. Design & Develop

      This is the longest phase, and should have the highest amount of check-ins and dialog of the entire product development process.

      After a consensus has been reached and approved by the client and product team regarding the overarching UX and functionality during the final test and re-qualify cycle, design and development needs to officially kick off. During this phase development should be given concise and approved-of wireframes, a high fidelity design language needs to be created that matches the functional wireframes which development has been given, animations and interactions should be prototyped and documented in a way that development can understand and run with, and a living design system needs to be produced to assist QA with testing, development with building and adding additional elements, other designers who might need to touch the product, and current as well as future stakeholders to help them understand how and why things have been designed and built.

      A plan of attack should be outlined so development knows in what order things will be given to them, and how to plan their time. For example, Sprint 1: onboarding. Sprint 2, messaging and purchasing. Sprint 3, social integration and sharing, etc.

      During "active" design, the design team should be 1 sprint ahead of development, at the very least. How a designer chooses to design, should be left up to them. Go work from a bar. Go work from a climbing gym. Spend half the time doing something unrelated if that's what you need to stay inspired and productive. But regardless of your working style, the designer should be testing (if applicable, of course not everything needs to be tested) as well as getting stakeholder approval at every step of their process. Nothing should be handed off to a developer before it's approved, unless the developer is made aware that something is W.I.P. ahead of time, and has agreed to put some JIRA story points towards it regardless.

      During "support" design, designers should be working with developers hand-in-hand. Every development team works differently to some extent, and designers need to adapt to their process. For some developers, this means creating assets manually and providing an in-depth guide. For others it may mean handing off a well-structured Sketch file, giving them a meticulously organized style guide and Zeplin project, or maybe just sending them screenshots with measurements in them.

      Tools I like to use for design:

      • Sketch for screen design, icon design, style guides, and pretty much everything
      • Abstract for versioning and management of the project's Sketch files
      • Pixelmator for image and bitmap editing if needed
      • Affinity Designer to create iconography and more robust vectors if needed
      • InVision to display and review very basic user journey's in a clickable form
      • Principle for high fidelity mobile or web animation and/or interaction prototypes
      • Framer for higher fidelity mobile or web animation and/or interaction prototypes
      • Supernova Studio for handing off native iOS-specific front-end (or just prototyping)
      • Atom to write code if needed
      • Slack for communicating with development in the office, or out of the office
      • Zeplin for handing off designs if needed
      • Jira and/or Plutio to track progress and delegate tasks and bugs
      • Various devices for platform testing -- iOS, Android, Windows, Mac OS, tablets, phones, desktop, etc
      • Music for inspiration and focus


      6. Follow-through & Support

      A product is never "finished". All of the previous phases need to be regularly repeated, user research needs to continue, absorbing feedback and adjusting product features based on user request and usage patterns as well as emerging technologies and expanding ecosystems, as well as simply expanding and optimizing what your product can do is all part of ownership.



      I love talking shop. Shoot me an email, or send me a message on any of these platforms that I'm regularly on: