Design: An Impractical UX
A Practical Approach to UX
Design System vs Design Process
"What is your design process?" This is one of the top questions a UX Designer will be asked in interviews. Having been a hiring manager for some time now I've reviewed a steady stream of websites and had countless discussion about what designers processes are.
We explore user centered design (UCD), getting to know the customer and empathizing with them and their environment. We explore multiple methods for gathering data and defining the users challenge. We talk of the ideation phase and generating a flow of possible solutions. We then move on to creating multiple fidelities of prototypes to test out our ideas and gather feedback for iteration as we rarely get it right on the first go round. Then we can review the various methodologies for user testing, gathering qualitative, quantitative and behavioral analytics, conducting moderated and unmoderated testing to validate our prototype. Finally, after multiple iterations and tweaks we can implement our design and then work the process all over again until we get it right or come as close as time, resources and patience will allow.
If we change the lens of this question and rephrase it to what's your design system process I think that's a more relative question for the discussion around management of UX teams.
As we move beyond a single contributor and look at scaling our design process across a team and organization it is much different than how you individually design a feature or tool. I think this is less addressed in books, blogs and general conversation and something I'd like to explore further.
It will take some time to get from individual design process to creating a whole design system in an organization. We've got to learn to crawl before we can walk and eventually run. It's then that we can start to look at how to manage people, tools, patterns, guidelines and brand to create our design system.
I feel comfortable not providing a detailed exploration of each of these steps at this point as I feel I've touched on this process above and navigated those waters repeatedly as I completed UX certifications through NNg and MIT that helped me 'master' design thinking.
Reality Check, Surviving the First Year
I've titled this site Impractical UX as my experience has been that most jobs are not the ideal for running UX by the book. Most organizations are not mature enough to be fertile soil for supporting all the processes, methodologies and tools you'd wish to employ as a UX practitioner.
Instead it has been my experience that the reality is that companies are not totally dedicated to supporting UX as a holistic practice. Usually there is a desire from the top down or perhaps grass roots as people become acquinted with the benefits of understanding their customers and delivering them value. You're much more likely to be confronted with people who will not believe and challenge you at every step along the way. If you have not felt this confrontation or challenge in your organization count yourself lucky and blessed to be in an organization that's mature enough to embrace you and your efforts.
The norm with most organizations is to have you start out with UX as the number one or two person practicing UX. Many times you are “the UX” person, performing all the jobs that UX people do, from UX Strategy, research, design, interaction, visual design, and writing and visual design or what people really understand or focus on is how you "made it pretty".
In Cases like this I’d love to say you can spend copious amounts of time in each step, doing discovery work, research, performing competitive analysis, content audits, card and tree sorting, user testing and validation across and do that across multiple project teams, but that’s really just not humanly possible.
Instead it’s much more practical to do as our friend Bill Murray says and use baby steps. You have to ease into things, stretching here and there until people are ready to accept you as an authority and understand the value you bring. Like most things in life you have to prove yourself before people will turn the keys over to you.
Chances are you’ll start by working with product owners or developers, or both that have had the responsibility for 'doing design' and they aren’t eager to relinquish that control. It’s like caring for a baby after a fashion, you have to prove to them that you won’t let their dear child parish. They’ve sunk blood, sweat and tear into these projects and you have to earn their trust.
If you come in spouting things like Confirmation Bias, Magic Number 7 +-2, Jakob Nielson this and Don Norman that walls will go up. My dear wife always said, "people don’t care how much you know until they know how much you care". In a non-threatening or challenging way, usually through some sort of visual proof you can slowly show them you really do care and want the best for the product. As with most UX practices, if you can bring them along for the ride with you they can see how the sausages are made and come to appreciate the need and value that UX provides.
In many cases this can be difficult as you are just starting out and your UX legs can be a bit shaky. Many times you're also trying to apply your learning in a new organization, industry and with new people and it can be difficult as you'd like people to just trust you. However that trust has to be earned and things will go much better if you can show more transparency and help people understand that you may not have all the answers right away but that you'll put in the time to connect the dots and show the value of what you want the team to do as a unit.
At this point you aren’t always able to run through hand sketches, paper prototypes, low-fidelity wireframes, high-fidelity prototypes, perform in-depth testing and check all the boxes, you’re just trying to keep your head above water and get some projects across the finish line. You're really just trying to show some value in the UX process to justify further investment.
This means we start with bringing in standards and heuristics. I’ve found this very useful in deflecting constant confrontations with supporting how you want to do something. If you can work with the team, your PO and devs you can establish standards. That way when there is ever any argument you can say, I think we should do it this way because that’s the standard we’ve set and consistency in the experience is so important for us to achieve. Now this doesn’t mean that you never have to give in or change your standards, but you can setup a process for that too.
Creating a process also helps lead to making decisions based on data. By saying we can make changes to our standards, we just need to bring enough supporting data or research to provide a convincing argument to change it. Now we’ve taken two steps that are actually very large for an organization in a relatively easy fashion. We have standards and we’ve created a way to change them. Showing that you're not rigid and willing to work with them is very helpful because as they say Rome wasn't built in a day. You're going to have to make compromises along the way and realize the progress in stages. It's easy to want to jump towards being the embodiment of Jakob Nielson in the first month, but reality is that it will take time and patience to see this come to fruition.
The Dreaded B-Word
The Dreaded B-Word at this stage is like an albatross circling around your neck. You and the person who hired you have convinced the organization that bringing UX into the mix will make things better.
The common objection becomes, "we don’t have time for that". A new UXer will always be fighting the dreaded B word, and that’s becoming a bottleneck. Product Owners and developers love to use this as evidence for not wanting to conform to your recommendations or completing your design 100%. We don’t have time for that or that takes too much time are a few of my least favorite utterances. They are a reality we often have to deal with though and so we have to prove to our teams that testing and doing design right doesn’t have to take weeks or months to do, in many cases we can test in a relatively short amount of time.
I don't want to paint PO's in a poor light here, in many cases they are just trying to survive themselves and trying to optimize the process to get more product out the door. As Marty Cagan talks about in his book Inspired, being a product owner is one of the most difficult and time consuming jobs there is. As a UX professional you need to help them understand that UX doesn't have to take as much time as they fear and that the benefits of delivering the right product or at least a better version of the product will be worth the wait.
If you haven't read the Inspired book I highly recommend it as know where the lanes of the product owner and the UX practitionar are will be very helpful as you discuss with your team what work is and is not in your lane. These assignments can differ from organization to organization so it's helpful to have that discussion from the beginning with your PO and team.
As a general rule the PO will be responsible for what get's made and UX will be responsible for how it's made from a visual and experiential perspective. I've found you need to be careful with this statement around developers as they think the how belongs to them. At this point it's a matter of semantics. The UX how is from an experience standpoint and the development how is from a technical standpoint.
In all these cases it's optimal to have these rails be guidelines and each team member should be able to freely explore helping out in other lanes when needed. You need to be able to help out with product definition or front-end development when needed. If you're swarming as a team to get software working you should be able to lend a hand when asked for, but be cognoscente enough to know when that's needed and wanted so you don't find yourself drunk driving in someone else's lane.
Adding Processes, Methodologies and Tools with New Team Members
As your organization starts to mature and become more accepting you can start to add more processes, methodologies, tools and hopefully more team members.
As you start to think about design process and creating a design system more in terms of interaction within your organization and eventually your team rather than just strictly the process for designing features we can start to look at each of these individually.
You’ll need to define or expand a way for working with new or existing teams, how do you get work, how do you manage it, how do others interact with it, how do you work with people prior and post to add pieces to the work.
You’ll have people you interact with who provide content or strategy and you need a process for incorporating the direction and assets they provide for you such as the voice and tone of the word track or marketing lifestyle photos. Before you start to even ideating on the designs there are several pieces that need to be integrated into your workflow.
Likewise when you’ve completed your work, many times you may have a marketing department that provided visual design or you may go to UX Engineers or Front-End Developers that you need to work with and you need a process for handing off the assets and proliferating design and implementation instructions.
Adding Processes: What Depth of UX is Needed?
Along with pre and post interactions within your teams you’ll need to decide on what level of interaction is needed for this specific product or feature. Is it something simple that you can use existing research, standards and designs on, or do you need to do discovery work to explore the whole breadth of possibilities? You’ll likely then have multiple design process forks at this point for handling new features or large redesigns verses redesigning existing features within standard sprint work.
Adding Processes: New Features/Large Redesigns
For new features or large redesigns we need a discover process that allows us to better understand the scope of the project and customers wants and needs.
For this process I’ve put together a process that combines discovery research and design sprints that have been popularized by Google as of late.
First I start of by working with the designer for the project and our UX Research team to do a Sprint 0 research sprint.
I’ve trained and sought training for the designers and researchers on a number of methodologies we can use to better understand the requirements and competitive landscape. Many of these will need to be done in conjunction with journey owners or stakeholders. All of them are not necessary all of the time, but I try to make the team aware of each methodology and when they are used so when the appropriate need arises they know which methodologies and tools to choose.
- Value Proposition -we seek to understand the basics key aspect of the project, what it is, who it’s for and when or where will it be used.
- Personas -Previously we’ve created persona silhouettes that a generalizations of our various customers that can be used and or extended to fit the needs of the project.
- User Journeys -We seek to understand from each of our personas their journey in relation to this product or feature and the points they interact with them. This really helps us focus on doing research for all the personas and all the touchpoints in our organization.
- KPI’s -Defining the KPI’s is helpful for the entire project and the next steps in our design sprint. We need to know how we are going to measure the success of this project and how we recognize if we’re making things better or worse.
- Competitive Analysis -It’s my experience that most designers love this part, scouring the internet, looking at competitors and industry leaders who have similar functionalities in production. We always keep the perspective that it will be very difficult to know if this is working for the competition. We don’t know if they’re conducting a test, or if the way their feature is looking and performing is bringing the desired results.
- Stakeholder Interviews -We’ve created stakeholders that are in charge of each of our personas journeys and manage the work within that process. There are also other knowledgeable people within the organization or on our team that have relevant information that can be helpful in understanding the customer and their needs.
- User Interviews -Whether in-person or with one of our tools like Loop11, we seek to conduct both moderated and unmoderated user interviews to gain more insight into customer wants and needs.
- Task Analysis -This is where we put on our BA hat and start to break down the tasks that a user goes through on existing tools or a conglomeration of self-built processes for accomplishing their work. This is where User Centered Design really shines through. We try to understand the user and their environments that will help influence our future requirements and designs.
- Content Audit -At times we may be redesigning an existing tool and we want to understand the current landscape, what pieces we have in place already, what processes were currently sending customers through so we can evaluate if we need to replicate a process/feature or sunset it.
- Design Thinking -We try to save a lot of this for the design sprints themselves, but a designer may want to go off an explore some possibilities for some features or products. This is where our traditional design process comes into play.
- Mood Board -Mood boards are handy for our designers in that we can work with Marketing to start exploring the assets they will want to use for this projects. What mood will be created, is it different from our current brand on purpose, what is the look and feel we’re going after?
- User Flow -This is a primary skill for our designers, having thought through the tasks the users will perform, what are the new and improved flows we want to come up with for our feature/product that meet the customers’ needs and wants.
- IA -This is important for whenever we’re working with something that changes our navigation, search, form or feature labeling and general organization of the information on our pages and throughout our site. It gives us a chance to think about how will this piece fit in with the rest of everything.
- Heuristic Analysis -This type of review can be handy when looking at what didn’t work in the existing feature or product. and how can we get it to be more in line with existing standards and best practices.
- Behavioral Analysis -This type of research has been very popular with all our team members from designers to PO’s to developers. Using tools like Hotjar to see click maps, scroll maps and actually review users sessions is so telling and eye opening for those who have not experienced it before. I love to see the lightbulbs come on for product owners or other team members as they see what customers actually do rather than long-held company lore or gut feelings.
- Qualitative Analysis -Along with interviews we do additional unmoderated research like online surveys or Qualtrics intercepts to get Net Promotor sentiment about various experiences.
- Quantitative Analysis -Google Analytics is our tool of choice for the numbers. Seeing conversions, bounce rate, time on page, etc. help fit one piece of the puzzle into our collective knowledge to understand customer habits.
- A/B Testing -Using Google optimize is a tool that can easily make me forget Sketch. I use Sketch for everything, I love design, but waking up each morning to see which variant in my test is performing better is addicting. I love being able to create alternative interfaces based on data and prove out the theories.
- Accessibility Analysis -Whether we use online contrast checking tools or run validations in our browsers to test accessibility this is always important to help those with visual challenges and help the company fend of undesirable consequences.
- Performance Analysis -This one has long been an arrow in my quiver from the early development days. I’ve had too many up and close experiences with how performance affects users experience, perception and the bottom line of the company not to use tools like Lighthouse and Webpagetests to find out how our websites are performing.
- Usability Testing -This never fails to get me, so many times when we’ve created tests on sites that we’ve been working on for long periods of time we find places where things fall down. Tasks that would seem rudimentary and obvious can become showstoppers and help serve to remind us that we are not the users!
- Sketches -Whether it’s hand sketching with pencil and paper, on our iPads or with Sketch, this is an indispensable tool for design work.
- Prototypes -Using tools like InVision, Abstract and now prototyping tools built in to our design applications allow us to create clickable prototypes. With the proliferation of UX Engineers on my teams I’ve sought to take this to the next step in using our design system components to help quickly build lifelike prototypes.
- Feature Roadmap -I love conducting design sprints and helping product owners see how conducting design sprints can bring real value to their feature roadmaps and backlogs. Having the whole team help define what features will be built is a huge win.
Adding Processes: Progressive Design Sprints
As with the nature of baby steps throughout this whole design process we needed to approach design sprints with the same iterative integration. Few organizations will whole-heartedly say, "sure, we have a week to spare to do ‚research‚". You have to show them the benefits step by step and let them see the value they provide. My first approach was to carve off an hour or two each day for each of the phases, and then after that I had multiple product owners commenting on how great design sprints are and how they’ve helped their teams.
Now, after conducting about a dozen design sprints we’ve garnered the support to start looking at how we can integrate these more holistically into the way we do work.