Re-design in progress - ETA early to mid December
Product Design
Define the problem
While it’s tempting to jump straight into a solution, it’s important to clearly define the problem(s) that need to be solved and then to move forward with a project plan that best suits it, whether it be Agile/Scrum for quick and fast execution or longer traditional product life cycles.
Ideation
One of my favorite parts of the process is coming up with as many ideas to solve the problem as I can, without judgement. Stockpiling these ideas on post-it notes or in a spreadsheet is often the easiest way to track, prioritize and evaluate them.
Iterating: Create & Evaluate
After looking at each idea for pros and cons, I like to pick my top 3 and flesh them out in quick sketches or wire-frames to get an idea of which one works in reality. It’s easy to get attached to an idea when it’s just that. Often when pixels are put onto screen, it’s easier to see which one solves the problem in the most user friendly way.
As I continue to refine the top ideas I want to get and fold feedback into them, putting these rudimentary mocks in front of users or surrogate users (pulled from within other areas of the office usually).
Evaluating Ideas
After looking at each idea for pros and cons, I like to pick my top 3 and flesh them out in quick sketches or wireframes to get an idea of which one works in reality. It’s easy to get attached to an idea when it’s just that. Often when pixels are put onto screen, it’s easier to see which one solves the problem in the most user friendly way.
Iterating
As I continue to refine the top ideas I want to get and fold feedback into them, putting these rudimentary mocks in front of users or surrogate users (pulled from within other areas of our office usually).
Often there are further steps in evaluating designs, including user testing if one has the budget or stakeholder meetings with executives or busiess owners, depending on the importance, scope and revenue involved in the project.
Execution
After the design is approved, I create final mocks, annotating any new modules, styles or pages that affect layout. I also reference user interactions in a specifications document to explain nuances of form fields, flows or other logic based user interactions/modules.
Still, when the engineering team builds the pages, I am often involved in the QA portion of the process, double-checking that everything was built to specs and works as intended, filing bugs and working with engineers to more fully explain and rectify potential misunderstandings.