Avoiding aesthetic design rework - or getting the right level of design input at the right time

Decision makers love images; they love mock-ups, functioning prototypes, user journey maps, nicely designed pages they can show their 'stakeholders'. The problem with this is that the customer often cannot see the value of work being done until it is presented in a more visually pleasing manner. After all, if you show a customer a page of JSON, they don’t actually understand how much work has been completed. One front end developer told me that he came into an organisation where a lot of work had already been done, yet after a week he joined the client was singing his praises. “Look how much work has been done since ‘Bob' joined, amazing.” The fact was the work was there, but it didn’t look great, so customer gratification was delayed and the developer was given the credit.

Unfortunately, this means that by the time customers can appreciate the work done, they often change their minds, getting drawn to the presentation rather than the substance. While this may be relevant for some large retailers, and even in this case, it can be an dangerous path. Often work already completed, but ‘invisible’ to the customer, is thrown away because decisions are made based on visual design rather than underlying functional features, weakening the overall product and having a negative effect on the morale of the developers.

Based on my personal experiences and some chats with my colleagues around what could be done to avoid this pitfall on future projects, I’ve come up with several lessons. None of the examples below include anything around the architecture, but let’s take that out of this discussion for now and keep things simple. I’ll address development and architecture in a follow-up blog.

So let’s cut to the chase, here are the lessons I’ve learned:

1. Use low fidelity wireframes, don’t waste time on high fidelity until the feature has been validated by at least a sample of the end users.
2. Do minimal design around functionality that is volatile or requires high user input or business decisions, for example where the business is unsure whether something will work.
3. Ideally, locate the designer in the dev team.
4. If you can’t do #3 then don’t make things worse; don’t create Product, User Experience/Design teams unless you have a liking for office politics!
5. Let the developers have a design framework (rather like a simple brand guideline) and let them be creative within this framework, this will avoid the delayed gratification problem.
6. If the designer is outside the team, discuss the designs with the developers at the idea stage.
7. Do not design-out value. In other words, don’t hide information from the customer that they “will not want to see” - after all they will ignore what they don’t need and they may surprise you. For example, the design might call for three facets to be shown on a search page, but there are actually 20 available, or the system can suggest the top 10 most relevant facets without any further development work, giving the customer an opportunity to show through their use of the system, which of these have value).

Here are some examples of projects I’ve worked on ordered by those with the lowest level of design rework at the top:

Project A Initiate by writing a story list for a proposal, throw these out, workshop some new stories using flip charts at the lowest resolution wireframes possible, write outline stories, start development

• Designer location: In team
• Level of pure design rework: None
• Main reason for rework: N/A
• Freedom for developers to be creative: High
• Time to get developing: 1 week

Project B Initiate project with small list of features, identify use cases, work up a working excel low fidelity prototype (1 day), confirm use cases, start developing

• Designer location: No dedicated designer
• Level of pure design rework: None
• Main reason for rework: N/A
• Freedom for developers to be creative: High
• Time to get developing: 2 weeks

Project C  Initiate with basic needs discussion, identify main feature areas, create a paper set of basic wireframes, write some high level stories, start development, work up detailed design, have it accepted, then have the design challenged, design put out to tender, original design re-approved

• Designer location: In team
• Level of pure design rework: Low
• Main reason for rework: Feedback from customers
• Freedom for developers to be creative: High
• Time to get developing: 6 weeks

Project E Get large document from previous workshops, throw it in the bin, workshop 10 features, create cards for these, work a minimal design, make the design fit the look and feel of the corporate site, sort into order, start developing

• Designer location: In team
• Level of pure design rework: Low
• Main reason for rework: New features extend functionality
• Freedom for developers to be creative: Medium
• Time to get developing: 1 week (not including previous attempt at project)

Project F  Identify features in bid, run vision workshops, run requirements workshops, user journey workshops, create detailed high resolution wireframes, start development, change design, rework, started to deliver more open ended features (i.e. those that avoid designing out the possible next steps

• Designer location: Outside dev team in Product Team
• Level of pure design rework: Medium
• Main reason for rework: Customer feedback on design
• Freedom for developers to be creative: Low at start then much higher
• Time to get developing: 8 weeks

Project G Workshops held before development team engagement, backlog created, high resolution designs created, development team engaged, many features developed as they were in the design, many features replaced

• Designer location: Outside dev team in Product Team
• Level of pure design rework: Medium
• Main reason for rework: Change of business requirements and design
• Freedom for developers to be creative: Low
• Time to get developing: Months

Project H Create mock up high resolution designs, create stories, start development, deliver high resolution designs, rework, change mind about designs, include extra features as these are in the designs which are now signed off, rework

• Designer location: Outside Dev and Product teams
• Level of pure design rework: High
• Main reason for rework: Design changes
• Freedom for developers to be creative: None
• Time to get developing: Months