Deciding UX Design Deliverables to use
June 7, 2015 12:18 PM Subscribe
UX Designers - How do you decide the types of deliverables that are necessary on the projects you work on?
In preparing for UX interviews and subsequent readiness research, I find that the process that Ux'ers use is slightly different across the board. It seems that some get user requirements, then define business needs, then draft deliverables.
I can't determine how to decide on what type of deliverables are needed. Is this something that is subjective or do you have a hard and fast rule to always set up personas, then user flow etc.? Can you detail your process for me? (it will also help me for my interviews to have this answered).
In preparing for UX interviews and subsequent readiness research, I find that the process that Ux'ers use is slightly different across the board. It seems that some get user requirements, then define business needs, then draft deliverables.
I can't determine how to decide on what type of deliverables are needed. Is this something that is subjective or do you have a hard and fast rule to always set up personas, then user flow etc.? Can you detail your process for me? (it will also help me for my interviews to have this answered).
Best answer: feckless above has pretty much covered everything that I was going to say, in that you need to think about the context for each deliverable, and choose the appropriate deliverable with the correct level of presentation finesse and technical detail for that audience, type of project, and project milestone.
In general, it makes sense to work from big picture strategic goals down to technical details over several rounds of deliverables, dependent on what needs to be tested, validated, and signed off at each stage. Yes, wireframes are increasingly depreciated these days, but I do think they offer a good deliverable choice for moving between these stages as you can start with something sketchy and add details through the process to ideally end up with with a document that stakeholders, designers, and developers can all use effectively. Personally I tend to just create one blended document based around wireframes with additional sitemaps, storyboards, user flows, written logic, and whatever else is needed to communicate the functionality of the system, and maintain that over the course of the project. This will also depend on the type of project that is being run - e.g. is it a big content site with a large scoping phase? If so, it makes sense to create personas and strategy documents to aid scoping. Is it a small mobile app being built in an agile project? If so, chunk the work into user stories and wireframe accordingly to be dropping into the sprint cycle.
One thing I would say is that I think a lot of user experience design can be quite deliverable focused these days, at worst lapsing into jargon (and I include the term "UX" in that) and fetishising document production over the actual process of collaborating with the larger team and stakeholders. Ultimately the user experience architect is always just a mediator between different parties - users, businesses, designers, developers, project managers, etc. and the best approach is to be pragmatic about what it takes to move the process on at any given point. As feckless mentions, a workshop session or even just an informal conversation may be all you need to keep the project going - just you make sure you capture something of those details later in case you need to double check what was agreed.
posted by iivix at 2:22 AM on June 8, 2015 [2 favorites]
In general, it makes sense to work from big picture strategic goals down to technical details over several rounds of deliverables, dependent on what needs to be tested, validated, and signed off at each stage. Yes, wireframes are increasingly depreciated these days, but I do think they offer a good deliverable choice for moving between these stages as you can start with something sketchy and add details through the process to ideally end up with with a document that stakeholders, designers, and developers can all use effectively. Personally I tend to just create one blended document based around wireframes with additional sitemaps, storyboards, user flows, written logic, and whatever else is needed to communicate the functionality of the system, and maintain that over the course of the project. This will also depend on the type of project that is being run - e.g. is it a big content site with a large scoping phase? If so, it makes sense to create personas and strategy documents to aid scoping. Is it a small mobile app being built in an agile project? If so, chunk the work into user stories and wireframe accordingly to be dropping into the sprint cycle.
One thing I would say is that I think a lot of user experience design can be quite deliverable focused these days, at worst lapsing into jargon (and I include the term "UX" in that) and fetishising document production over the actual process of collaborating with the larger team and stakeholders. Ultimately the user experience architect is always just a mediator between different parties - users, businesses, designers, developers, project managers, etc. and the best approach is to be pragmatic about what it takes to move the process on at any given point. As feckless mentions, a workshop session or even just an informal conversation may be all you need to keep the project going - just you make sure you capture something of those details later in case you need to double check what was agreed.
posted by iivix at 2:22 AM on June 8, 2015 [2 favorites]
> It seems that some get user requirements, then define business needs, then draft deliverables.
Well, this will depend on what type of project it is. Some projects arrive on my desk with very prescriptive requirements already determined by the client. Some are more open ended and exploratory. Again, you've just got to be pragmatic about how much you can and should input into scoping and strategy work.
posted by iivix at 2:28 AM on June 8, 2015
Well, this will depend on what type of project it is. Some projects arrive on my desk with very prescriptive requirements already determined by the client. Some are more open ended and exploratory. Again, you've just got to be pragmatic about how much you can and should input into scoping and strategy work.
posted by iivix at 2:28 AM on June 8, 2015
This thread is closed to new comments.
Audiences might include:
- The designer (or other designers) -- to use as part of the design process, or to record design decisions for later projects.
- Developers -- to act on the deliverable
- Stakeholders (to get buy-in for a project)
In practice things like wireframes are more useful to folks who are part of or are familiar with the design process and less useful to external stakeholders. OTOH, high fidelity mockups shown too early can lead to weird discussions about details when you're still nailing the fundamentals down.
Also think through stages of a design process, and the length. A long,complex and multi-phased project with a giant team might need multiple deliverables for multiple audiences at different stages. OTOH a quick feature with a small team and you might be able to get the design exploration, buy-in, and specification into one 1/2 hour whiteboard sketch session.
Don't be afraid to get creative. As nice as it is to have a canned process with set stages (and it can be reassuring to other folks) it isn't always necessary and every project is different.
FWIW, the biggest change I've seen over the last decade is the diminishing use of wireframes (at this point I think they're only really useful to the designer) and the increasing need for prototypes of varying levels of fidelity. I used to think of prototypes as mostly for user testing, but I now use them for user testing, design exploration (especially around responsive design), and stakeholder buy-in. Downside is the burden of building them, but some of the prototyping tools help here.
posted by feckless at 1:09 PM on June 7, 2015 [4 favorites]