Here to serve
“Design Thinking on a sprint schedule” best describes my UX process for large organizations. The Design Thinking activities and deliverables I use on projects change depending on the problem, company size, and culture. However, my leading principles remain the same.
Understand the user’s big problems
Test High Risk / High-Value Hypotheses
Work in short cycles
Learn what we need to learn
No matter the chosen process, I enjoy humanizing technology. My motivation comes from the opportunity to improve someone’s personal and professional life.
"Continuous improvement is better than delayed perfection"
Design Thinking "NNG"
Empathize - Define - Ideate - Prototype - Test - Implement
I am solving real user problems using a consistent and outcome-driven methodology. Design Thinking is both a process and an ideology. The names of phases can vary but the basics are the same. The Design Thinking model I subscribe to for large companies is from Nielsen Norman Group (NNG). You can explore the forest to learn more about each phase!
High Value & High Risk
Test High Value & High Risk ideas first. A High Value & Low Risk can often be implemented immediately. Turn your idea into a hypothesis:
We believe this [OUTCOME] will occur if [THESE USERS] successfully attain this [BENEFIT] from this [SOLUTION].
Now we can find data that supports a hypothesis and move forward. If the evidence disproves the hypothesis then we can conclusively reject it. Let's start testing and see.
WHY: I conducted user interviews in order to get a better understanding of the problem. Over the years, I have collected questions and organized them by customer service, task flow, closing, etc.
What do you think this product/feature does or will do?
How would you go about performing this task?
Was anything surprising or did not perform as expected?
When in doubt, always ask “why?”
WHY: Interviewing key people in the organization can provide you with an understanding of the business goals. Stakeholders receive feedback on products and are actively looking for new market opportunities. I've been asked to review services when there are changes in:
Increase user satisfaction
WHY: Workshops are a fun and fast way to align a team. When I run a workshop it is an opportunity for me to share as well as discover.
Kickoff Workshop: Builds trust in UX process, gets the team on the same page, create project plan, review process and challenges
Assumption/Question Mapping Workshop: By identifying deep-rooted assumptions and unknowns, we can draft potential research questions. This delivers an additional round of prioritization.
Affinity-Diagramming Workshop: Designers, stakeholders, and users have an idea of what is self-evident for a project. By taking the insights and observations and grouping them we can uncover themes around the obstacles, causes, and needs for a project.
Additional types of workshops are Problem-Framing, Discovery, Empathy, Design, Prioritization, Critique workshops, Lightning Jam Exercises, and Service Blueprinting Workshops.
“Strategy is knowing what to do when there is nothing to do.”
So far the discovery phase has allowed our team to use research as a way to describe the problem, understand why it is important, write our hypothesis, and set our goals. Now we can make some deliverables.
This quick exercise can reveal behaviors and attitudes, as well as uncover the holes in your knowledge of the user. A moderated empathy interview can gather your user's emotions and motivations. Use their responses to build a persona and get your team on the same page.
While working at Robert Half, I used data from Google Analytics, interviews, and user research to build personas. Developers and the Interactive Media Services team used the personas to improve services, sites, and apps. I enjoy updating my templates and process between projects.
A Journey Map is a tool I use to design a better outcome for the users, leading to better outcomes for the business. I have often joined teams where a Journey Map is used only as a visual representation of the customer's journey.
Service blueprinting focuses on the behind-the-scenes of how you deliver and operate. This can provide a better, quicker, and often cheaper service to your customers by reviewing your employee's process.
Low Fidelity Wireframes
In my experience, users don't provide the same feedback when the process looks finished. If I provide a user with a paper wireframe, they are more likely to contribute. Wireframes save designers, developers, and business partners time and effort. Those savings can be used where needed.
By now we are discovering a clear intent for the experience, goals, and objectives of your product. We have done the work in getting to know the user and potential paths for them to travel. Now that we have some research it is time to organize and analize the results.
User Need Statements / Stories
WHY: This step articulates a specific user's problem and how we can solve it.
What are the user's needs?
How we can help?
Why we should do it?
Defining the problem for the team and providing an actionable "why" helps me to differentiate the differences between user segments, especially in B2B situations. This step shares similarities with development tasks, user stories, epics and can be called Problem Statements or Point-of-View Statements.
WHY: By repeating why five times, you can begin to uncover the nature of the problem as well as its solution.
This is a way to help me define potential problems based on our findings. Here is the original example from Taiichi Ohno, the architect of the Toyota Production System during the 1950s:
“Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
“Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
“Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
“Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
“Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.
Audit your Content and Competition
Here are some additional steps involving potential content.
Take inventory of the content you plan to create
Group your content for desired user segments
Define your Information Architecture structure such as flat, daisy (return to main page after task), industry segments, or filtered/faceted navigation
List what differentiates you from the competition
"If you fail to plan, you are planning to fail."
A charter document can help with large organizations. Mine contains:
Overview of the project scope
The scope, objectives, and people involved should be clear and concise. This document is more the marketing and project management side of me. Creating a charter means it gets approved quicker, everyone knows their part, and scope creep is less likely due to documentation.
Mood boards help especially with companies who have not solidified their brand or have no style guide. This can give guidance and communicate visually to the team what you are aiming for on the project. For established companies, I pull from my swipe file and stock photo services with potential images we can use on a project.
Finalize your Decisions
Documentation now looks a little more detailed and some decisions should be finalized.
Goals and objectives
Sitemap listing major categories
Finalized features and functionality
End-to-end user journeys
The define phase is a perfect stage to glean insights from your research. This is the time to create a clear path for your users, don't leave it to chance. Organize the team's observations and make connections. Look for common pain points across each user segment? Plan ways to meet their needs.
Here we want to test the prototype and not the user, making ideas tactile. See how your users interact with and react to your product's design. Here are some objectives I have learned over time.
Prototype Basics: Choose the prototype best suited for the stage you're at, clearly define what your prototype is meant to achieve, use the right tool for interaction, and prototype often and as necessary.
Provide Users with Options: Users can tell you which they prefer by making comparisons. Just change a variable at a time and they will review what they like and dislike.
Low Fidelity First: When I started out, I would skip this and go to high fidelity. User's provided less feedback with prototypes that look complete, thinking choices have been made about the process. The price of a bad design is high so I suggest you don't rush.
Watch Them Work Through It: Ask users to talk through their experience. You are here to observe. If they are off track just ask them "What are you thinking right now as you are doing this?" Negative feedback is how we learn.
Your first solution rarely looks like your final solution. Great ideas come from everyone. I like to keep design iterative and based on feedback, focusing on continuous improvement. Testing, improving, and testing again until you have obtained the minimum viable product.
Here are some things that have helped me with this:
Minimum Viable Product: Deconstruct your service or product to its bare minimum. Successful companies start out by doing one thing well.
Release What Works: If you release a flawed mobile app, you can count on negative ratings and deletions. Having customers say, "I wish it could do this" is better than "It can't even do the one simple thing I bought it for!"
Short Mobile Release Cycles: Keep releases small and focused. Don't get in your own way by adding features before they are ready. Fix errors quickly. Release features on a schedule by promising and delivering on that promise. Falling off the app store charts can happen faster than reaching the top.
"Rule of thumb for UX: More options, more problems."
Figma and Framer are my favorite interactive tools. You need to be constantly building, testing, and iterating during the Develop phase. I can swap out static elements and replace them with interactive components for fast turn around. Over the years, I have helped build many design libraries for myself that can be updated quickly for a specific client. Having cloud-based programs allow partners to see my changes and give instant feedback right in the browser.
Quick Findings Report
This short and informal document contains an executive summary, major findings & recommendations, research samples, and methodologies. I've distributed these in emails, scheduled newsletters, PowerPoints, intranet pages, and dashboards. Great way to update shareholders and promote the UX Team. Archiving reports help with consistency and long-term reviews.
Depending on the findings, and company, I would recommend releasing smaller "quick findings" reports while working on the Usability Report to prevent complete silence with your customers.
Background summary: What was tested, where and when, the tools used, and who was involved in the research.
Methodology: The evaluation process, what tasks users performed, type of data collected, what scenarios were used, who participated and their demographics
Test results: An analysis of the data, data visualizations, and enlightening user comments and feedback. Generally, I include more technical details than in the quick findings report
Findings and Recommendations: What the UX team recommends, based on findings? Write down what worked well, what didn’t and why. State what should be done next to improve the design or move forward with the process. I organize this in a findings walkthrough, positive/negative, and "eureka!"
My Additions: Finding Summary Table with issue type, description, location, recommendation, difficulty level, and actionable recommendations.
I like to write the report as it is happening based on my notes and then summarize to < 3 pages for executives, expand on those findings for Quick Findings Report, and then full Usability Report. Generating documentation throughout the process makes final documentation easier. The size of these reports depends on the frequency of reporting. I generally have a full usability report with additional comments for the UX team for future projects.
Prep Analytics Reports & Dashboards
Analytics Reports can define a baseline and track trends in order to define goals, strategies, and concepts for a brighter tomorrow. Google Analytics is one of my main sources outside of internal stats and I've used it daily for years and have automated much of the reporting.
I can automate daily, weekly, or monthly reports to be emailed to individuals or a team's site for archival as CSVs or PDFs. I have also set up enterprise connectors for Google Analytics to provide real-time data to Tableau, DOMO, and Power Bi.
Dashboards are amazing tools for providing a single source of real-time data, allowing for interaction and analysis. Data-based-decisions are my goal for any company. I generally create a dashboard that answers 3 to 5 questions for clients, and more in-depth dashboards for the UX team. Dashboards allow data visualizations to tell a story, provide metrics in real-time, and on mobile.
A word of caution: Google Analytics does not answer "why" a user does something. It also tracks "devices" and not users out of the box. It is not an attendance sheet and the legality of tracking personal information can vary from country to country.
Promoting the Changes
Help get your customers excited about the upcoming changes early. Give them reasons to be psyched. Nurturing interest for your product can help us validate whether they like it. This can better prepare us for their feedback.
You can either plan to test your product or have your customers do it for you. Testing prototypes allows companies to prevent customers from seeing avoidable failures. There is no perfect app or way to satisfy every customer. We can, however, provide an amazing experience for our target customer.
User Interface Testing
WHY: User Interface Testing (AKA UI Validating) is the process of testing the visual elements of an application to validate the performance and functionality.
The UI is how the user interacts with your product. Testing UI can show how easy is it for the user to understand your design
I recommend a least some human UI Testing but many aspects can be done by software applications as well. You want to check:
All elements for size, position, width, length, and acceptance of characters or numbers
Fonts, color, alignment, and image clarity
Users can perform all functions with intended UI
Device/Screen resolution compatability
Error Messages display correctly
User Acceptance Testing
User Acceptance Testing (UAT) ensures the system is functioning as planned, meeting the goals of the design phase.
3 Most common or difficult tasks
Applications are stable and work as intended
All business transactions are properly integrated into the process
Achieved data flow and data integrity across applications
Ensure compatibility to devices, browsers & operating systems if applicable
Overall performance of the application or product
The main purpose of UAT is to validate the end-to-end business flow, unlike system testing where we are looking for errors. I look to UAT for a summary of how the product works in real-life scenarios.
Though not performed by UX, it is important to know when this process is complete so User Acceptance Testing (UAT) can be scheduled. System testing is not only testing for errors in the software but the entire computer-based system as a whole. It is best to complete this phase before UAT so users can see what
Finalize and Deploy
Your product is live. You listened to users, defined a problem, workshopped ways to solve it, and delivered something. Its not easy but you did it. Congratulations!!!
"That which hinders your task is your task."
Say that five times fast!
Analytics Reporting and Review
Tracking a benchmark prior to launch. In the past, I have worked with the Dev team to ensure the tracking code is in place as early as possible, preferably a month in advance. It's important to have a benchmark in place so you can gauge your success.
Scheduled status reports begin immediately after release in intervals ranging from the 1st day, through the 1st year, eventually moth over month and year over year. I usually have as many of the reports automated or sent to a dashboard as possible.
On top of the documentation for the development team, it is great to document how the project went. This can even be considered the 5th D step.
What moved us forward and what hindered the process?
What feedback did users provide about this experience?
What aspects of the experience were effective?
How well did we solve the issue for our users?
What is our adoption rate?
What contributed to these numbers?
How did the users describe the impact of this product on their lives?
Did users indicate the product is relevant and applicable?
What the project a success?
What parts were successful?
What can we improve?
Did we involve the best people, in the best ways, at the best times?
What should we do the same and differently in similar projects?
Documentation often has its own step in the design process. It helps with transparency, promotion, repeatability, and accountability. Documenting during the entire process improves recollection and time spent during the wrap-up phase. Previous companies I've worked for have used document management systems, intranet sites, OneNote, Google Docs, etc.
Staying consistent begins with knowing what happened in past projects, access to the materials used, and how it was achieved. Aim for clear a description of the process and procedures. Great documentation provides each decision and the story behind why they were made.
Celebrating achievements does not mean a trip to year trip to Bora Bora after each sprint. The most important celebration I use is a Thank You Card. I am known for giving thoughtful notes and my team's happiness is important to me. I usually write them on a physical card for larger achievements and a three-paragraph "hero of the day" style for jobs well done. Sometimes I am not aware of how much effort a team member took to accomplish my task. This is why it is important to thank them.
Build a culture of gratitude within the company throughout the project takes time but is important for longterm success. In the past, I have run movie clubs, Yammer groups, group lunches, as well as social get-togethers both in-person and virtual. I want my team to know I am continually grateful.
Understand, Improve, Apply
Over the years I gathered many ideas from different Design Thinking methodologies: Deep-Dive from IDEO, Human Centred Design, 4 D's from Design Council of the UK, and What x 4. They are the map I use to navigate the project but only give you a general outline.
Now that I have over a decade of practical knowledge, I see the peaks and valleys of a project. I know when to tell the team we are almost at the top or take a different trail to save some time. This experience allows me to travel lean, bringing just what I need for this project.
I look forward to working with you.