5 Minute Read
User Experience Design
User Experience (UX) design happens when the greatest number and diversity of professional domains magically converge. Software projects are a hive of frantic activity in the early stages. Strategic leaders, Subject Matter Experts (SMEs), technical decision makers, project managers, and business analysts toil along separate paths to come up with requirements for:
- What should a product do?
- What technologies will be used?
- What resources will be available to meet the product’s objectives?
Eventually, these efforts must rendezvous in the form of designs. Teams that act upstream and downstream from each other typically lack common ground — individuals who write business requirements can't read lines of source code. Developers often have limited knowledge when it comes to the details of business processes. Detailed visual representation of how the end product should look and behave empowers both teams by placing them on common ground. Everyone gets a glimpse of what will be delivered. I cannot emphasize enough that looks and behavior factors are key to nailing great user experiences; a skilled UX designer can bless both factors with brand-aligned appearances and psychologically pleasing interactions.
Early Project Activities Help UX Teams
Before the first lines of code are written on a software project, you can expect a large amount of collaboration among professionals with diverse backgrounds, different professional domains, and conflicting interests. The grandiose visions of strategic leaders can conflict with scope-controlling project managers. Technical decision-makers tend to stick with familiar technologies to the chagrin of Subject Matter Experts (SMEs). Concurrently, business analysts need to somehow deconstruct the entirety of the project into bite-size work packages (these are called user stories). In one form or another, contributors to this “pre-coding” phase of software projects need a platform to convene, socialize ideas, hold debates, make decisions, and produce finalized and approved designs. Everything should be in place — for once the coding starts actually happening, the labor, morale, and technical costs of going back and revisiting these activities explodes. Leaders who turn their teams loose without proper collaboration platforms do everyone a disservice.
There’s tremendous opportunity to unlock value during early project stages, but to realize the rewards, a platform must be in place where contributors from all backgrounds can convene. Think about collaborators on high-complexity projects. Can they thrive if they limit their collaboration to in-person meetings or if their requirements are maintained in documents that lack version control? What if their written communications get buried deeply in email threads?
Presence Levels for Team Members
Preventing negative outcomes — “bad” outputs and/or frustrating interactions — starts with having a platform for synchronous and asynchronous collaboration on base requirements. Software engineers, product owners, business analysts, designers, SMEs, end users, and project sponsors must all have a presence on the platform. In this case, presence can manifest in several forms that fall along a spectrum of involvement.
- High Presence
Teams or individuals who are responsible for structuring content on the platform make up the smallest group, occupying the top of the pyramid. These select few work directly with project sponsors and business analysts to:
- Capture the overall software requirements.
- Ensure the platform is capable of measuring and facilitating progress towards these requirements.
- Define and follow standards for the presentation of content by contributors.
In the case of a team I previously worked with, the Product Owner was responsible for creating a Roadmap that broke the project into Phases, and each Phase aligned with different subject areas. This Roadmap was maintained directly on the collaboration platform. The PO also maintained the list of features required for each Phase. I collaborated with the Business Analyst Leads to design a database structure for their Requirements. Each Requirement was the basis of their agile team’s user stories.
- Medium Presence
Contributors responsible for adding actual business requirements to the platform make up the larger middle group of the pyramid. While not directly responsible for the Product Roadmap or structure of the Requirements database, these contributors add the vast majority of content to the platform. Their other job responsibilities should involve liaising with SMEs, end users, and their peers to distill complex needs for the product, then elegantly write the necessary requirements documents and design their corresponding visual mockups.
- Low Presence
Passive actors who consume the platform's content and provide feedback are the bulk of the team. This group should be as large as can be effectively managed and be made up of all remaining stakeholders, right down to end-users themselves.
Selecting a Collaboration Platform
For many custom software projects, the requirements are complex and can make finding a good platform challenging. The more information surrounding a requirement that can be neatly communicated, the better. Teams are often accustomed to using a set of tools they've had for years, and involving a third-party consultant can be helpful to independently evaluate the efficacy of the existing tools and processes.
Traditional DevOps tools usually have some collaboration features, but they are not always the best collaboration platforms. The focus of these tools is involvement in a . While knowledge management & requirements tracking are present in many of these tools, they seem to be implemented as an afterthought.
Visual-focused tools like Figma and Sketch are excellent mockup and prototyping tools. They can facilitate conversations among technical and non-technical audiences using relatable visual content. The downside to these tools is that they lack the ability to neatly link to written requirements, so it remains essential to find the missing piece in this platform puzzle.
In my experience, Figma + Notion has been an indispensable platform pairing. Notion lives at the epicenter, providing robust capabilities to present written requirements alongside visual mockups and asynchronous communication threads. It is an easy tool to adopt and train, and it scales efficiently to handle projects with thousands of requirements.
Without the proper tools, teams will likely overspend time and resources while suffering losses from miscommunication needlessly. While it requires some knowledge and initial investment to adopt and implement these platforms, the payoffs are inarguably there.
The Bottom Line for UX Teams
Leaders of software projects, big and small, who recognize and support their UX teams unlock incredible value for their organizations. By gathering diverse experts, providing a common-ground platform to collaborate on, and making the best decisions before a single line of code is written, they score upfront wins and suffer the fewest losses down the road.
Rework, especially when it involves expensive resources like software developers, can be mitigated early by producing optimal designs. Furthermore, the patterns and processes that evolve around these collaborative platforms can provide ongoing wins and result in sweet, sweet user experiences.
How does your team collaborate? How would things look if it all went smoother? Let's review together and see what we can improve.
| 9 Minute Read
5 Minute Read
| 7 Minute Read