Hot answers tagged

23

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


20

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


19

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


14

Although I am a staunch supporter of agile and lean methodologies in UX, it's important to remember that they are just methodologies. UX is not about how you create a great user experience, rather it is about what the user experience is. So there are many different UX methodologies that can achieve good results. Often one methodology is more suited to a ...


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

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


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


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


6

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


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

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

You don't have to build the whole UI to test some features like navigation. Early in the design process, you can test information architecture with a tool like tree testing or card sorting. These are good ways to test copy and wording too. Further along, you can test user flow with an interactive prototype built with wireframes. Usability testing at the ...


5

This all depends on what your definition of UX is... which has been a changing beast over the years - from what the experiences is through to a job description for certain kinds of role. I would personally say that you do need the qualifiers - since you can apply UX practices in many different contexts. For example: A dedicated UX agency brought in to do a ...


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.


5

Well there is the Lean UX Manifesto from Anthony Viviano, Ajay Revels and Ha Phan: Early customer validation over releasing products with unknown end-user value Collaborative design over designing on an island Solving user problems over designing the next “cool” feature Measuring KPIs over undefined success metrics Applying appropriate tools ...


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


4

I don't think there is a workflow that is guaranteed to work, because it will depend on the product, people and process (and to an extent the tools) used as to what would be the optimal workflow when it comes to efficiency. So I would suggest you try to weigh up the product (i.e. what is being delivered), people (what are they comfortable with in terms of ...


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


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

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


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


3

Anecdotally, as a developer, it is more of a difference with knowledge in a Framework, rather than a specific language that affects speed. In your Objective-C/Swift example, your developer is going to be using the Cocoa or Cocoa Touch framework, regardless of language. If she knows exactly what views and controls AppKit/UIKit offers, their APIs, how to ...


3

I think it's partially inherent to working 'lean'. You design the product flow tension-based & when you catch these missed flows, you fix it ad hoc / improve it. I think, over time, your accumulated experience will guide you towards a more complete handoff, with all flows, error states, etc. included. Maybe a solution would be to start working on a ...


3

Exactly how much you do when probably depends on the circumstances, but I can't think of any case where the wireframe should omit something because it will be done later - that puts way too much permanence on your wireframe. Generally speaking, wireframes aren't a blueprint, they're a sketch, so they are meant to quickly capture what you're thinking in a ...


2

Check out Hugh Beyer's 'User Centred Agile Methods' http://books.google.com.au/books/about/User_Centered_Agile_Methods.html?id=CoYxZ7mWapUC&redir_esc=y Even though it's a monograph it's extremely easy to read and explains the philosophy and methodology of Agile to a UX practitioner audience. UX Book Club Melbourne read it last year and it was very ...


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