The Wikimedia Foundation has announced a campaign in collaboration with the South African creative community promoting the right of access to knowledge and encouraging…
Just like walking on a tightrope — part of the act is about balance, focus and reaching an end point without falling. The other part, the logistical side of the act, is about how tightly strung the tightrope is. If it’s too loose, too giving, the tightrope walker won’t have anything to hold on to or grip. If it is too rigid, there isn’t enough room for the walker to recover if he makes even the slightest mistake. It has to be tense enough to have a predictable boundary and structure, but loose enough to make allowance for human error and any other unexpected interference.
This analogy seemed particularly apt when we embarked on a website redesign for a large company with many stakeholders. The process started with workshops with representatives of the different business units. Each workshop followed a similar structure and insights were gained into how the business operates.
After user research and fully grasping the various inputs and challenges, a sitemap, colour coded by templates required, and an initial first set of template wireframes were designed. The first unanticipated challenge then surfaced: the company had also hired the services of a branding agency to do their brand architecture. Part of the architecture involved the look and feel of the brand, which included a new CI (Corporate Image) guide. In order for our team to get into the visual design, the digital CI guide needed to be cemented.
This was looking like a blunder of massive proportions since both agencies were working in parallel, apparently on the same problems, without any knowledge of the other. Fortunately, we managed to arrange meetings, introductions and formulated plans for collaboration. We continued with the wireframes, slowly piecing together the new website mindful of the fact that at any minute, something about the brand could change.
But, as I’ve learned, large companies have a tendency to work in this way. Often, because the different departments deal almost exclusively with their own business, there isn’t much inter-departmental communication be that internal or relating to vendors and service providers. The lesson is that the earlier you can find out who else is involved, even seemingly indirectly, the better for the overall project. Being exclusively focused on the project, it’s important for the project manager and UX designer to understand the potential implications of any other concurrent projects.
After presenting the rationale, the site structure and some of the templates, the business was asked to circulate the prototype and presentation and provide feedback by a certain date. It was explained that because deadlines were tight, the process would follow an iterative delivery approach. Timelines were drawn up, dates were agreed upon and everything seemed to be on track for a project that required tight team work. But the second lesson I learned from working on this project, is that deadlines are really only important to those being paid to get the job done.
It’s not that the various stakeholders don’t care about the project; it’s that the progress and milestones needed to be met to reach completion are not the concern of the people who have a stake in a small piece of the project. Their day-to-day business isn’t a single project and therefore they do not have the time to focus on it exclusively. From an agency perspective, this aspect is tricky to overcome when you are under pressure to meet deadlines and design the right solution, but getting buy in and approval is always key and this is where good-relationship building in invaluable.
Luckily, having user insights in your arsenal is akin to having a royal flush. When you can back up the decisions you’ve made with the fact that they address the user’s pain points with your product, you have the power to listen to business objections, but not be compelled to agree or comply with their proposals. Having these insights, documenting them early and referring back to them often is the difference between your tightrope being too loose or too rigid. It allows you to make decisions, compromises even, as long as they don’t affect the act. It also sets the tone for how you deal with unexpected technical, business or strategic challenges.
This is the third lesson that I have learned from walking the UX tightrope: you may have to make tough and unpopular decisions, but as long as they’re based on actual user insight and address the users’ needs, there is no need to be too rigid about unanticipated challenges. Being flexible, when necessary and within the boundaries of the ultimate goal and vision (as determined by the user needs) is what makes a challenging project work successfully.
Image: Wiros (via Wikimedia Commons).