An Opinionated Guide to Creating Software
The final lesson in our Introduction to User Interface Design Through Wireframes course is about what process to follow in order to make sure that your ideas end up seeing the light of day in production, and delighting your end users day after day.
The previous lessons discussed how to design user interfaces. This one, focusing on the design process, is the result of many interviews that Balsamiq has done with entrepreneurs, product managers, UX designers, marketers and developers. Every organization is a little different, but we think that what we describe can serve as a useful starting point for you and your team.
The process is a little different if you're not creating something completely new but are instead adding a small feature to an existing software or website. It's also a little different whether you're a product company or a consulting company. We'll highlight those differences along the way.
The steps in the process are:
- Gather requirements
- Sketch out ideas
- Submit your proposals to the core group
- Incorporate feedback into wireframes
- Pitch to the larger group
- Make a high fidelity prototype (optional, discouraged)
- Work closely with developers
- Help with testing, deployment and marketing
- Monitor how it's received
Step 1: Gather requirements
So it happened: an idea for a new product or feature landed on your lap and you have to design a solution for it.
Ideas come from all over the place: if you work for a product company, they often come via the support or sales teams because of customer requests. Other times they are deemed strategically important by the powers that be (PMs, executives, marketing...). Some other times, the development and design team come up with them! If you're a solo founder, you're doing all of this idea gathering and prioritizing yourself!
If you work for a consulting company, these dynamics often happen within your clients' organizations. They just call you when they're ready to execute on the idea.
Regardless of how it happened, it's time to start executing.
The first step is to understand what people are asking you to do. This phase is normally called gathering requirements.
Gathering requirements is its own discipline, some people make it their whole careers. Here's a very high-level overview.
First of all, make sure you shift the conversation from solutions and ideas for solutions back to "what problem are we trying to solve".
Humans have a very strong tendency to automatically jump to solutions any time they encounter a problem, so it's likely that by the time the request comes to you, it's already framed with a solution in mind.
For instance, you might be asked to "add search to the site or app". Seems clear enough, right? Well, because the request is framed as a solution, you might do all the work to design it, but the solution might miss the point entirely. Maybe the problem your customers wanted to solve would have been solved much better by improving the onboarding flow, or by adding phone support as a support channel! You just don't know!
So step one is to create a wiki page or Google Doc — or whatever tool you use to communicate internally on projects — and put the "What Problem(s) Are We Trying to Solve" title right at the top.
Now, make sure you assemble the correct group of stakeholders. You should include those who asked for this feature, leadership from development, marketing, and ideally someone who will be impacted by this change. If it's too hard to find an external customer (it shouldn't be too hard), find an internal customer to act as their proxy. Someone from tech support, for instance.
Next, go around and ask all the stakeholders what problem are we trying to solve with this change?, and take notes on the page. In some cases, you might have to use the 5 Whys technique to get to the root of the problem. Look for patterns in the responses and categorize the answers so that you have a clean bullet list of requirements on your page.
Once you get to the bottom of what the problems are and have digested it fully (sleep on it!), you might want to circulate the page with the stakeholders again, to make sure everyone agrees that yes, those are the problems we want to solve.
At this point, you should also have a better understanding on how important or urgent this change is for everyone.
Once that's done (ideally in a day or 2), you can start shifting towards thinking about possible solutions.
First up, try to avoid the "if all you have is a hammer, everything looks like a nail" problem. In other words, don't jump to what's easy for you to do. Try to think more holistically, and really try to put yourself in the end-user's shoes.
Don't limit your thinking to a software solution, think about the Whole product concept instead. Maybe the best solution is better documentation, or training, or a process change, or starting a podcast!
Spend a day or 2 testing these possible super-high-level ideas with the stakeholders again.
If you all agree that a software solution is worth pursuing, it's time to move on to the next step.
Note that this doesn't necessarily mean that you're committing to implementing whatever solution you're about to design. It might well be that what you design cannot be implemented in time and on budget, or cannot be supported by your organization... at this point you're just committing to exploring a possible software solution to the problem.
- 10 techniques for gathering requirements
- Software Requirements (3rd Edition)
- Stop gathering requirements - How To Be A Good Product Manager
- Product requirements documents, downsized
- Gathering Product Requirements
- Using Wireframes with Agile User Stories
Step 2: Sketch out ideas
This is the most creative part of the whole process. It's a lot of fun.
Some software teams like to do this part together in a meeting room with a whiteboard, or by using real-time-collaboration in a wireframing tool like Balsamiq Cloud. Other teams like to do an exercise where multiple people come up with solutions on their own, and then get together to review them and pick the best elements of each.
The vast majority of the time though, this phase is done by one person, alone.
So, make sure you get a good night sleep, block out at least 2 hours in your calendar, make sure you're properly caffeinated, quit Slack, turn off email notifications, put your phone to charge in the other room, close your door, put your headphones on, play some relaxing music (Balsamiq Wireframes has it built-in in the View menu), and get yourself ready to get in the flow.
If you're artistically inclined and are not afraid of a white page, you might want to start by sketching ideas on paper. Just keep it high level, boxes and arrows, so to speak.
If you can't draw a straight line to save your life, or find a white page intimidating because it allows you too much freedom (which might make your design too hard to implement), a tool like Balsamiq is perfect for you. You can just pick standard elements from the UI Library and assemble them. Make sure you use the Sketch skin for this step! Switching to the wireframe skin or — God forbid — using a tool that allows you to design at high fidelity, is a terrible mistake at this point! Unless you have superhuman self-control, you'll find yourself thinking WAY too far ahead, fiddling with details like colors, fonts, and pixel-perfect alignments. That's a huge waste of time right now.
If you're just adding a piece of functionality to an existing user interface, you might find it faster to take a screenshot of the existing UI and tweak it by using the crop image tool.
Now it's the time to use all the tips and techniques you learned about in the previous chapters.
Most importantly, don't be afraid to start over!
If you want to see what this process looks like in real life and in real time, check out our Wireframing with Balsamiq YouTube playlist.
Once you're at a good stopping point, go for a walk, take a hot shower, or a quick nap! — the warm and cozy environment away from the computer will help your brain digest what you just did and suggest changes and improvements.
Your goal right now is not to come up with "the definite solution", but rather to come up with some user interfaces to submit to the team as proposals, to see how they react to them.
Be careful not to fall in the "version 3" trap! Because of how our brains work, we usually tend to put way too many details in our wireframes.
So, once the initial wireframes are done, try to scale them back once (version 2), and then do it again, to get to what should be released in version 1.
If you want to show the whole vision to the team, add some annotations that say "v.2" or "this can come later". You could use yellow Pointy Buttons controls for those, or Vertical Curly Braces.
- Creating Your First Wireframe
- How to Start a Wireframe Project
- Sketching User Experiences: Getting the Design Right and the Right Design
- UX Sketching
- Why It's Important to Sketch Before You Wireframe
- Quick, Useful UI Sketches
- UI Sketching Conventions
Step 3: Submit your proposals to the core group
Once you have a few sketches, it's time to go back to the stakeholders for a quick check-in, to see if the direction you've gone in makes sense to everyone.
Make sure you call these sketches "early, quick drafts" and you tell everyone that "you're not married to any of these ideas". This way they won't hold back honest feedback for fear of hurting your feelings.
DO NOT email your sketches or otherwise "send them over the wall". They're too rough to be understood. Schedule quick 1-1 chats with each stakeholder, and walk them through each sketch.
Your goal is to gather as much feedback as possible on where each role would like the design to go. This step is important because your sketches — even in their roughness — are very powerful: they allow everyone to visualize the solution in their minds. This will in turn trigger thoughts and concerns that they couldn't have thought about during requirement gathering.
Note that each person might care about different aspects of the solution. Executives or sales people might care more about branding and strategic importance rather than usability. Developers care mostly about implementability, graphic designers generally care about aesthetics. Learning what each stakeholder cares about is an important part of the process! The more you do it, the better your wireframes will be next time: just like in those old cartoons, you will feel like you have each little person on your shoulders giving you feedback as you design.
Make sure to take good notes as you do this round of feedback — put them on your wiki page!
If some of the feedback is great, "obvious" and non-controversial, go ahead and incorporate it in your design right away, you don't have to wait until you've spoken to everyone.
A word of caution: if you get very little feedback or just simple "looks good to me", you should view it as a red flag. Either people aren't engaged, don't understand what you're proposing, are the wrong audience, or something else. Design at this level of fidelity should always elicit feedback.
Step 4: Incorporate feedback into wireframes
Now it's time to turn your sketches into proper wireframes.
Look at your different designs, study your feedback list, and try to put it all together into a single solution.
If you had been using paper sketches before, this is a good time to transform those into Balsamiq wireframes, as they're generally easier to understand and share.
Once again, use everything you've learned in the previous chapters to create wonderfully usable, lovable designs.
Note that you should still very much keep things at low-fidelity here, it's still too early to risk getting people get distracted by pretty colors and icons. This is especially true when building a new feature, web page, or product.
We recommend only designing the key screens at this point (probably less than a dozen). Just design the Happy Paths for now. There will be time to think about confirmation dialogs and error conditions later.
You might want to use the Symbols feature for headers and footers, and you might want to link screens together to help you walk through them — though it's generally not required as long as you sort your wireframes in a way that flows naturally.
We believe that it's important at this point to allow others to participate in the wireframing process. Just because their job title says "developer" or "business person" it doesn't mean that their user interface ideas should be discounted. Balsamiq, for instance, was built specifically to allow non-designers to have a seat at the table. Don't be too protective of your designs. Instead, invite others who are interested in sharing their user interface ideas to your project! In Balsamiq Cloud for instance, you can do this very easily. They can work alongside you, creating alternate versions for you to review, and you can easily comment on their designs so you can iterate together.
Make sure you work closely with development at this point! They will likely have constraints you don't know about, and their green-light — even a reluctant one — is essential to move forward. By the time you're done, you should know that what you designed is buildable by X people in roughly Y amount of time.
- What is Wireframing and How It Can Improve Communication
- What Are Wireframes?
- How Product Managers Build Healthy Relationships with Designers
Step 5: Pitch to the larger group
Once you've worked on your design for a couple of days, and maybe circulated it electronically with the core team one more time for final review, it's time to present it to everyone.
This will be more of a sales meeting than a brainstorming meeting. You will be pitching your design to all the stakeholders, confident that it will satisfy the requirements. You will still accept feedback, but don't expect too much of it.
Aside from all of the stakeholders from step 1, make sure you invite the person that's high up enough to be able to give your design a green light, so that development can start — usually an executive, or the client. That's your main goal with this meeting.
One trick that some of our customers use at this point is to switch to the Wireframe skin. It's still low-fidelity, but it's a bit more polished, just enough not to elicit the same amount of feedback as the Sketch one.
Walk people through each of the screens you designed, one by one. Try to keep the presentation engaging: avoid getting bogged down in too many details. If objections occur, make a note of them and promise to deal with them 1-on-1 after the meeting (if possible).
If you did your job well involving the core team over and over ahead of the meeting, this presentation should be a breeze. See Tips for Presenting Your Wireframes for more about this important milestone.
Step 6 (optional, discouraged): Make a high fidelity prototype
Back in the days of waterfall, when 18-month release cycles were the norm, building prototypes was a great way to reduce the risk that your solution — even if well thought-out and approved by your team — would miss the mark with customers.
Today's world is much more agile. Developers can turn your wireframes into something for you to play with in days, not weeks or months.
High fidelity prototypes take a while to build (you have to design every single screen in detail, link every single element to its destination, provide fake data, etc.) and are done with expensive tools with a high learning curve. If you have a UX designer on staff — lucky you! — this would be a job that only they can do.
Iterating on prototypes is also painful: changing high-fidelity designs in Sketch or Photoshop takes time, and re-wiring all the pieces of the prototype is a painful process.
Last but not least, once you're done with a prototype, you throw it away.
For these reasons and more, we usually advocate skipping the high fidelity prototyping phase entirely, and going straight to code. Even if your wireframes missed the mark enough for you to have to change 15% of the UI code, you'll still be able to keep the remaining 75%.
That said, creating high fidelity prototypes might make sense sometimes — say, you're building a car, or a satellite... something not easy to iterate on after it's released.
Some, usually large, companies use high fidelity prototypes to get buy in from executives. The idea is that in the enterprise world, the suits don't want to see low fidelity, sketchy-looking stuff. They want to see the real thing, in all of its branded glory.
Another use of high fidelity prototypes is for self-service user-testing. Some people think that end-users will not give you meaningful feedback unless they see the whole thing, as if it was real. It might be, but we've involved our users at the wireframing stage several times, with great results.
You should try and see what's best for you and your company.
If you do this step, expect to add at least a few weeks to the schedule.
Step 7: Work closely with developers
Alright so you have the green light, now it's time to work closely with development to make sure that your designs get built faithfully.
You can help in several ways.
First off, add a lot more details and annotations to your set of wireframes.
Be ready and quick to answer any questions the developers will have.
Make time in your schedule to review early implementations, on staging or via screen-sharing sessions from the developers' machines.
Think of all the possible edge cases and write them down. This will help the developers write unit tests, it will help manual testers to verify each case, and it will allow your support and documentation teams to make sure everything is well documented, with the right screenshots.
Schedule weekly (or even daily!) check-ins with the developers, to see how work is progressing.
Don't be afraid to go back to wireframing! If you notice parts of your design not feeling quite right once they've been implemented in real code, go back to your wireframes and tweak the design to make it work! Life is full of compromises after all.
Step 8: Help with testing, deployment and marketing
As the feature gets close to being ready, you'll be in a great position to help answer questions about the feature from different stakeholders.
Marketing will want to know how to highlight the feature, the documentation team will have you review their work on it, the execs will want a real demo before launch.
You'll be very popular, and like a proud parent, you'll see your new feature get released to the world. Yay!
Step 9: Monitor how it's received
It's amazing how many people don't do this, or don't even consider doing this.
In a way it's understandable, it was such a struggle to get from idea to production, most designers are probably exhausted at this point.
But if you don't know if your feature is well received by the end users, how will you get better at designing?
There are many ways to see if a feature was successful: you can track usage via metrics, you can look for mentions of it on Twitter, or — our favorite way — you can interview your users about it!
Closing thoughts on process
That's it. We hope this brief high-level outline helped you in preparing for what the life of a UI designer — even a non-professional one — is like when taking something from idea to production.
We hope it gave you a sense of who the stakeholders are and what each phase entails.
As we said before, every organization is different, the process above is a weird average of what we heard during dozens of user research interviews with Balsamiq customers.
If your process is different, tell us about it! We're always happy to improve these guides.