Jerry Cao is a UX content strategist at the collaborative wireframing & prototyping app UXPin. For expert advice on building creative yet feasible designs, check out the free 34-page e-book Building Mockups Developers Won’t Hate.
The most rigorous phase of brainstorming often occurs after receiving details for a new project. After all, most of the early ideation falls within the design team’s jurisdiction since they’re usually considered the “creative” minds.
But as dictated by modern design thinking, you shouldn’t restrict creative thinking only to design or marketing teams. Design is not a tactic, it is the art and science of solving problems for users. With the right guidance, usable design ideas can emerge from the roughest (and most unexpected) of origins.
What this means is that developers are just as important to the design process because they actually make the ideas come to fruition. Never forget that developers are simply designers of code.
When starting any new project, invite as many designers and developers together into the process as early as possible. When it comes to effective brainstorming, tackle issues related to both design and development so that everyone has a chance to air their grievances – but make sure only a small focused team has the final say.
With that in mind, let’s examine a helpful framework for starting your design projects with the right people in the right direction. If you’d like more tips for successful collaborative design, check out the free e-book Building Mockups Developers Won’t Hate.
Adopt Open & Honest Communication
The atmosphere in the room determines the success of idea generation. In order to make everyone feel open to suggestion without rebuke, create as objective a discussion as possible.
Brainstorming is a vulnerable process where people overthink and may take rejection too personally. Remind everyone to stay objective and focus more on the idea(s) rather than the messenger. Designers and developers may express their ideas differently, but remember that everyone has the project’s best interest at heart.
“Design may rely on aesthetics for its medium, and development may rely on code, but both draw on theories of efficiency to create effective output,” says Mozilla’s lead UX designer Cassie McDaniel’s in her excellent Smashing Magazine article on designer-developer collaboration. “Elegant code is efficient code, and elegant design is efficient design. This means that design and development share some core values of process.”
As outlined in Web UI Best Practices, set aside your ego and focus the conversation on the users. Developers and product managers are more receptive if you remind them of the user-based reasoning rather than its “just good design practice” (which is why personas are so important).
When disagreements arise over-prescriptive feedback, ask each person to state the problem and then describe in detail how they arrive at the solution.
Let’s look at an example from Digg as described in this piece from Smashing Magazine. During the early days of the social bookmarking site, the lead designer came up with some new ideas for changing the vote button (which appeared simple in theory). However, the lead developer at Digg soon realized the changes would require a major reformat of the code architecture and server setup.
Luckily, in their case, the idea was killed after the early conversation. But imagine the ripple effects if they had each gone about their parallel paths, only to crash headfirst later in the process as they scramble to iterate and fix such a foundational error in assumptions.
While collaboration is important, you shouldn’t compromise to the extent that you run into the issue of design by committee. Remember that there is definitely a line between compromising on the aesthetics/interactivity due to technical constraints, versus diluting the design to satisfy all the stakeholders.
Treat Documentation As A Dialogue
First and foremost, you’ll want to start out by reviewing all the top-priority ideas. As the second chapter of the Guide to UX Design Process & Documentation states, the entire team will need to review some form of functional specs and technical specs documents.
Documentation is the starting point for conversation, not just a quick checklist for everyone.
At this stage, it helps to organize suggestions into required features, recommended features, nice-to-haves. As the ideas evolve, keep the developer updated – otherwise you might find a “must-have” feature dictated by the product manager (and already built by designers as a hi-fi prototype) needs to be killed because it’s impossible to build.
Engage in Feature Prioritization Exercises
Once the team has a laundry list of ideas, you’ll want to organize them individually based on purpose and feasibility. Let’s look at the priority/feasibility plot, affinity diagramming, and a clever prioritization activity created by Pandora.
The priority/feasibility exercise (originally developed by UX consultancy firm Adaptive Path) asks the team to score features on a scale of 1 to 5 for priority and feasibility. Everyone on the team casts their votes (Google Spreadsheet works well), then you plot the scores with feasibility on the X-axis and priority on the Y-axis.
Image credit: Appfluence
To avoid design by committee, make it clear that this exercise is meant to just generate more data points for the product design team – it is not a substitute for expert decision-making.
An alternative method, the affinity diagramming method which is sometimes referred to as the KJ Method. It can be outlined as follows based on Jared Spool’s adaptation (which we actually follow at UXPin):
- Start with a focus question, for example: “What new features should we build into our product?
- Everyone suggests ideas on sticky notes or notecards. These ideas are then gathered into a single pile.
- Once every idea has been grouped, the ideas are discussed at length and scrutinized accordingly. Some get tossed, while some may even spur new ideas.
- After you’ve decided which groups are important, prioritize the groups. Once you’re done, you’ll have a better idea of the rough feature set.
This organization technique is designed specifically for sifting through large collections of data, which makes it perfect for complex products.
Pandora’s Workshop Exercise
Pandora’s technique considers financial restraints by limiting features based on what’s affordable over a 3 month period. Although projects can run much longer or shorter, this method is highly adaptable:
- About a week or two before the activity, take down ideas for suggested features. About a week before the activity, have everyone create a short slide describing their idea and its scope.
- Set a dollar estimate for the product team to design and build one feature over a certain period of time(1 month, 3 months, 12 months). These estimates can be used to calculate respective price limits for a budget. To keep it simple, Pandora decides that $5 represents a feature that requires one month of work.
- Pick a group of people and give them post-its with their “budget”. These post-its represent votes for how much should be spent to build a particular feature. To prevent people from getting carried away, Pandora gives each person $30.
- Encourage each person to spend their budget on the top features. Afterwards, the team can discuss which features seem most pertinent and feasible. We agree with Pandora’s recommendation to give a small group of people (like the product team) the final say.
The above exercise helps Pandora cull down 80 rough ideas to a handful of feasible ideas. They’ve actually ran these 2-3 hour workshops every quarter for 8+ years now, which can’t be all that bad considering their success.
Remember that it doesn’t really matter which tactic you choose, as long as the final arrangement works and gets everyone thinking simultaneously about technical feasibility and design priorities.
Assemble a Realistic Plan
Once you’ve successfully prioritized ideas, the next step usually involves preliminary design work. You’ll likely do some rough sketches, iterate them to wireframes, or perhaps just dive directly into low fidelity prototyping.
Although wireframing seems like a designer’s task, developers can lend an ear for suggestions and an eye for critiques.
For example, it helps for designers to get feedback on UI patterns since they are a common component to almost every page on the site. The reality is that developers will need to fill in some design blanks, as Paul Boag suggests. The earlier you involve them, the sooner they can see the “why” behind design decisions, which will help them exercise better judgment later.
By outlining a plan of attack each stage can move along quicker and smoother. For example, the team could start by listing important phases of the project and what needs to be accomplished.
Critical phases usually include (not in linear order):
- Wireframing – Low-fi ideas, UX exploration, layout structure.
- Prototyping – As described in The Ultimate Guide to Prototyping, this stage involves Interactive elements, animated effects, page flow, UX testing.
- Mockup design – Full website mockup creation including icons, textures, colors, typography, and accurately-positioned elements. This may also include inner page designs and responsive changes based on viewport.
- Frontend development – Building design assets, coding the layout, browser support, responsive changes, complete CSS/JS animations.
- Usability testing – This ranges from simple hallway tests with 5 co-workers to unmoderated remote tests involving hundreds of users simultaneously.
Given the rise in popularity of Agile UX methodologies in which designers work a sprint ahead of developers, the key to success lies in validating ideas based on internal and external feedback. When possible, conduct a round of usability testing and internal feedback session (involving stakeholders and developers) every time you iterate the design or make dramatic changes to the code base.
For instance, you might start with a sketch or low-fidelity paper prototype. Even in this rough stage, your feature set is still tangible enough for feedback from developers on system feasibility.
If you’re using UXPin for the digital design, you can then craft a wireframe (or make it a prototype by adding interactions) and tag developers in your comments. As the fidelity of your design increases, so too must the precision of feedback. Once you’ve finalized the visual design and imported your Sketch or Photoshop files into the app, you can again invite developers to your project to ensure all the details are still feasible (before you refine the interactions).
Of course, this project roadmap cannot succeed without a solid kickoff meeting. Make sure you involve developers in your kickoff meetings. Don’t run a kickoff meeting as a 30-minute block to review documentation and timelines. Make it collaborative with helpful exercises like the design studio technique.
Because design projects are completed as a team, they must always be started as a team.
When everyone on the team operates fluidly, it creates an atmosphere of one large team instead of smaller divided teams. That’s exactly the environment you must create, since everyone really is working on the same project regardless of their role and each creative stage is just as important as the next.
As a designer, your role is not just limited to design. Developers may write the code but this is just a means to an end – this “end” being the final product, not the deliverables. We actually built UXPin with this type of collaboration in mind.You can design with others in real time, and you can share your project links with others (they don’t need an account). If you’d like to practice what you’ve learned, go ahead and start a free trial to invite others into the design process.