Hot answers tagged

22

You've somewhat discovered the answer to your own question. The best time to include development in the design process depends on the development team you are working with. Your initial intuition is correct...get the developers in sooner than later. Ideally, they are a part of the design process from the beginning. They have insights and ideas that can ...


17

The Sharing Mockups stage is too late Assuming you want the developers fully engaged and understanding the reasoning behind the design and decisions made then you should have them in a UX Design Workshop - before mockups are done In my typical workshop I'd Explore related User Stories Itemise concepts user will be thinking about Do multiple UI ideas ...


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 ...


12

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 ...


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 ...


7

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 ...


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 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 ...


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 ...


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

straight away. For various reasons: they can give insight that you would never get from anyone else; can flag technical limitations very early; become emotionally attached to the project.


4

According to Bill Buxton "We are NOT all designers", although "we are all potential participants in the design process", but design is "a profession as reach as math or medicine" that cannot be performed without experience and knowledge. Although the designer must process and evaluate all possible contributions, the final design is the designer's role and ...


4

I am a developer with about the same design talent as the average rutabaga. I think you may be asking the wrong question - you should probably be asking "As a designer, how can I most quickly gain the trust of the developers on my team?" Most of the "designers" I have worked with were developers whose management told them they were now designers, and then ...


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

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 ...


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 ...


3

I am a developer, and the designers on my team work pretty closely with us. We set it up so we have the opportunity to raise questions and give input when the designers give us designs, but then when the decision is being finalized, the designers get to decide and we don't get a vote. Get input from people who care, but establish a clear boundary between ...


3

TLDR: We ask this question "What's the smallest increment of work that can be tested? We go and test that using the quickest solution that'll get us answers. Which means products like Axure and even Invision are often considered as too time consuming to use unless we're dealing with a heavy animation/interaction-based solution that is difficult to convey to ...


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

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

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

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

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 ...


2

Our current workflow is: ...heavily waterfall and dependent on heavy documentation. This rarely works. If ever. And especially hard to pull off when the UX folks have no technical knowledge. Instead, I'd suggest adopting a more agile process. This doesn't have to be a formal agile process, but rather, embrace the idea of having your UX folks be a ...


1

Sounds like your designers need to become more in tune with what's possible in the platform, or at least, what the developers are happy to take on. The trick, by the way, is to hire designers who aren't going to run into these issues in the first place. Sketch Early with a Developer As a solution, I'd change the first step in your workflow to be a ...


1

The specifics will vary greatly depending on the software and system that you use, but some best practices include: Keep the information in a central location accessible to the team(s) that will be using it. Everyone who needs to access the research should be able to access it. Often, each team/group keeps their research to themselves, thinking that it ...


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 ...



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