/  
Process

My Process

M

y process has been an evolution of molding itself around the ever-changing flow of work within my environment. My process might not work completely for you and that's ok. I've always enjoyed learning more about how other people work, and perhaps you might find something useful in here, too.

I like to begin projects by working on a Design Brief. My version of a design brief attempts to answer the 5 W’s of Who, What, When, Where, and Why in order to better understand the scope of a project and the user stories associated with it. As I continue working on a project, I like to add in research findings as well. Want to see what my Design Brief looks like in the beginning of a project? Check out my google doc that I use as a template.

A little peak of my Design Brief template

‍

‍Mapping user flows of both the current experience and the potential experience is a great way to gain alignment and understanding between members of the team. Maintaining a high-level view that focuses on the user and what her journey through a task will be like helps to keep the focus on the solution and not the details of visual design. I love using Miro for this. (Bonus - it has a Sketch plugin!)

Here's a peak at one the user flow diagrams I made to show a product's current (overwhelming) process for sending receipts.

Conducting user research is an important step of not just better defining a problem, but establishing empathy for the people who are using your product. At my company, research ranges from Usability Testing, Surveys, Feedback Sessions, to forum posts in our public user group. Research summaries or reports are then shared and then usability recommendations are made for adjustments that may be necessary. Your can read more about my Usability Testing process here.

‍As a project becomes more fully understood with user stories and pain points identified, I start thinking of potential ways to approach the problem at a high level. This requires collaboration between product managers, developers, SMEs and other resources within the company.  I also work with Business Analysts to create technical and design requirements and communicate our progress with the rest of the team.

When I approach the design part of creating a solution, I typically wireframe several different directions we could go in. Here I will consult a developer to check for technical feasibility as well as other stakeholders and SMEs to garner feedback and help whittle down a solution into 1 or 2 higher fidelity designs.  Client feedback is also important in this step of the process as well, and often I will solicit feedback from clients on the resulting solutions to ensure the problem is being solved and if there is a path to iteration to make improvements.

Wireframes using bootstrap of a client feedback portal I worked on

At the end of the process I do a final handoff for developers which typically involves the sharing of links to final designs in Sketch. Once development work is completed I then assess the implementation of the design and provide feedback if any changes need to be made. Often a new feature release comes with client feedback so I also like to track NPS related to new work (or other feedback types) to gauge whether or not the designed solution worked. This is an area that I would love to get more quantitative data on post-release - did we improve a workflow as intended?  Did we save users time? Are we establishing good user habits and are they feeling empowered in their work? I always enjoy hearing that users love a new feature and that they find it valuable, but learning why they think it’s great helps me to make more great things.

‍