Why I’m Different
“What I find most striking about him is his unique mix of critical thinking and creativity. He can get to the essence of problems and opportunities, weigh priorities and tradeoffs, as well as structure projects and plans...But he is also a natural and gifted designer. From information architecture to interaction design to visual design, he uses his knowledge, experience, and creativity to design, simplify, and harmonize user experiences that our users are excited about.”
When most people look at my resume and see the duality between software product management and product design, they immediately think, well, he has a business analysis background, so he must be more on the problem space than the solution space. When I get asked questions about this, my answer is always the same, I can go deep into both areas, from product strategy/market fit to pixel perfect hi fidelity comps.
Ultimately, my passion is for solution design, especially with new product development. Sure, I can do commoditized design, we all know what established design patterns such as consumer ecommerce checkout flows look like. However, I excel at solving complex UX problems because the inherent processes being supported are well...complex. From in-depth, qualitative user research to information architecture, interaction design, UI design, and the creation of design systems, I can go from unearthing true user needs/insights to translating those into highly usable, aesthetically pleasing solutions. I’m a player/coach who truly believes to properly manage and grow design talent you clearly have to have done it and need to continue doing so to keep skills sharp/relevant. No one wants to learn from someone who isn’t up-to-date on the latest tools and trends.
I also understand how to throttle based on the project, product, and task at hand. Do you need to create fully interactive prototypes for every project? NOPE. Sometimes, it’s a brainstorming session with a product manager and a few engineers with some user flows sketched out on a whiteboard. It always depends on the goal, importance and risk. I’d like to think my ability to calibrate is very good, choosing the right approach, effort, and toolset at the right time for the right project. I am able to regularly switch between macro level “big picture” design and micro level design all while keeping the business needs in mind along with all the other constraints (time, budget, tech debt, existing configuration, tech stack, etc.).
Design Approach
Approaches to UX and software product design all start to sound very similar after a while. To be honest, much of it is the same, at least on paper and in terms of general process. Honestly, it reminds me of all the different versions of Agile, which in my opinion, are just various rehashings of the original agile framework from the Agile Manifesto. In some cases, intentions are pure, trying to utilize Agile in a way that fits OUR COMPANY processes, in other cases, these frameworks are used to sell Agile to clients that don’t know any better. With most of these frameworks, 2 key components seem to be getting lost. User feedback and actual iteration, not all this ship and forget feature work going on. Sometimes it might make sense, oftentimes, it doesn’t. You need to iterate on a feature so that it’s at least good enough and hits whatever business goal it set out to achieve.
Look, I get it all too. Everyone wants to come up with the perfect process to get work done. Unfortunately, I don’t think there is such a thing, so it’s figuring out something that does work, fosters cross-functional collaboration and leads to great product outcomes. So why do I bring up the Agile example, such a hotly debated topic that might cause anyone reading this to just stop? Well, it’s because there are similarities happening when it comes to design processes. Everyone seemingly has their own special model, from the Double Diamond Method to various renditions of a Design Thinking process. I’d like to point out one aspect I believe is always missing from those lovely design process diagrams. The people involved. So, I’d like to preface that collaboration with Product Management, Engineering, Users, Internal Stakeholders, , External Stakeholders and of course, your own Design team should be happening in some form in many, if not all, of these phases. Share the research knowledge, understand technical feasibility early, use inclusive ideation phases where possible, and crowdsource design feedback internally where possible. Sure the focus needs to be on the user, but holistic cross-functional design collaboration leads to better software products, helps build organizational UX maturity, and frankly, is a lot more fun. In the end, these models all boil down to my version with the phases listed below.
Research
Learn what they do and how / why they do it. Ask why...A LOT.
I am a huge proponent of qualitative methods like user interviews, fields studies, contextual inquiry, etc. Actually talking to users provides amazing insights and needs to be a habit of any design team. However, data driven design has it’s place and can provide key insights you cannot get from talking to users. They tell you one thing, but analytics show their user journey tells a different story.
Analysis/Definition
- Understand the issues/pain points/needs, really digging into the core to get definition.
- Affinity mapping, card sorts, Post It notes, various prioritization techniques (Kano Analysis, MoSCoW method, etc)
Ideation/Brainstorming
- More affinity mapping, card sorts, and lots of Post It notes for design ideas
- Conceptual designs, sketching, proposed task/user/work flows, storyboards, etc
Design
Sometimes when designing it’s easy to want to “over design”. Keep the focus on the research and defined scope never losing sight of it. Let the user be your guide to what they do, how they do it, and problems they face. Arm your product managers with this information. It will help them make better decisions and they will love you for it.
- Users don’t want to spend a lot of time completing simple tasks.
- Focus on primary actions and eliminate clicks/taps, unnecessary overlays, navigation, and UI distraction.
- Reduce cognitive load and avoid creating a swiss army knife.
- Use intuitive UX / UI / IA / IxD. Follow mental models.
Hone in on key tasks and process steps so new users can jump right in. Allow for discoverability of advanced features, but don’t clutter the UI with them, unless of course, THAT IS your target user.
Come up with a number of possible solutions, don’t just focus on one. Eventually, you'll have to hone in on one solution, but make sure that choice came after evaluating alternatives.
Validation/Testing
Validation and testing of wireframes, user flows, prototypes, visual comps, developed software, it just depends on what stage of the process you are at.
Received valuable feedback?
Deliverables
I separated deliverables because each of the phases above will have their own depending on the project. Maybe you needed to do in-depth evaluative research, so ended up with some user personas and journey maps. Maybe it was a time sensitive, tactical item that just required a whiteboarding session with engineers. Maybe it was a brand new workflow that required a full fledged design prototype illustrating key interactions for engineering. The point is, every project, feature, task, work item, etc will have a specific deliverable or set of deliverables that will depend on the size, scope, time, budget, etc. involved. Like I mentioned above, it’s all about proper calibration given the needs, circumstances, and constraints.
User Journey Maps
User/Task Flows
Hi Fidelity Comps
Annotated Workflows
Simple Sketches
