Let’s not pretend all projects and products fit neatly into the same mold. Between deadlines, budgets, business needs, resources, etc. a design process must be a living, changing concept. That being said, here are the broad strokes of mine.
I first like to see where we stand. What are the business goals? How do we define success? Is this a phase 2? Are there findings from phase 1? What have our competitors been up to? Any changes in the market? Have we identified our key demos? Any changes in those? What about technology? It’s a comprehensive scan of the lay of the land. Without it you’re pushing a canoe into a river with no idea what’s around the bend.
This is the most important step and the one most often skipped. You can’t design for your users if you don’t know your users. Talk to them. Like actually talk to them. So often the problem we first aim to solve with our product or feature ends up being either not the actual problem at all or just the tip of the iceberg. Without live, dynamic conversations you’re, in the best case, leaving money on the table. In the worst case you’re creating a product doomed to never find traction.
It’s also important to talk with stakeholders, developers, product owners, marketing, anyone internal that touches the end result. These conversations not only get everyone on the same page; they also help define any business or technical limitations.
Once a user problem is found it’s time to brainstorm the best ways to solve it. Enter whiteboards, Post-its, maybe even an early flow chart or two. Once you have a few viable options, it’s ideal to go back and talk to those users and stakeholders again.
Now it’s time to whittle the field down to the most promising contenders and make some prototypes. Sometimes that means actually working with a developer to create live demos, but more often it means creating and stitching together wires in XD or firing up InVision.
Time to test those prototypes. If we’re confident enough in the problem/solution fit, I’m usually fine using remote testing tools like Usertesting.com. Initial tests are less about usability and more about general understanding and reception of the product. Once market fit is established, I turn to task-based usability testing.
Often times this step proves we were operating on false assumptions, proposed the wrong solution, etc. in which case it’s back to any one of the previous steps.
Once the wires and flows are validated they’re sent for visual design. Depending on the feature or product, this step may be lumped into the Prototyping and/or Validating phases. It’s at this point we make sure we’ve designed with accessibility in mind.
Communication with the developers should be ongoing throughout the prototyping and validating phases. Ideally a working demo has already been built using Agile design/development principles. Short of that, this is when requirements are written, design documentation is delivered and, after some amount of time, a product or feature is launched. In a perfect world multiple versions of a product or feature are launched for apples-to-apples A/B testing.
Remember those measures of success? Here’s where they come back into play. How’d we do? Did we A/B test? Which won? By how much? How are users using the features? Which outcomes did we expect? Which did we not expect? Most importantly, this postmortem is where we plan the next phase and access how the team worked as a whole.