Evaluate and Measure Progress

by on August 27, 2013
in book, design

An Excerpt taken from, The Value of The Finite
‘An acre of performance is worth a whole world of promise.’ – William Dean Howells

Oh so let’s assume you have decided to take action, you have found a regular routine that works to maintain focus, you’ve successfully avoided disrupting your progress with new ideas by starting and managing a backlog, and you’ve made some progress towards your goals. Now it’s time to put in place a regular set of checkpoints or milestones to evaluate your plan, your progress, and your backlog, to ensure you’re heading in the right direction.

The benefit of evaluating your progress is threefold, it provides:

1. A regular cadence to acknowledge and celebrate your progress!
There’s an old saying that the only reason anyone ever finishes a marathon is because at mile 18, when things get really tough, you’ve already run 18 miles. Acknowledging your progress becomes the push you need to finish those final 8.2 miles. So your project effectively generates it’s own positive inertia, effectively pushing you further toward the finish line, simply by taking a minute to acknowledge how far you’ve progressed. It’s also an excellent excuse to throw a party – everyone loves a good party.

2. Focused opportunities to adjust your plan.
As you design and build a solution inevitably you will learn things about the customer, the market, your approach, the technology, your solution, all learnings that you didn’t have at the outset when you started. Each check-in is an opportunity to adjust your direction to ensure your project is viable without disrupting the focused execution. In this way you can work effectively (even at scale) to ensure your solution remains viable.

3. A measurable timeframe to evaluate your project velocity, by asking questions like:
▪ How far have you come?
▪ How far have you left to go?
▪ How long did it take you?

By actually measuring how long it took you to go from milestone 1 to milestone 2, you can much more accurately predict when you will hit milestone 3, and eventually cross this finish line. This data can significantly help you adjust for your end date, by managing the scope of your project if necessary, or how you are resourcing it.

Estimating Work and Communicating Costs

by on August 19, 2013
in book, design

An Excerpt taken from, The Value of The Finite
‘If you fail to plan, you are planning to fail!’ ― Benjamin Franklin

Estimating work and communicating the timing of deliverables is one of the most important and often overlooked skills any designer should take a hard look at developing. The art of velocity tracking ultimately determines your credibility as a designer. It’s really quite simple: If you are consistently late with deliverables, you are corroding trust with your clients, your team members, and your manager. You aren’t doing what you say you will. If you do this consistently just like the boy who cried wolf, people will stop listening to you. As a designer this can be disastrous. I can think of a number of clients that were lost simply because deliverables were late, and a conversely a number that were won-over with mediocre work, simply because it was delivered consistently on time.

Missing dates has other consequences later in projects. If you have corroded trust with team members you loose influence. Credibility as a designer is incredibly important. Because of the arbitrary and subjective nature of design, if people believe that you lack any integrity, they won’t accept influence from you. Simply handing off deliverables when you say you will, or slightly earlier, goes a long way in supporting your credibility further down the project path, and ensuring you are on equal footing with your project stakeholders.

Think about it this way; you’re the hiring client and you’ve worked with two designers in the past:
Designer A: Was mediocre in terms of talent, but reliably estimated their work, committed to a clear deadline of Tuesday the 19th, and delivered everything on Monday the 18th, according to spec with minimal revisions.


Designer B: Who didn’t provide a clear timeline regarding how the process would work, had to be managed to commit to a date a few weeks into the project, delivered amazingly stunning designs that only incorporated some requirements, that had to be sent back for multiple revisions, putting you past your deadline, over-budget.

Who do you hire back?

Ideally you are able to both estimate, communicate, commit and deliver stellar work, but the planning phase takes just as much effort, and energy as being an effective designer.

Fortunately the solution is simple. Pay attention to how long things actually take. Here is a good strawman format to follow for most design deliverables. There are a bunch of areas where time often gets invested that designers neglect to factor into their estimates. This outline is a tool to help you avoid this and get to actual estimates that are accurate.


UX Process Visualization


▪ Customer definition and analysis
▪ Gathering, identifying, reading, and synthesizing requirements
▪ Project, planning, and scheduling
▪ User research, personae development, user workflow definition, planning, and scheduling
▪ Competitive analysis
▪ Opportunity identification and design goals

There is so much work here that designers forget to incorporate into their timelines. The first job of a designer generally is to ‘discover’ or understand everything that they can about the customer, the project, and the needs of the client/business. To internalize and make sense out of all of this information takes some time. This time needs to be factored into schedules, to set expectations early as to when an actual model or interaction will be ready for review. The scope, complexity, current state/accuracy of documentation, and saturation of the market opportunity will help determine this initial discovery timeline.


▪ System workflows, site-maps, or information architectures
▪ Early concepts (on paper or a whiteboard)
▪ Initial wireframes and interaction design definition
▪ Review interaction concepts, iterate, and refine
▪ Conduct hallway usability

03 DETAILED DESIGN (Execution)

▪ Visual design language definition
▪ Apply design language to interactions
▪ Review visual comps with team and sign off
▪ Formal usability testing, recommendations, and iterations
▪ Handoff for implementation

Once the project has transcended discovery into the conceptual and detailed design phase, the most common mis in terms of estimating work, is the number of required reviews and iterations required to close on a final plan-of-record design. Often projects will suffer in this phase as well without a well documented design review process to appropriately take feedback, and formalize it into design execution and closure. Again most of this work has very little to do with actual hours behind a monitor designing, and more to do with the human, and relational aspects of, sitting down with stakeholders, going through everything, taking feedback, taking notes, incorporating feedback, and communicating status on the process.

All of this work in-between the actual design effort gets left out of schedules, and projects slip. Assume reviews will be tough, multiple iterations will be required, that you won’t get it right the first or second time, and then you will either hit your date (if you’re good) or deliver early (if you’re really good.)


This is also often significant time spent closing down on the projects. Writing documentation, getting assets / optimized and handed off, getting everything worked through to meet the appropriate final quality bar. Sometimes with larger complex systems, this includes incorporating customer feedback, and managing design changes into the schedule. Factor in your level of confidence into the estimated dates for your solution. Are you 40% confident or 80% confident. There’s a big different there and it will likely surface in terms of your ability to actually hit your dates further down the funnel.


Finally there are also other reasons why projects aren’t appropriately estimated and scheduled.

Obviously all of the above is quite a lot of detail to think about, review, estimate, and plan for. Sometimes there are technologies involved that are new to the team and this causes unforeseen complications. Often there are simply risks, or unknowns when planning is first started, and if this is the case, this should be called out in the original project plan estimate. Finally clients and/or project stakeholders are simply in a hurry and need an estimate fast. The best mitigation here is to get a ball park figure to the client or stakholder upfront, and communicate that a second in-depth evaluation will be required that may increase the initial estimate. This is fairly commonplace and helps to meet the clients immediate need, while setting expectations appropriately.

Time Boxing

by on August 19, 2013
in book, design

An Excerpt taken from, The Value of The Finite
‘If everything is important, nothing is’ ― Patrick Lencioni

Time boxing is simply the value of having:

1. A deadline
2. Clear priorities
3. Focus

Ironically we all do this in a numer of ways everyday without even realizing it. For example when you get ready for your workday you have a clear deadline, which is generally the time you need to be at work. From this constraint, you reverse engineer your morning, factoring in all of the things that have to be accomplished before you arrive at work. Let’s say you have to be at work by 9am. That is your deadline.

Then you figure out what you have to accomplish with your morning. The timing is determined by how long each item takes, and the order is determined by what’s most important, and common sense. For example it doesn’t make any sense to get dressed, brush your teeth, and then shower and eat breakfast. There is almost always a logical inherent order to work. Or if you know you have to be out of the house by 7am on Monday, Wednesday, and Friday, but on Tuesday and Thursday you don’t need to leave until 8am, then naturally those are the mornings to go to they gym. When you look at things in this way a clear order of priority emerges, and decision making, and execution becomes almost self-evident. Working on large projects isn’t far removed from this commonplace example, we just don’t always look at it this way.

You can look at your work day in the same way. What if you arrived at work everyday at 9am and left at 5pm. What if you made those two times immovable constraints. How would it change what is important about your day? Is getting your inbox to zero really what you need to accomplish? Time boxing is often about what you aren’t doing, rather than what you are doing. It’s about intentionally deciding what isn’t important, and simply not spending precious time and energy on the things that don’t matter.

For example by not checking mail, not socializing online during the day, or taking long coffee breaks with co-workers, not going to superfluous meetings, and not working late, you are able to effectively manage your day, and allocate time to focus on what really matters. Of course if you are in a place in your life where socializing at work is really important to you, then factor that in as something that is important.


The most valuable thing about having a deadline is that it forces a conversation about what is important. Importance is simply what matters right now, and what doesn’t matter right now. This is always in flux, always changing and evolving, so checking in on importance with some regular cadence is helpful. Often it is understood in projects that not everything can be delivered by the deadline, but it is seldom discussed until a deadline is put into place. Then suddenly all sort of discussion starts. At first this can look like angst, but it is incredibly valuable discussion. Deadlines force teams to work through what is important, and to let go of things that don’t matter, right now. This forces prioritization, which allows teams to focus. Dates elucidate what should be focused on first and what can be postponed. This natural order helps teams to cut through ambiguity, and begin to make real traction executing on deliverables towards concrete dates.

In contrast, if you leave all of this open-ended, there is no forcing function to prioritize project deliverables, no focus for email communication, and no way to say no to meetings. Eventually you end up working on everyone else’s problem, working late on your own, and eventually feeling tired overworked and resentful. This is when folks tend to take time with co-workers to vent which will eventually corrode team morale. Now compound and multiply this times the number of folks you have in your organization.

You know thing aren’t in a healthy state, when everything is a fire drill, everything is an emergency, everything is a reaction, a response, and everything is critically important. This approach is extremely short-sighted and deceptive, in that it can successfully garner short-term results, because everyone responds to the immediate sense of urgency, everyone likes to feel like a hero once, or maybe twice. But the heroic amount of energy required to respond, time-and-time again is exhausting. This is what eventually leads people to burn-out. Once they see no end in sight to the fire drills, they stop caring. This is because when everything is of equal importance, really nothing is important. If management isn’t able to effectively plan, prioritize, and load balance projects, then what are they there for? Eventually people figure this out and leave the project, feeling resentful, and taken-advantage of, and rightly so. The sub-conscious message is that people aren’t important.


One common miss-conception is that dates have a rational justification or meaning behind them. The truth is all dates are completely arbitrary. They are an illusion. Folks will come up with really great reasons to justify deadlines, like quarterly earnings, back to school, holiday, etc. but they are still arbitrary. You can miss the date and still be successful. Good teams are transparent about dates, but still buy-in, commit to the date (assuming it’s reasonable) and execute against it with the best possible sustainable effort. The best analogy I have heard for hitting deadlines, is to treat them like a really important goal. If you make it a goal to hit the date, then you are thinking about it in a healthy way. As dates get close, usually you can do a reasonable push to meet the date without overextending teams, but this is only if you have clear buy-in to the date and folks are working towards the date in earnest from the outset.


So what can be done about all of this. Thankfully the process of time boxing is fairly straight forward. Start by taking the big, unapproachable project or projects, and begin breaking them down into smaller components. For example if you’re building an e-commerce website, look at the landing page, the category pages, the search results page, and detail page, etc. Continue until you’re at a granularity that is actionable. Now decide which area is most important.

Here are some helpful questions to ask:
▪ What is the most important thing to focus on right now/today?
▪ What can be postponed until later?
▪ What are the obvious next steps?
▪ How long will they take to complete?
▪ What is a reasonable deadline to deliver?

Put each component into a list (a backlog) and put each item into priority order. Once you have determined an order of execution, figure out what you need to do to deliver it and set a reasonable date for delivery. Now you have a time box. You know you have achieved when you are able to fill in the blanks: We will deliver a ‘‘ for the ‘‘, by ‘.’

Or using the example above, I will deliver a landing page for the new e-commerce platform, by January 20th.

The beauty of this is that it is immediately actionable. You know what is important, you have a handful of actions, and you have a date to drive towards.

Agree On Problems First Then Solutions

by on August 19, 2013
in book, design

An Excerpt taken from, The Value of The Finite
‘The formulation of the problem is often more essential than its solution, which may be merely a matter of mathematical or experimental skill.’ ― Albert Einstein

It sounds so simple, but it’s very common. How often have you been sitting in a large meeting, where people will jump right into the issue of the day. There will be a very brief mention of the issue, it’s significance, and then the room will jump right into discussion about how to solve the problem.

Often times you will have many people with diverse roles with equally diverse perspectives on the issue. Some folks may not even agree that “the issue” of the moment, is a problem at all. This can be very detrimental in meetings, because if the issue isn’t of any interest you get people opening laptops, picking up phones, or otherwise checking out of your meeting. If this evolves into a pattern, pretty soon no one will even show up for your next meeting.

Even if you are lucky and maintain the involvement of people’s attention, you will still have the issue of mismatches perception and understanding. People will interrupt one another, talk over each other, all eager to share their perspective on the issue. In this situation folks will talk past one another, likely saying the same thing in a slightly different way, but because there is no agreement, no one is listening to each other.

This is when meetings feel heated and escalate, but it’s not clear at all why. It’s because everyone is racing to be the first one to solve the problem, no one is listening to each other, and no one has agreed on what problem needs to be solved.

Because many folks prefer to be the individual with “the idea” or “the solution” instead of the individual pointing out the challenges ahead many folks will jump right to solutions which is great although slightly premature.

Until the patient has been diagnosed there is no way to know what medicine is required. Identify and agree on the issue at hand, then discuss solutions.

To move past this you need to clarify the problem statement, the open issue, and get everyone to see it the same way, agree on the issue, and then solve it. This removes all of the tension, frustration, and focuses the group one cooperating to collaboratively problem solve.

It may feel silly but while in a group, you will want to say it outlook even, something like “so it sounds as though we agree the issue is wiz bang,” great now let’s talk about how to solve the problem.

This becomes even more effective when you have multiple interrelated compound issues. Start with an agenda of open issues. Agree on the agenda. Make sure you are solving the right problems!! Then solve them! Now go on do it. Destroy!

It sounds so simple.

Importance Of Feasibility

by on August 15, 2013
in book, design

An Excerpt taken from, The Value of The Finite
“If it don’t make dollar – then it don’t make sense” -DJ Quik


Every design project carries with it implicit requirements. Requirements stem from all manner of sources. Hopefully the target customer, often the client, the technology, or the business. There can often be so many it can seem overwhelming. Where do you start? Who do you listen to? What is really important? To make things more complex, some requirements are soft and malleable. Usually these are the attitudes or opinions of people involved with projects. Other requirements are quite rigid and introduce difficult constraints that have to be worked around within a designed system. It is often these unseen, unspoken, undocumented rigid requirements that get missed early while making project estimates. Dates are set, commitments are made, work begins, then as you dig into the project you begin the discovery process.

Project requirements are the iceberg beneath the surface just waiting to sink your ship.

Once you hit one you know it. Designs often have to be iterated multiple times to accommodate and keep projects moving forward, but often at huge loss of schedule, and cost to the team. In fact it is hidden requirements like this that are the basis of agile vs. waterfall development. Waterfall pretends that you can dig in while planning a project and identify all of these icebergs document, and plan contingencies for them. Agile knows better, and assumes that you will have to do some work, some investigation to dig in and see what you’re up against. Either way you’re trying to understand what is hidden within the project sitting in front of you and identify efficient ways to workaround.


There are three standard sources which inform design requirements; the customer, the technology, and the business. It is critical to identify these sources as early as possible within projects. By understanding the motivations behind investments from a customer, business, and technology perspective, designers are fully empowered to identify assumptions throughout the design process. This will help designers develop project principles, codify design goals, and to make appropriate decisions and compromises (yes all designers compromise) relative to the importance of the requirement source.

One of the first hard truths relative to working as a designer for a living is that; 90% of design is about understanding what you are designing. Then once you understand it, 10% actually designing it.


Hopefully you have a very clear immediate customer need in mind with your project. This is often a well understood opportunity addressing a known customer issue, gap, pain-point, or trigger, often supported quantitative data, or qualitative customer research. Sometimes the customer requirements stem from an ambiguous emerging customer need. These can be tricky, and are often a loosely-defined, or competitive opportunity influencing, or capable of influencing a customer (typically supported with quantitative projections and qualitative competitive data). Either way these should be your north star on the project. The customer needs or requirements should always be used as the first inflection point in decision making. Codifying project principles, and design goals should begin with your customer opportunity, and should be used to negotiate, technology and business requirements.


  • System pain-point that needs improvement
  • Attitudinal or emotional bias (can be positive or negative) toward a solution
  • Functional value gap
  • Address a trigger


Customarily these requirements are non-negotiable at the expense of significant cost to the organization. Savvy designers possess enough technical knowledge and experience to identify small workaround investments which have a large scale impact to the overall quality of the design.
To identify these sources early, designers must read all technical briefs and functional specifications associated with the project. Designers must also attend meetings, and ask clarifying questions. Appropriate proactive involvement directly in the project, will work in the favor of the designer.
In turning towards the technical stakeholders (developers, contractors, testers, program managers, project managers, etc…) designers are also building relationships with the people responsible for making designs real within the physical world.

Any engineer worth a damn will tell you, anything can be built, it’s just a matter of cost, or how much you are willing to pay to build it. In systems design this cost is typically the engineering and quality assurance resources assigned to the project, as well as the amount of time they have to build and stabilize it.

If your design concept isn’t technically feasible, with the resources you have, and the time you have, you’re simply wasting everyone’s time. Save yourself the heartache. Vet concepts early with technical leaders. Figure out what is possible, but don’t compromise on your customer goals unless you have no other choice. If you backslide too far, you likely aren’t delivering any incremental value.


  • A platform to build from (some existing technical foothold to build off-of)
  • Time (prototype, prove-concept, build, test, refine)
  • Resources (people)
  • Motivation (justification for investing)


Evidently, businesses tend to stress strategic business goals, directives, or charters which emphasize a particular technology, investment, integration, or outcome. These directives can and often do, conflict directly with the market, customer needs, and the designer’s principles and goals. Nonetheless, it is the job of the designer to understand and accept the motivations of the client or organization and elucidate solutions that balance everyone’s needs.

It is common for designers early in their career to misinterpret business priorities or identify them too late in the project to be appropriately effective. Such requirements can be obfuscated in overly technical business speak, organizational politics, come from misinformed sources, or through multiple layers of hierarchy within larger organizations. Thus it is critical that designers possess appropriate courage and conviction to ask (sometime difficult) clarifying questions of the most executive management. This must be done within the requirement gathering phase of a project to be effective. As with most things in life, timing is everything. If these questions are asked too late, the opportunity has been lost, and the designer may be perceived as difficult to work with, and may potentially lose credibility with the client, or organization as business goals are missed.,

If you don’t have a clear strategy for how your design will move the needle towards established business goals, again you’re simply wasting everyone’s time. There is a very delicate balance between intentionally stretching a team beyond it’s current implementation or current technological gate, and taking things so far beyond what’s feasible, that no one can buy-in to support the proposal.


  • Business justification for investing
  • Metrics to measure success
  • A clear deadline for delivery

To earn the respect and trust of people who actually have to manage and build your designs, feasibility is the first priority. Take it upon yourself as the designer to understand all of the technical constraints and affordances and make the right trade offs. This will minimize disruption and streamline the implementation of your design. Remember until it’s been translated to code, tested, stabilized, and proved – all you’ve produced is a drawing and unless you’re a fine artist that isn’t going to pay the bills. Ideas on paper aren’t fiscally valuable until they have been translated to code. Take it upon yourself to know something about the technology being used to implement your solution and then and only the. Push gently to evolve.

Designing to Design

by on August 6, 2013
in book, design

An Excerpt taken from, The Value of The Finite
One of the pitfalls that is currently plaguing an active project, is a lack of planning upfront to determine an appropriate outcome.

This shows up in several ways:
Lots and lots of ambiguity about the project. Ideas like , we just want you to start in with fresh eyes, the sky is the limit. As we all know every project has to come down to reality at some point, and this vague of a start can only lead to lots and lots of unnecessary inefficient iteration.

Better to get the project on some rails upfront if possible. What are the principles, what is the purpose, what are the priorities – what’s important or most important. How long do you have to complete the project?

These are the fundamental building blocks of information required to articulate design goals. The questions you need the answers to up front are:
1. Why are you doing what you are doing?
2. What are you trying to accomplish?
3. What does success look like?

From here you can exercise trade offs that will be feasible within time constraints. It unfortunate human nature to assume time is unlimited and that this level of ambiguity is acceptable early in a project.

Unfortunately too often this translates into heroic efforts late in the cycle to make the impossible possible, which burns people out leading to inevitable and unnecessary attrition.

Have the discipline to decide what is important at the beginning and stick to it, and only adjust if the alternative means failure.

Changing direction mid-project is another common challenge to projects. This can show up as new direction from management, a sudden new idea from someone influential to the project, or in the vehicle of pointed feedback. “That’s just not what we’re looking for anymore…”

Once the project has surpassed the ideation/discovery phase and transcended into execution, this is one of the most terrible and unfortunately common setbacks to projects and should be acknowledged as such.

Often times being a designer means that you’re presenting ideas and solutions through management with the goal of tipping the project from discovery into execution. This is when organizational politics can wreck havoc as other teams, sponsors, and vendors learn about your intentions, are able to see and visualize it first hand. Project stakeholders are suddenly jolted into reacting. Often not in accord with the project agenda.

Having the discipline to focus and ride the organizational wake of such reactions will test project leadership, management, and the team. Successfully guiding projects through each phase of the project phases is the role of management. Not the role of design. This is where early established principles and vision can be used to remind management of what your looking to accomplish, to rally internal agreements and influence stakeholders. Backsliding too far this early can have devastating effects on the project and team morale.

This is why it is so important to get as clear as possible on the why, what, and when of your project up front.

Any adjustments require a full re-evaluation to ensure a successful outcome.

Stakeholder Evaluation, Roles and Responsibilities

by on July 12, 2013
in book, design

An Excerpt taken from, The Value of The Finite

By taking the time to understand the people involved with your project, your own role and contributions, and thoughtfully engaging the right people in the right way, you can make a significant impact on the ability of your project to succeed. It also has the side benefit of helping your career as well. This is fundamental, but is often overlooked in the design discipline. It is critical to ensure you are involving the right people in the right way with intention in the design conversation. The process is really pretty straightforward, simply ask yourself who needs to be involved, how and when should each individual be involved, and what is their actual role and/or contribution?

While working through this exercise keep-in-mind that the magnitude and importance of this is corollary to the scope of the project, the size of the organization, the number of internally dependent teams, as well as any external partners. By looking at a project through the lens of all of the “other people” working on it, communicating about it, and losing sleep over it, you can gain some very useful insight as to how to appropriately involve everyone in the design conversation.

Take thirty minutes and do the following for your current project. I guarantee it will be the most useful 30 minutes you invest in your project today. You can thank me later.


1. Make a list of all the people directly or indirectly involved with your project – include people

2. Answer each of the following questions for each person:

What is their role?
What function does this person perform in the organization?
What are their expectations?

What is their responsibility?
What is their expected contribution to the project?
What do they really want to contribute?

What is their motivation?
What is their personal and/or professional interest for involvement?
What is really important to them?

What is their preference?
How do they work?
How do they want to be involved?

3. If you don’t know the answer to the questions, be direct and ask. It’s amazing how much people appreciate this.

As an example here is a stakeholder evaluation that I conducted for a primary influencer from a past project (all information has been fictionalized to protect

Stakeholder: Sally Joyce
Role: Project Manager (mid-level)
Function: Manages schedule, delivers functional requirements for the project, and also communicates project status.

Expectations: Involvement in requirements authoring, feasible timely design solutions respectfully incorporating functional requirements. Communication of blocking issues, and the completion of deliverables. Involvement in preliminary design discussions to prevent missed requirements.

Responsibility: Accountable for the delivery of the software solution on schedule.
Contributions: Requirements, feedback on designs, schedule, communication.
Actual Contributions: Are in alignment, no gaps, or conflicts of role and contribution.
Motivation: Date driven. Delivery of solution on time, without slipping, irrespective of quality.
Importance: Meeting dates is really important.
Style: Assertive face-to-face, passive written, prefers face-to-face, often doesn’t read emails.
Involvement: Needs direct involvement in reviews to meet preferences. Won’t appreciate or read written status.

As you can see, by just reading the summary above, having never even met Sally, you probably would have a pretty clear idea about how to work with her, what she expects, what makes her tick, and how she prefers to work.

The funny thing is we all have these needs in the work environment, and we so rarely communicate and talk about them. It’s as though there is some sort of social contract that says we’re just supposed to intuitively “know” all of this about each other.

It’s amazing to me what happens when you simply directly ask the right questions, instead of guessing, assuming, or pretending to understand people. When you assume this, you are simply projecting your thoughts and beliefs onto someone else, and this can have the adverse effect of alienating the people you will eventually need to rely on to deliver.

When conducting an evaluation like this, often I will just be getting to know someone related to a project, and won’t know the answers to many of these questions. So i’ll schedule a thirty minute one on one to fill in the blanks. Every time I have done this people generally open right up, are really happy to talk about what they care about, what their perception of their role and contribution is, and what is important to them. People like to talk about themselves, it’s what we know, it’s human, and people generally really appreciate it when you simply take a few minutes to understand them.

In retrospect I have spent years of my life working with people on projects having not done this. I guessed, assumed, projected, tried to reach over gaps, and made so many mistakes in the process. This simple tool employed appropriately, early in a project, can go so far in building really solid foundational working relationships on your projects.

It takes a little effort, a little practice, and a little discipline. And once you get the hang of it, not only will you earn the respect of the people you work with every day, but you will also advance your own self-awareness relative to your contributions, motivations, and preferences.

Design Review Process

by on July 11, 2013
in book, design

An Excerpt taken from, The Value of The Finite


The design review process is a tried-and-true social mechanism for ensuring standards of quality, cross feature and functional alignment, ensuring consistency across deliverables/functional areas of larger projects, and incorporating feedback from project stakeholders.


Ensure that designs meet appropriate standards for consistency, accessibility, usability, findability, internationalization, performance, etc.


  • Maximizes transparency of design progress
  • Acts as a natural forcing function for progress
  • Ensures that designs meet business goals
  • Helps to minimize late changes to product requirements and concepts
  • Helps to ensure brand integration


  • Realize maximum value internally from design teams
  • Facilitates teamwork, learning, and cross-pollination of ideation
  • Increases team accountability
  • Involve teams and project stakeholders in the design process


As with any other meeting (see chapter 2.1.1 On Time) ensure that the agenda is clear, that roles and responsibilities for the review are assigned, and that the work up for review maps to one of the following categories or design stages. Send the framework for the review at least 1-2 days in advance of the review. Do not send the designs ahead of time unless you require feedback from folks that aren’t available face-to-face for the review. Feedback on designs is very subtle and is almost always best shared face-to-face whenever possible. This also allows the designer to capitalize on the first impressions of the design. Often folks feedback will evolve if they have enough time to “think-about-it” which is still useful, but isn’t aligned with how an actual customer will consume a design solution.


  • Design Owner – The designer (in the hot-seat) presenting his work for the review.
  • Design Reviewer – Ideally at least one other designer, someone from outside the design discipline – ideally test, and a researcher if available.
  • Informed – Make note of any key stakeholders outside of the review that may need to be informed on the review status, and follow up notes.
  • Note Taker – Someone needs to take notes, which should only be sent directly to the design owner. This responsibility should rotate on teams.


The goal of conceptual design review is to verify early that design concepts map to the user experience vision and product pillars. These could be anything from pencil drawings, pixel perfect comps, interactive prototypes, or even competitors solutions.


  • Low-fidelity/Med-fidelity prototypes – Ideally from an efficiency perspective little time investment has been made this early in the process.
  • Preliminary interaction/navigation models
  • High-level design concepts – Many interaction or core details may be left missing. This is ok, the goal is to understand and talk about the high-level direction.
  • Preliminary information architecture/s
  • Design schedule – How is progress relative to committed dates? Are things on track?
  • Task analysis – Are there critical use-cases missing that would fundamentally alter the design or force a change in direction?
  • Competitive evaluation- Are there existing solutions the design is informed by? Are there better alternatives out there already?
  • Alignment to product vision/pillars – Are you aligned with them?


  • What scenarios/stories/use-cases/tasks does this concept address?
  • How does the concept accomplish the scenario/customer goals?
  • How does this concept deliver maximum value to the target customer/primary persona?
  • How is this concept better than existing/competitors solutions/offerings?
  • How did data/research help inform/shape this concept?
  • Which stakeholders have given input into your concept?
  • How does this concept integrate with other products/feature areas?
  • How does this concept fit into the product pillars and product vision?
  • How is progress relative to committed dates? Are things on track?


The goal of the design standards review is to verify that the updated design concepts meet the required organizational design standards. Of course every organization is different, but if you don’t have any defined standards documented, that might be a better place to start, rather than effectively “flying-blind” and proceeding with product design without any documented and agreed to design language.


  • Med-fidelity/High-fidelity prototypes
  • Applicable user experience guidelines, organizational best-practices, and documented design language
  • Low-level design
  • Design schedule


  • Does the design look right?
  • Does the design feel right?
  • Does the design align with all documented standards within reason? Includes: design language, team principles and tenets, and standardized best-practices.
  • Are there new deviations/innovations that should be documented?
  • Does the design fit into the product road map and product vision?
  • How is progress relative to committed dates? Are things on track?


The goal of the interaction design review is to verify that the proposed interaction/behaviors are clear, predictable, consistent, and usable.


  • Med-fidelity/High-fidelity prototypes
  • Applicable user experience guidelines
  • Low-level design
  • Design schedule


  • How is the UI design tailored to the primary persona?
  • What are the most significant engineering concerns for this design?
  • What interaction standards or best practices have been employed?
  • Are there any necessary additions or changes to the visual specification needed to support this design?
  • What legacy features may be impacted by the proposed design?
  • How is the interaction design consistent with the brand?
  • Does this design require ongoing maintenance?
  • How is progress relative to committed dates? Are things on track?


The goal of the visual design review is to verify that the visual design of the UI maps to the design vision, the visual specification, and the brand guidelines for the current release.


  • Full fidelity pixel perfect compositions of core screens
  • Color palette
  • Icons, graphics, and branding
  • Visual specification
  • Brand guidelines
  • Product vision


  • Do the visual design elements within the UI align with the brand guidelines for the release?
  • Do the objects (buttons, tabs, menus, etc) align with the visual specification?
  • Does the visual design (colors, grid, typography, graphical style, icons, and logos) align with the visual specification?
  • Are any amendments are needed within the visual specification to support this design?

On Quality

by on June 27, 2013
in book, design

An Excerpt taken from, The Value of The Finite

When you experience quality it is unmistakable. The hours of design, engineering, quality assurance, and production processes and standards that go into the sound that a car door makes when it is closed. The seamless fit-and-finish between the unibody chasis and backplate being rounded to the nearest nano-meter so that the device doesn’t collect lint from your back pocket. Being politely and promtly greeted with a smile, the music level is just right, you’re able to move through the tables without discomfort, the table is clean and set, it’s not too hot or too cold, there is a hook for your coat, the type on the menu is legible, it’s not too bright or too dim, you’re greeted again warmly, given just enough time to order, but never pressured, hurried, or neglected.

  • Quality is quiet and confident.
  • Quality has an element of suprise, it’s about getting more than you expected.
  • Quality has an element of balance, it’s never too much, nor too little.
  • Quality is paying attention to all of the small details, and ensuring that they are taken care of.
  • Quality is about giving a damn.
  • Quality is about getting it right most of the time.
  • Quality is about always, always making it right when something goes wrong.
  • Quality is about consistency so that you’re expectations aren’t lowered next time.
  • Quality is unmistakable because it is rare.

So how do you capture this rare and wild creature? How do you build quality world class design solutions, design teams, products?

Quality requires three simple things.

  1. Quality people
  2. Quality attitudes
  3. Quality priorities

Delivering quality requires people that care about quality. People who care about, pay attention to, and are sensitive to quality are pre-requisite to deliver it. From this perspective with this attitude and set of values, decisions get made a little differently, tradeoffs are made differently, and delivery is generally consittently at a higher-bar. You need people who understand and have experience in exchanging the currencies of quality within complex projects to be able to deliver quality products. Without them, you don’t have “it.”

Quality is an attitude. Some might even call it a religion. It’s a core value, like honesty or integrity, it’s not compromisable. It’s about getting it done right, not just getting it done. People who don’t understand this simply “don’t get-it.” Therefore when transalating this prespective value into the workplace, a aptitude and belief in quality is also required. This can lead to value conflicts as well so be careful if you really want “it.”

Finally quality is completely dependant on having clearly established priorities. Quality means knowing what is important, and conversely what is not important. By being laser-focused on what matters and equally aware of what doesn’t you can quite effectively drive quality into a product, and through to completion. If you don’t know what matters, and what doesn’t matter, you will be completely paralysed, you will never get a team aligned, and you will never ship.

Myths about quality:

  • Quality is expensive
  • Quality takes longer or can’t be done on time
  • Quality is subjective
  • Quality isn’t achievable
  • Quality is a hinderance to productivity
  • Quality can’t be measured

Things that compromise quality:

  • People that really don’t care
  • Not knowing what is important
  • Not knowing what isn’t important
  • Not taking the time to discuss and agree on what is important
  • Taking on too much
  • Underestimating how long things actually take
  • Having and maintaining a low standard for defects
  • Maintaining a bar of acceptable defects, rather than maintaining a acceptable quality bar
  • Only QA/test is there to ensure quality

Steps to build quality:

  • Make quality a core team value or principle
  • Manage folks out that don’t care enough to make “it” happen
  • Hire people that understand, and have a track record for successfully delivering high-quality
  • Be really, really clear with the team about what matters and what doesn’t – don’t deviate
  • Do a few things that are tangible, understandable, and do them really, really well – don’t deviate
  • Figure out how long it will really take to deliver – get quality estimates
  • Set a date – don’t deviate
  • Set a quality standard – meet it everyday
  • Everyone is accountable

Reductive Reasoning and Focus

by on June 26, 2013
in book, design

An Excerpt taken from, The Value of The Finite

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.” — Albert Einstein

Less is more. I’m sure you’ve heard it before. Ludwig Mies van der Rohe coined the term as a core precept for minimalist design. Great, so how do you actually do this? The solution is to focus on what matters, and remove everything getting in the way.


  1. All systems have a hierarchy or natural order.
  2. By pruning a system back to it’s core essential elements you expose it.
  3. This exposure enables the natural understanding of a system, as each element naturally leads or directs to the next.
  4. In this way the architecture is self directing. It is it’s own guide.
  5. This natural order within a system or architecture is what we refer to as intuitive. We know it when we see it.

To put it more simply most systems and/or architectures are full of filler. This filler abstracts the system and if applied thoughtlessly can make a system seem foreign, alien, less approachable, or even intimidating.

For example we hide electrical and plumbing systems behind false walls in most homes. But it we strip back the structure to it core elements it becomes self explanatory. We can follow each and every cable from the junction box out to each satellite outlet and socket. We can trace the plumbing stack out to each receptacle, the hot water, the cold water from the source to the destination. The system itself is self-evident. It explains itself with very minimal understanding of electrical engineering or plumbing and physics. Even the sub structure/framing it self evident. It’s clear where something is load bearing, where subdivisions occur, and why they exist.

Everyone intuitively understands how a ferris wheel works because it’s mechanics are exposed. No one understands how a car works because the whole system is hidden from the driver. It seem mysterious and unapproachable. But in ten minutes I could teach just about anyone how to change their oil. Give me thirty and we could draft out each primary component of an internal combustion engine, and discuss how each sub-system serves an individual function of the whole.

The core of understanding of reductivism within a system is to understand these ideas. The notion is to thoughtfully expose the core structural elements to the user that are requisite to understand how it functions. Strip away unnecessary filler. Apply filler judiciously and with intent. It is most useful when applied to help direct or lubricate the understanding or ease of use, typically when transitioning from one sub-system to another.

So many systems are filled with unnecessary distractions, decorations, and each of them simply add noise to the overall gestalt of the system. You can end up having to add new distractions to circumnavigate the existing distractions. Far better to remove the initial issue, and re-evaluate. Let the purity of the engineering sing. Let it be it’s own muse.

Sadly, distractions are all too often internal or intrinsic to the project or organizational culture you are working within. Too many conflicting opinions about a design can easily shake your confidence, and quickly have you wondering if you’ve headed down the right path or not. Some organizations thrive on embellishing systems with unnecessary distractions, believing they are “adding value.” This value add statement always scares me, simply because the initial system was likely perfect the way it was initially intended. Once new features or functionality are attached, not only does the underlying infrastructure become obfuscated by the “feature-of-the-day” the bolted on apparatus feel out-of-place. With mature software I have seen this “bolt-on” approach time and time again, until the whole system is simply a series of appended apparatus. The system itself no longer has any intention, elegance, or structure to communicate with a user about how to move through it. It is too full of features to be understood. This is also commonly referred to as “bloat-ware.” This happens also in architectures when spaces are remodeled time and time again. Each time being repurposed for different uses, goals, needs. The whole core of the space is engulfed, and it no longer breathes.

So if you’ve inherited a project like this, or are working within a culture full of “value add” thinking, think again about the assumptions biasing your approach. Look earnestly and directly at the system underneath all the crap. What is it telling you. Find it’s critical communication points and uncover them. Make it sing again.

This can be done tactically by simply creating multiple concepts. One with the crap. One with it stripped away.

The streamlined singing system will sell itself. It will be self-evident. The thing you have working in your favor is that most human beings are fairly predictable, and generally speaking we all appreciate something more if we can see it for what it is, approach it, understand it. I have yet to put two examples like this in front of key-stakeholders or decision makers, and have someone choose the crap. It’s almost anti-human once you see the two approaches juxtaposed.

We call this “intuitive.” When you ask someone to explain why they find something intuitive they almost can never put it into words. It’s like some sort of magic. The truth is the system is simply self-evident, likely because it isn’t full of a bunch of distractions, obfuscating it’s purpose and meaning.

You have to use your eraser as much as your pencil. Keep at it until you’ve reduced the system back to exactly what is required, and shamelessly throw away what isn’t needed. This is the essence of achieving simplicity.

Next Page »