23 March 2016
Looking beyond software-based design tools
Second thoughts on Adobe Experience Design and other new tools, and how we should really be talking about process
After trying Adobe Experience Design (Xd) for a brief hour, I went back to my regular tasks. In the back of my mind I was trying to think of an upcoming task or project to fully test out Xd but none have come up yet. This seems to be the case with a lot of new products; we briefly try them out and then get back to work.
I can’t really fault Xd for being limited, it is a Preview after all. There’s little reason to give a savage review of Xd at this point. Everything that’s missing will be added eventually. I’ve read several reviews where people have pointed out a lot of ‘flaws’ and missing features in Xd. While fair critiques, again we’re talking about a Preview app, and features Adobe has identified.
Curiously I realise Xd Preview is a great example of a minimum viable product, and one where the app’s own UI design didn’t suffer. You can use Xd to design and prototype, using an interface that may be sparse but clean, considered and unified. Adobe clearly has priorities for where they want the product to go. At the same time it must be of some help that we designers are being vocal about the features we most miss; at least for taking a pulse from the community. We could all be so lucky to work on products where users are engaged and offering feedback that can validate our next steps.
If I’m honest, a part of me is comfortable with my current workflow, and I just want Illustrator to be a bit better (stable and have some prototyping & interaction tools). I have been slow to adopt to Sketch because it does things differently from Illustrator (some of which I don’t feel are better). Maybe after five major software switches (starting way back with Pagemaker), I’d like to avoid another change, however most of those product switches were to adapt to someone else’s workflow (why else would I have used CoralDraw).
My hope for Xd is that it takes the best design features from Illustrator with easy to use prototyping tools (yes, opposite to just making Illustrator better). I think it’s heading in that direction. Already I like the new workspace in Xd; it’s simple and uncluttered, and when the missing features are add I could see myself using Xd over Illustrator. It has promise, it just needs to fulfil that and ship. But I’m not fully committed. I want to see how Invision’s Craft improves (prototyping with real content has value), and I need to give Principle a try. Already I’ve given Flinto a try on several projects, and it has a strong lead over the others. The problem is, testing and trying to adopt a new tool takes time away from design.
As some people might know I’m more a fan of good design process than the latest software tool. Improving our craft is a good aim, while relying on software tools should be secondary. I realise a lot of the conversations in the design community is around the latest design tools is due to them being shiny and new; we had a drought of options and little innovation in the space until recently.
Don’t get me wrong, I’m all for new tools that make our work as designers better, more efficient and help us communicate our ideas better. (If anything, better communication is the most important aspect). However I lament that we designers could spend more time discussing how we design, and making the process of design more transparent and better. I should lead by example and stop focusing on the software tools.
At the end of the day, our software tools are there to assist us in executing our ideas, and communicating both our ideas and intentions. We shouldn’t rely on them to solve the problem. They are solving a workflow problem themselves particularly around demonstrating a solution, and the extra time gained should allow us to spend more time refining and iterating to reach better solutions.
What I find more interesting are the processes we use, whether deliberate or second-nature. Learning design process was a key component of my education. If we consider design as a craft where our task is to find a solution to a problem, we also need to recognise we’ll attain a better solution the further we dig, the deeper to the root we work.
In the Sprint book that’s just been released, there are some in-depth examples of the product design sprint process the team at Google Ventures has refined. Taking a process developed by IDEO, the GV design team has reworked it with the added constraint of less time. It’s a great and fast process, not just for startups, but for all businesses that need to react and move quickly.
My best take away from running the workshop has been the result of including stakeholders in the product design process. Doing this answered a lot of questions at the beginning, and everyone was able to give input in defining both the problem and solution, resulting in less friction or delays later. When seeking internal feedback to the near complete project, the solution was already better, the stakeholders read in, and iterations were able to push the solution even further. So much of that came down to good communication.
Of course this is only one approach. I’m working on refining my own process based on what has and hasn’t worked. And I’m curious to know what process other designers follow, whether they follow the rough discover, define, explore, refine and ship process, or identify the change we seek and map the steps in between. How deliberate are we with our process? Do we ensure we ask all the right and enough questions? How do we correctly identify the right core problem, and validate it early on, so we’re on the proper path? And what goals and metrics do we set to validate are solutions worked?
I think sharing our systems for tackling problems, big and small, will help us refine our own tools. And just as we’re eager to try new applications, plugins and workflows, we should apply that curiosity and willingness to experiment on how we do our thinking as much as the practical part of pushing the pixels. We’re advocating experimentation and refinement in our approach to tasks, so we must also ideate and iterate the process itself. Equally we should document how we tackled a problem, and learn from the way we approached previous projects.