One of the skills I’ve found to work well in the realm of user experience, is not using technology to help in the UX design process. It seems a little counter-intuitive, as at the heart of our trade is the use of technology. But if we reframe our design thinking without the constraints of our technology-based tools for design, we’ll end up focusing more on the real issues and pain points people have with the technology we end up making. I’ve distilled the essence of these thoughts below.
We all know we need good research to get to a good design. One trick I’ve found helpful is to not use technology to help frame the research that needs to be conducted. Some points include:
- Start meeting people and interviewing them – and write down some insights after talking to them.
- Use the design yourself and see what problems you uncover by trying to accomplish a basic task within the program.
- See if your product has a forum where people can express their thoughts and ways to improve the product, and gather good quotes and pain points (or improvement points too) to take to the next design discussion.
- Watch some people try to use the product and have them tell you about it – you’ll be amazed as to what people do to get their work done.
- With all of these good points written down, create an affinity diagram about what you have found; alternatively, you can use a word cloud or create your own means of sharing what you have found.
- Only use technology to capture details that you cannot (e.g. using a tape recorder for interviews with interviewee’s permission), or to aid in sharing your results.
With all of these insights and new knowledge, there will be a lot of space to design for. If you’re working in a larger design team, see if there is a way to help place your insights into priority updates, or functionality for the next release. If you’re on your own, or in a smaller team, you may have to make a judgment call as to what will help make users’ lives easier and happier.
Once you have something to design for, you should get your favorite pen/pencil and a lot of paper ready (if you’re whiteboard person, that’s fine too). Then, start drawing all of the possible ways to address the insights and problems you have found. Don’t throw anything away, as everything is salvageable. Take a significant amount of time to do this (about an hour or so). Once you have all of your sketches, take a look at how they work. Critique them as if presenting in front of a group, noting their strengths and weaknesses. Take the strengths and continue to iterate on them, until you have a good concept that you can share with others.
Storytelling for user experience is one of the best ways to create a shared understanding of your design intentions. It is also a very good means to show the journey a user takes to perform a task. Create a story for your audience to follow:
- Make sure you have every step sketched and complete that the user will take – your story will suffer if there are hidden steps or “magic” is needed to complete a step in the process.
- Frame your story from the start where a user wants to do something and comes to your product/application.
- Go through each step, noting what actions are taken by the user, and also where questions are being asked by the audience.
- Don’t forget to include an end step, as rarely do we ever leave our users at the end of our applications guessing what to do next.
- Take notes as to what works well with the design and the story, to make sure you can tell it a better way next time, including the improvements and suggestions your audience gives you.
- If part of your story includes areas of uncertainty, make sure the audience knows that, and come prepared with questions to help facilitate the discussion and make sure that the audience feels that their time and talents are valued.
After multiple rounds of sketching, presenting, and building up a concept that should be built with technology, you should have enough data, confidence, and research to create a paper prototype. This prototype should be something you would feel comfortable taking outside of your design and development circle, in order to validate your design. I’ve found that paper prototypes are especially helpful to not only validate a design, but to also efficiently and inexpensively find problems and get stakeholders to invest in improving the design. Some tips I’ve found in the paper prototype process are:
- Prepare and share your prototype with your usability testing team – they may be able to help you prevent mistakes and collect unusable data before the test even begins.
- Make sure you know what you want to gain out of the prototype and the testing before collecting users to test the design. Your session may go longer than expected, and will make participants feel like they are wasting time if there isn’t a solid game plan.
- Create most pieces of the interface on separate pieces of paper, or create each possible version on its own piece of paper (what you look to gain out of the test may help to answer this question). This will allow the moderator to easily assemble the prototype as the user is experimenting with the design
- Above all, make each piece of the prototype looks to scale, and most of all, readable. It is OK to have sketchy lines, but don’t come into the session with a prototype that will embarrass the design team.
Address issues and feedback from testing
From your session, you’ll have gained more insights about how people will have used your design and where they have had problems with it. If you iterate through this technology-less prototyping cycle, you’ll find that you can be just as fast or faster than preparing your concept in your typical tool of choice.
Why is it important to be fast, and not use technology?
To answer the second part
- First: our tools for crafting the user experience are changing all the time, but the one common point to all of them is creating a good concept on paper so we can use our tools as a translation mechanism.
- Additionally, if we can’t draw our design thinking as a means to communicate, then no technology will be helpful in trying to create a good user experience for our users.
- Pragmatically, this is a good skill for a practitioner to have to continue contributing to an organization while trying to understand and gain skills in an organization’s tool-set.
To answer the first part
The obvious answer – time is money for most organizations, and if we can spend our time testing answers to improving systems, they will see their return on investment (as the organization can have tangible proof of design thinking and data-driven design).
The not-so-obvious answer – being fast allows the designer to get their ideas out of their brain and into a form for discussion, critique, and improvement. An idea stuck in a designer’s head isn’t an idea the rest of the team can buy into, and argue for, if it isn’t shown on paper and talked about. It’s just not useful to anyone, except its creator – and that’s what user experience is not about.