Execute for Every Screen
23
1 Executing for Every Screen Embracing everyone’s limits to expose you project’s strengths @shoobe01 #d2wc
-
Upload
steven-hoober -
Category
Technology
-
view
1.842 -
download
1
description
There are several ways that current development processes can miserably fail users and the business when trying to launch your project on multiple platforms. Massive changes, blame, or simply not understanding your missed opportunities, are the usual results. The answer is not any of these, and certainly not to try to impose a new process. Instead, encompass all the existing processes to create a new philosophy of implementation. Avoid pitfalls and gaps, and play to the strengths of your team to operationalize a functional design and development processes. Steven will talk about methods he's devised and used with business, analysts, and developers that make everyone happy and help assure projects actually launch. Presented at D2WC in Kansas City on 17 March 2012
Transcript of Execute for Every Screen
1
Executing for Every Screen
Embracing everyone’s limits to expose you project’s strengths
@shoobe01 #d2wc
2
UX thinks:
Principle of Most Time: The most
elegant and simple solution to any design
problem will be the one that requires the most developer effort.
Developers think:
Every product we build is a product we build for ourselves to solve our own
problems…making decisions based on
real opinions trumps making decisions
based on imaginary opinions.
333
No more hand waves
4
Shared principles
• Modular• Iterative • Incremental• Patterns and best practices
5
Modular
Re-usable components make work quicker and more efficient, more repeatable, easier to understand for regular teams and easier to improve or fix.
Implementation:
Good programming principles (whichever you embrace) encourage re-use, consistent naming and resource allocation, and using the simplest solution.
User Experience:
We don’t draw every page and state independently, but consider the design holistically, and draw many items to be used across the product.
6
Iterative
Whether week two or release two, work is never thrown away, but improved on and expanded to become better and more capable.
Implementation:
Start simple, learn as you go from both solutions and needs of the customer/client, and build improvements on what you build before.
User Experience:
Review designs internally, with user research and by analytics when launched. Identify, learn and improve, on small and large timescales.
7
Incremental
Resources – both people and time – are limited. Deliberately break up work in an ordered manner for management, and coordination.
Implementation:
Assigning developers one task helps focus, and allows the team and management to track progress, and further split (or combine) work as needed.
User Experience:
Conceive holistically, but design in easy-to-manage chunks. Split the work to who can best perform the work, and deliver in pieces if needed for speed.
8
Patterns & Best Practices
All of our work builds on history, knowledge and evidence.
But watch out for best vs. common practices.
Implementation:
Apply existing knowledge and re-use known good solutions, but , extend and combine to meet the system needs and project goals.
User Experience:
Speeds work and constrains the problem space with libraries, patterns and stencils. Analyzes or researches to find the best solution.
99
Coordinate to collaborate
10
Planning for multiple platforms
11
There’s no time• There’s plenty of time• Scale the engagement• It pays off in the end
12
Design for every screen
• Gather information
• Design for users, tasks, and goals
• Make n assumptions about single technologies, interfaces or platforms
• Create a blueprint of the whole service… then branch out
• Design to target (end goal) experiences
1313
Constraints
1414
Development scales well
15
But the core team…
15
1616
But the holistic team…
17
Blueprint
17
18
Branch design to each platform
18
19
Serial
20
Parallel
21
Staggered
2222
Operationalize your process
