Or: The Role of a UX designer with tech chops.
Introduction: The Art of Design Thinking
Would you like to uplevel your product or service design to a point where your product is truly ready for international markets? UX Design Thinking helps you make your users happy without wasting developer time on approaches that leaves your end users wanting.
Every application begins as an idea, a concept waiting to be shaped into something real. But between the vision and the product lies the often-overlooked craft of requirement engineering. Here, user needs are translated into actionable specifications, where vague goals become clear, testable requirements, and where design meets technical feasibility.
The gift of requirements engineering lies in defining and refining the vision, ensuring that every stakeholder (management, users, designers, developers) has a shared understanding of what we’re building. I thrive in the space where user experience, technical architecture, and business requirements converge.
Let me illustrate this using a recent example: designing a comment system for a dynamic application.
This preliminary design document is to illustrate the kind of design thinking I might engage in to produce a preliminary design. It may seem from this document that design work is a single-shot event, whereas in reality it is anything but. Collaboration happens at all stages and verifying hypotheses with users is crucial. See more: the why and the how of usability testing.
Understanding the Problem
In this project, the goal was deceptively simple: create a comment system where users could attach their thoughts to specific paragraphs in an article. At first glance, this sounds straightforward—just slap some IDs on paragraphs and tie comments to those IDs.
But when we look at the actual interaction, we come across a variety of questions that need to be solved before the UX works for the user.
In this article, we will focus on only one: Content is fluid. Articles change, paragraphs are rewritten, and IDs break. How do we ensure comments remain relevant as the content evolves?
Requirement Engineering in Action
Here’s where my role as a User Experience Design Engineer comes to life. Some questions that needed to be asked are as follows. Note that no user research has yet been done so these are hypotheticals, but at this point that’s ok.
What are user needs with regards to comments?
Users expect comments to stay relevant, even if paragraphs change. They might also want to see the history of changes and discussions tied to specific sections.
What are the constraints?
The system must handle changing content gracefully without overwhelming the server or slowing down the frontend.
What are the edge cases?
What happens if a paragraph is heavily rewritten or removed? How do we ensure no comments are lost?
These and other questions led to a detailed specification that accounted for user experience and technical feasibility.
User needs
User Story: A Clear View of Context
Meet Alex.
Alex is reviewing an article titled “The Evolution of Language”. While reading a paragraph about how language adapts to technology, Alex clicks the comment icon to leave feedback.
The Commenting Experience
The system allows users to comment on individual paragraphs of a text to allow fine grained discussion.
- When a paragraph has no comment, a speech bubble is shown on mouse hover or on tap on mobile, next to the paragraph on the right.
- When there are comments to a paragraph, a speech bubble and comment counts are permanently shown next to that paragraph.
When Alex clicks the speech bubble or the comment count to open the comment box, it doesn’t bombard them with a wall of edits and feedback. Instead, it provides a clean timeline with just the essentials:
- Abbreviated current paragraph text at the top.
- Comments
- At points of the timeline where when the actual text paragraph text was changed, showing a note that change was made, timestamped, but without showing the full details of the edits.
- A click-to-expand option for each change, using say, the <details> element, to view exactly what was modified, including the exact differences between versions of the paragraph, with additions and deletions highlighted.
Why This Works
This design achieves the perfect balance between simplicity and transparency:
Minimal Cognitive Load: Users like Alex aren’t overwhelmed with every change and detail. Instead, they see a clean history with timestamps, keeping the interface lightweight.
Transparency on Demand: Unlike social media discussion, in an academic discussion the details may actually matter and it is important that they are accessible on demand. Using the <details> element, users can choose to explore changes when they need more context.
Chronological Clarity: By interweaving comments and paragraph changes chronologically, the system shows the full story of how the paragraph and discussion have evolved over time.
(Preferred) Real-Time Feedback: Comments are updated dynamically without requiring a page reload. (This may be a challenge, depending on technological choices.)
This commenting system shows that thoughtful design isn’t about overwhelming users with data but about presenting just enough to make them feel informed and confident. By letting users control how much detail they see, we respect their time and focus while still providing the transparency they need.
For Alex, and others like them, this approach ensures every comment they make is grounded in clear, accessible context. Feedback becomes not just a task but a meaningful and enjoyable part of collaboration.
Technical Specification
Database Structure
We designed two tables:
- comments: Stores comments tied to a normalized version of the paragraph text.
- paragraph_links: Maps the current version of a paragraph to its original version for retrieving historical context.
Precomputed Links
A backend process calculates links between the current and original versions of paragraphs, ensuring efficient retrieval without repeated fuzzy matching.
Technical avenue of exploration: Fuzzy matching of changing content
Tracking paragraphs in a commenting system can be a daunting task, particularly when content is frequently edited or updated.
To address this, techniques like fuzzy matching and Levenshtein could be used. These methods provide a balance between flexibility and resilience but come with their own set of challenges.
The alternative is to track document editing on the front end, each interaction with the paragraphs and try to keep up with which comment belongs to which paragraph by making the comments a part of the same data structure. This requires a rich text editing front end. If the content management system is based on static files and/or markdown editing, for instance, this may not be feasible.
Fuzzy matching and Levenshtein distance both excel in ensuring that comments remain attached to the right sections, even after minor edits. Whether it’s a typo correction or a slight rephrasing, these methods can adapt, ensuring that the integrity of the discussion is maintained. This resilience makes them a robust choice for dynamic content environments.
Another significant advantage is the flexibility they offer. Unlike static identifiers, these methods analyze text dynamically, making them invaluable for platforms where content is frequently rearranged or adjusted. This adaptability ensures that comments are less likely to become orphaned, providing users with a seamless experience.
However, these techniques are not without their drawbacks. One of the most prominent challenges is computational cost. Calculating similarity scores across large documents can be resource-intensive, especially when there are numerous paragraphs to process. This can impact the performance of the system if not managed properly.
Additionally, significant edits to paragraphs can introduce ambiguity. If a paragraph is heavily rewritten, the system may struggle to identify the correct match, potentially leading to incorrect associations or multiple matches. This can erode the reliability of the system, particularly in complex documents.
Finally, implementing and tuning these algorithms requires a level of expertise that can add to development time. Balancing accuracy and computational efficiency is a delicate task, one that demands careful planning and testing to get right.
In conclusion, while fuzzy matching and Levenshtein distance provide a resilient and flexible foundation for paragraph tracking in a commenting system, their limitations should not be overlooked. Developers must weigh the trade-offs carefully to ensure that their system is both robust and user-friendly. By striking this balance, they can create a commenting experience that stands the test of time, even in the face of evolving content.
Frontend Rendering
The frontend receives:
- The original paragraph text.
- A list of changes
- All associated comments with timestamps.
When designing a user experience, one of the biggest challenges is presenting enough information to give confidence without overwhelming the user. In a commenting system, showing paragraph history and changes is essential for maintaining context. But if every edit and comment is displayed all at once, the interface can feel cluttered and intimidating.
Instead, what if we gave users just enough information upfront—like a timeline of changes—and allowed them to explore further when needed? Using a collapsible <details> element, we can offer the best of both worlds: simplicity by default and transparency on demand.
Dynamic Updates
The frontend dynamically updates comments in real time as users interact with the system.
Collaborating with Developers
Here’s where the magic of collaboration happens. I don’t implement every line of code—but I do design and discuss every detail of the system with the developers who do. Together, we:
1. Refine the specification
Developers challenge the technical feasibility of certain ideas, and we iterate until the design balances ambition and practicality.
2. Address edge cases
We brainstorm scenarios, like how to handle a paragraph that’s deleted entirely or a heavily rewritten one that no longer resembles the original.
3. Ensure the user experience shines
Developers might suggest simplifications. I advocate for the user’s needs, ensuring that features like change history and real-time feedback aren’t sacrificed.
Where I Shine
This example highlights the part of the process where I excel. I get energized by:
- Designing the database schema and defining how data flows through the system. See more about Conceptual Modeling
- Collaborating with developers to discuss fuzzy matching algorithms or normalization techniques.
- Advocating for the user, ensuring the experience remains seamless and intuitive.
- Diving into the nitty-gritty details—whether it’s how timestamps are displayed or how paragraph changes are rendered in the UI.
My key strengths and what I’d rather delegate to others
Coding every detail or debugging edge cases is not my ideal role and can be draining for me.
But sitting with a developer to map out the logic? That lights me up. As I still understand the technical level quite deeply, I can act as a bridge builder between user needs and implementation. Together, we turn abstract ideas into a concrete plan that developers can confidently implement.
My gift lies in being the connector—the one who ensures that the user’s needs, technical constraints, and business goals align seamlessly, and turns them into reality in terms of wireframe designs or detailed visuals. As I have been a developer and intimately understand the point of view of software development, negotiations about tradeoffs can flow effortlessly. There’s no need for an translator/intermediary between me and hacker types.
The Value of a UX Design Engineer
In many projects, there’s a gap between what users want and what developers build. Bridging that gap is where the UX Design Engineer becomes invaluable. My work ensures:
- Precision: Clear, actionable specifications prevent misunderstandings and rework.
- Collaboration: Developers have a trusted partner to discuss technical trade-offs and user impacts.
- Alignment: Stakeholders, users, designers, and developers are on the same page, reducing friction during implementation.
Final thoughts: My role in the Big Picture
Using this comment system as an example, I hope I’ve illustrated the value of requirement engineering done well. It’s about asking the right questions, diving into the details, and creating a roadmap that others can follow confidently.
To me, this is the most exciting part of building anything: not just seeing the idea come to life, but being the one who shapes the foundation it’s built on.