Ever wanted to design a user experience but felt limited by your technology stack, language, or framework? Here is a tried and true 5-step user experience workflow to help facilitate building a UX for now while planning for the future.
The amount of frameworks, platforms, languages that are available to us when designing a User Experience (UX)—whether you sit on the UX analyst side or on the UX practitioner side, you encounter this plethora of things on a daily basis. So how do we tune out all the noise of this digital ocean and design/develop an experience for our users that is agnostic of choices based on these outside factors? How do we provide a user with the best experience we are capable of giving them while planning for future enhancement?
Stick with this article and I'll walk you through my five-step process of doing just that—there are many like it but this one is mine.
Note: This article is written in the context of delivering to an enterprise client with multiple stakeholders, teams, etc. This does not change the premise of this workflow.
You've met with your stakeholders, you've discussed the ins and outs of what you need to do to keep them happy, and now you need to put words into action to start developing your experience strategy and wireframes.
What are the core requirements of their requests? Format them in statements, such as, "As a user I need to X." Or, if you got more specific, "As a specific persona I need to do X," Once you have these statements, start to break down these concepts in to smaller pieces that are functionally possible.
At this stage, don't think about functional possibilities or your specific environment. Purely focus on the platform-agnostic experience. At the end of this step, you should have a list of discrete actions and steps to achieve the stakeholder goals for your project.
The next thing you want to do when understanding your goals for this project is to think within the mind of your personas. What are the discrete goals and actions each user needs to take?
Some or most of these will likely come from your list in step 1, or by breaking down items from step 1 into smaller actions. Can you align goals from the stakeholder conversation to individual personas? A great way to visualize this information is a goals & actions table (example below) organized by persona and their primary goal when browsing this site.
In step 3, we still are not thinking about our frameworks, languages, or any other technical limitations. Sometimes a UX person handles this part, and sometimes it's a combination of a content strategist and a UX person.
Now that we have our goals and actions, we need to plan out the rhythm and flow of these on each page that we are wireframing. On each page, you are designing an experience for a specific persona or multiple personas. What are those primary goals or "Call to actions" (CTA) that these users need to complete on this page? What are the steps and actions that a user will take on this page to take them through to these actions? You should know this based on your step 1 list, and the table you put together on step 2.
It sometimes helps to map these steps out for each persona so that you have a visual representation of how this particular persona might browse the page. This also serves as a great tool for communicating user behaviors to non UX team members.
Once you have a chart like this for each of your pages, you can start to develop the flow of content on the page in a modular fashion. Each section should drive the persona(s) down the page to a specific CTA to take them down the funnel of their journey toward their goal.
Now that we have gathered goals & actions, persona journey maps, and base level wireframes, we can start to think how we can accomplish these within our environment.
Now would be a great time to chat with your development team to tell them what you are trying to achieve with your experience using your wireframes to guide that conversations. It should be a partnership, and there should be some shared knowledge and understanding of what is possible. Since ultimately they are building it, they may be able to help you break down certain challenges into smaller functionality chunks.
You should also come armed with your own research about the platform the product is being developed in. Is this being built in React? Maybe read the development documentation or research React components that you might need to use. Is it native iOS? How about reading Apple's Human Interface Guidelines (HIG) for developing iOS apps?
Not only will this knowledge help you when developing your experience—it also will show the development team that you are willing to put in the work to understand their technical limitations and to work within their parameters while also trying to achieve the best experience for your users.
Planning for enhancement is about two things: Reducing the overall steps it takes to achieve a goal or complete a task, and enhancing existing experiences to make them better based on new capabilities of your tech stack.
As you start to wireframe, think, "What is the minimum functionality I can provide the user to meet this goal today?" Is there a goal or functionality that you can not accomplish? If the answer is yes, can you break this functionality into more steps in order to facilitate this functionality? Even if this means providing more manual steps for the user?
If you are able to break it out into more steps, it also makes sense to think of the future. What developments in your tech stack would help you reduce the amount of steps it takes to complete this goal?
As an experience designer who is also a developer, I often think of progressive enhancement, which is this exact thought process when it comes to coding a piece of software/website. Your goal is to make a seamless experience for your user. The user should never know that you are providing limited functionality, but you as the experience designer should always be thinking about ways to improve and enhance their experience throughout the lifespan of your product.
With siloed teams, it's easy to just "throw something over the wall" and let the next team deal with it. But you are the advocate for the user, and you should work hand in hand with development to ensure the experience you planned translates well within the development cycle.
If you don't have day-to-day communication with the development team, how can you effectively communicate planned functionality? Can you build a prototype with a tool like Adobe XD? Can you collaborate with them using a tool like Unite UX? Can you screenshare? Can you set up a daily or weekly scrum to work with the team remotely to ensure things are getting executed according to your planned experience?
Whatever method you end up using, it's your job to own the UX, which is up to and through the development of the product.
Consider this guide a suggested framework for designing a UX for the now while planning for the future.
This is the workflow I use day in and day out for my own projects, but I encourage you to tweak and change things to suit your own workflow/environment.
Again, it is important to understand that you, as the UX expert, own the experience for a project. Ensuring your experience is executed exactly as you intended is important not only for your own reputation, but also for the overall experience for your users.
Joe DeVito is a results-driven leader with over 10 years of experience in the digital space. Joe specializes in Technical Architecture, Usability, and Immersive Digital Experiences. Throughout his experience with Blindsheep Digital, UDig, and Booz Allen, Joe has led large teams on enterprise-level web and software application projects. His clients have included Army, Navy, and Securities Exchange Commission (SEC.gov). Joe has exposure to many industries and types of businesses, which enables him as an effective leader and allows him to be the common thread between development teams, design teams, and his client stakeholders.
Subscribe to be the first to get our expert-written articles and tutorials for developers!