Tag Info

Hot answers tagged

26

I have come across this exact problem on a project. Everybody on the team is already stretched to the limit to get a product shipped - and it's important to get it out before a particular international event (for example). So a UX review which happens too late in the development life cycle throws up some serious issues which no-one had foreseen. What to do - ...


15

+1 on "UX starting at day 0". [Minor caveat that I'm a dev and not a UX person so I might have a bit of a naive understanding of what is done/needs to be done from a UX perspective]. I have worked on Agile teams where UX folks were an integral part of the team and a few things that seemed to work well: Early UX involvement Often our interaction ...


15

On Agile From the various Agile-related concepts, I'd like to highlight two: It meant to combat requirements volatility (frequently evolving or changing requirements or their priority). It increases time to market. Agile, when used in the right context (and followed by the word), is nothing short of magic. The cost of changes within a properly managed ...


12

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


11

My response may be biased because I run a pure UX research, strategy and design firm, but as UX practitioners, we're involved in agile projects at the very beginning. As zsiberian stated, getting ahead of development by 1-2 sprints is the only way to keep the process agile. UX involvement in the iteration planning session allows the user story definition ...


11

I would strongly recommend reading this excellent article on smashing magazine on Lean UX,to paraphrase the article: Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed. Traditional documents are discarded or, at the very least, ...


11

UX, along with all of the other disciplines involved in your project, should be involved from day one. The team should strive to work in parallel with each other as much as possible. To achieve this, it is imperative that the UX resource(s) participate in all daily Agile rituals and meetings. This is especially true for backlog grooming and prioritization. ...


8

I hate to stereotype, but, well, it's somewhat valid in this case: JSF developers don't understand the presentation layer code nor user experience. I think it has to do with the evolution of JSF as a web development tool...most all of the front-end code is out of the hands of the developers. It's all generated automatically (and poorly) via the server side ...


8

Agile seems to come in a variety of flavors, but the theory is all the same, and based on that theory, UX is part of the mix from day 1...as is business line owners, customers, IT, marketing, etc. I usually find the problem is when UX is still doing waterfall but dev is trying to go AGILE. Lots of UX teams still want to pump out piles of wireframes, which ...


7

First, you are not causing any problems, you're doing the best you can with what you have and asking for help shows you have a good head on your shoulders. So I won't sugar coat any of my answers otherwise I don't believe I'd be doing you any justice. First, throw out the term agile. I've been in the environment you are in and they call it agile because ...


6

Mike Cohn provides a great template for user stories which is used throughout the industry. As a type of user, I want some goal so that some reason. As a customer, I want to pay my bill online so that I do not have to mail it in. As a developer, I want unit tests in place so that I can verify my code is functional. As an enterprise card holder, I want ...


5

From my own experience I would say you work in a parallel stream ahead and after Development and if you take it literally not in Agile Development at all. Why? Because in my understanding Scrum, which we do at my company, is about production and development in iterations. But tasks itself not. You take a single task and work on it until its finished. Then ...


5

At the company where I work, the UX team is responsible for creating the PRDs, which is the detailed plan of requirements to the engineering team. This helps us avoid the problem by making sure the UX team had a chance (in the beginning) to get things designed well. Once an issue is found, I have found it very difficult to get it on the roadmap (as you ...


5

Actually it sounds like the UX team wasn't made part of the development team from "day 0" as Roger states. You should be one team and create functionality together (all required disciplines). This would reduce but probably not eliminate the usability problems encountered during testing. UX should also have been brought into strategic design. If it were ...


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


4

It sounds like your "down the road" wireframes are a bit too far along on the fidelity spectrum. In other words, they're too detailed if you feel much "pain" when the ground changes under your feed (which it often does, in your case as well as mine). Have you tried just using pen/marker/paper (lo-fi) for your longer term wireframes and saving Visio ...


4

I too don't understand why adding to the backlog the issues that came up should delay the delivery. There's certainly nothing that says that absolutely everything in the backlog needs to be added to some release. I would, however, take an honest assessment of the user value that would be added by addressing the discovered issues. Spending more time on a ...


4

An approach which I find very fitting on where the UX role should intervene in Agile (Scrum in this case) development is: In the product backlog, translating end-user feedback into specifications. In the sprint planning meeting, providing mockups so both the Team and Product Owner have a better idea of what will be built and how. At the end of each ...


4

Depends. I'll show you two extremeties, a bit exaggerated, but I'll hope you'll find some useful advices. Stereotype 1: If they're agile-maniac geeks, also in love with the latest fad (spring, scala, whatever), but no understanding of ordinary humans, it's likely that they won't do program design. In this case, usually UX does program design, so a full ...


3

Summary: Scenarios provide context to user stories. Therefore it is never too late. You may discover new stories or realise existing ones are not needed. To explain my answer I'll start with definitions for context. User stories are discreet, structured information that describes a deliverable and testable piece of functionality for a user. (i.e. The cards ...


3

I think that's a pretty standard way to do it, but don't serve the process if the process gets in the way of progress. I will never commit to a final deliverable (e.g., site map) before everything is done; IMHO, efficient UX work is never as neat as a waterfall-type project plan would indicate. My own process is more like the curly line on a Hostess Cupcake ...


3

At my previous company (which liked to consider itself an Agile development company) we used user stories to moderate success. I think calling then suggestions would be a great idea if what you're looking for is simply ideas. The problem we had was that we told everyone the proper form for A User Story and they then resisted the idea of entering anything ...


3

Jared also asked this on the agile-usability mailing list and people may find the replies there of interest. Austin especially included some very nice tips. My reply to Jared there included below for those who might be interested: Not a problem unique to agile. I'm amazed at the number of folk who budget in time for usability testing, but expect the ...


3

One of the main purposes of using agile methods is to make a situation like this a non-issue – anything that doesn't make the first release can be added to the backlog, to be (possibly) developed and pushed during a later release. As Ben Rice also noted, adding to the backlog should not jeopardize a release date. As Roger Attrill and others also noted, UX ...


2

I use BasecampHQ for this sort of situation: create overall projects and projects for each sprint follow message threads within a project and attach documents to messages messages are usually copied to email - and can be replied from email get a collective view of all the files attached to that project collaboratively edit documentation via the writeboards ...


2

To my mind, this isn't an issue specific to Agile development processes; this question gets at the issue of ensuring that UX is part of the development process, period. In one of the first comments on the question "At what point in the development process should UX come into play in an Agile work environment?", user Aaron McIver (rightly) says that "Agile ...


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


2

In my experience agile development can be antagonistic towards UX, especially if UX is attempted to be made to fit within an agile development frame work. The issues with agile don't relate to how successful then can be for development teams but when either UX concepting is attempted within sprints or if key design is done on the fly with the development ...


2

One of the biggest problem with putting an argument or proposal about UX to management is the lack of an objective baseline or benchmark. For example, people like to compare between similar software products, but don't take into account of the fact that they may be designed for different types of users operating in different environment under different ...


2

You first have to prove that there are UX issues with their existing products, and get the time and resources to fix those, before you can justify the extra efforts to get it first-time-right on new projects. Imagine that you can present a usability test report, that proves that x% of the users are confused over a certain highly valued feature, or they ...



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