Tag Info

Hot answers tagged

13

Resolve the behavioral stumbling block You make a key observation that it's hard to get users to backtrack from a specific suggestion ("I want this button!") that they are psychologically anchored on. I agree. You can use reason and charm to get a user off a fixation on a specific UX suggestion, but the effort involved in doing that can result in ...


9

I've tried to solve this same question in the past. Here's my solution. Keep it short. Direct them to activities. Focus the issue with a choice: "I'm trying to do something that's not currently possible" OR "I'm doing something and the app isn't doing what I expected" Ask about activities: "What were you trying to do when things went wrong?" This changes ...


9

This won't fully answer your question since you already included part of the answer in your question :) For the part where the user (or the client in some cases) insists on "But I WANT a BUTTON", I have some useful techniques: I re-confirm the user/client problem. I shift him/her from proposing solution to identifying the problem. This may require a lot ...


9

First things first I don't think UX can succeed in this scenario. A sprint is too short to do both the design and execution of the same feature. You should be out in front of things with the Product Manager defining the work before it ever becomes an engineering request. If you take that approach seriously (which I've never been able to realize 100%), you ...


6

Great question. I'll try and break it down into a couple of components of how to provide the holistic view and task management (and reference Jira documentation when I can). From what you have described, a user story to handle the 'bigger picture' thinking is called an Epic. An epic is essentially a large user story that can be broken down into a number of ...


6

I've seen a lot of different exceptions made like this in agile - called spikes, buckets, non-stories, etc. This is doable - basically it's just an allotment of time. The only place I've seen it get ugly is when you assign an huge number of story points to it to account for the time you're taking to do many tasks, then you have a substantial portion of the ...


6

I have done this several times and am currently in the process of doing this for several related enterprise products. We are going about it in phases. For large projects, you don't really want to scrap what exists and build fresh. There have been studies about how frequently those fail. If this is for a small scale project, then the answer would be ...


5

I don't think there's a set answer as to how much detail is necessary within a persona. The development teams and Business Analysts I'm used to working with deals with persona as the basis of the overarching "saga" levels that directly influences epic level work. Because once you go down into individual stories, it's been boiled down to simple one-liner ...


5

I had very similar experiences to yours (and also been using JIRA for quite some time now). It goes: User stories are extremely limited It seems that every Agile team fails to understand or work with user stories. But for a good reason - a user story capture only a tiny fraction of the problem domain, here's just a couple of things user stories don't ...


3

Focus first on the user story. As it stands there is no user value inherent in the first story as it is written. Try rewriting it from the User's perspective (and consider that User's don't want to fill out forms but form fills are necessary in order to get something that they want). Attach a simple ux workflow created by ux in collab with dev. The other 2 ...


3

Disclaimer: I'm biased, having worked as a dedicated UI text editor and writer on UX teams for 15 years (on top of several years of documentation experience). That said: ideally, there are trained content providers that work with PM, dev, design, and user experience teams to ensure that the UI text (control labels, messages, tooltips, instructional text ...


3

The person who owns the body copy is the person who is best-suited to own the body copy. The specific deliverable where the UI text should live is the deliverable where everyone knows where it is, knows who owns it, and is able to easily access it when they need it. As such, the answers to these questions depends on your project and on the team. On some ...


2

1 Good question. I say this because copy is often a hot potato in the product process. Some of the issues: Copy by committee is highly unpleasant and gobbles everyone's time Designers have unusual minds, so their copy choices are often awkward CEOs tend to insist on words that strike the wrong tone – and it's hard to push back on them Many product teams ...


2

Short answer: You can not Lean without having a really integrated team. Lean UX origins comes from Lean Strategy. It is a bit strange that you already have a brand new UX team already integrated to your organization. Lean Strategy generally is favor of; Low inventory and personal cost High communication with customer Really short cycles and more on ...


2

I think that there is some confusion about Scrum roles and responsibilities. In Scrum you have just 3 roles: Product Owner - holds the vision for the product. Scrum Master - helps the team best use Scrum to build the product. Team - builds the product. Please note that the Scrum Master is not a "Team Leader" or a "Project Manager": he's a coach and a ...


2

There's two issues here to address: getting a proper understanding of what the suggested change is supposed to accomplish, and avoiding resistance or frustration from the customer because "why are you asking me about the problem, when I've already told you what you need to do to fix it?". In my experience it is extremely difficult to resolve this well ...


2

I'm sure this is going to upset several people but here it goes. I personally believe that this is not a user issue. A user is not going to have insightful UX requirements and this is the reason that there is a need for your expertise. Even the most educated people, which have used computers for 20+ years, struggle with computers and the internet as a ...


2

For your MVP (min viable product), UX has to be done first. Once your MVP is ready then you can do your both UX and Dev agile. Otherwise, it will be a waste of time for your Dev team to code and re-code based on the UX changes.. Sorry I don't have a documented white paper on this, but have plenty of personal experience.


2

The answer is a spike story I heard people say there is no room for UX Design in Agile. But there is if you make the most out of it. You can do a spike story before pulling up the actual userstories from the backlog. A spike is a story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a ...


1

Based on your comments, I think I understand what you are envisioning. This comment helped: The developers can 'design' a system that caters for changes to the interface and its interactions, and the designers can 'design' an interface that caters for changes to the underlying implementation platform/framework. I think that's a great idea. However, I ...


1

I completely agree with tohster on this issue. What a great response. I'd post this as a comment, but I don't have enough reputation yet. I've used the "S-T-P" approach, which I see as the core of tohster's solution. That is, Situation Target Proposal Situation Start with the current situation. What are you doing today? How are you doing it? What ...


1

Adding to the already good answer from Eleonora Zucconi: I noticed that you said that each UX designer is in a different scrum team. To me that means that as far as the project being concerned they are members of that team, period. Now there might be structures within the company that aren't a part of the project, like a UX group in the organization, UX ...


1

User stories are usually small, used as a definition of a requirement. Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories. I would recommend to create an epic containing multiple user stories. Each user story should be an end to end "piece" ...


1

I am a UX designer on an agile project that manages a suite of applications for higher education institutions. We are composed of 5 delivery teams and a handful of core teams that support their work (analysis, UX, services). Each of the 5 teams has a dedicated UX designer who who, within the sprint structure, implements the design standards set within the ...


1

I think ideally, writers should write these messages, but I've hardly ever worked with a writer. It's been my experience that whoever gets to a point where the message is needed ends up writing them. I think after a site or app is "done", it is a good time for designers and writers to go through and give suggestions before the project is truly done. If ...


1

A root idea of Agile is to only do things that add user value. So pretty much all activities should be attached to a User Story. There can be exceptions but try hard real hard not to use them. As an example even internal performance improvements are relevant to a story: Add acceptance criteria with response times on relevant user stories and mark as ...



Only top voted, non community-wiki answers of a minimum length are eligible