Role Relevant Skills Last updated on Lead Designer UI/UX Design March 18, 2019 Visual Design User Research User Testing Requirements Gathering Workshop Facilitation Development Support Layout Inspector Updating the Dropsource layout inspector to support new functionality. Background Mobile apps use constraints to position views on a screen. The original version of Dropsource included a basic layout inspector to help users design their apps. Visualization of a button positioned with constraints. In mobile development, constraints are used to set the size and position of views on an app screen and define how they adapt to different screen sizes. If you are unfamiliar, this is similar in concept to making a responsive website. When we launched the first version of Dropsource a basic layout inspector was included so users could create custom layouts for their app using constraints. Step 1: Understanding the problem Users started hitting the limits of our layout inspector and needed a way to build more advanced layouts. However, supporting this came with an additional complication. ​​ Mockup of the original layout inspector. In the spirit of moving fast, the original layout inspector was launched with the minimum constraint options required to layout a screen: width, height, top, and left constraints. This was enough for users to create basic layouts but was limiting if they wanted to do anything more. For example, it wasn’t possible to pin a view to the bottom right of the screen. As more users started reaching these limitations, this topic kept resurfacing on our support forum. Visualization of pinning a view to the bottom right of the screen. At face value, the answer seems simple, just add more constraint options. However, doing so introduced an additional problem. Constraints have rules that if not followed can put them in an invalid state, causing app screens to render incorrectly. To support more constraint options we also had to address the problem of invalid states and come up with a graceful way for users to deal with them. Step 2: Team Brainstorming Knowing our developers had a better understanding of constraints, I organized a brainstorming session to come up with potential solutions. To kick things off I created a problem brief to align the teams understanding of the problem and prepare them for a brainstorming session. The problem brief I created for the layout inspector. I focused the session on what I saw as our biggest risk, how handle invalid states. At the end of the session we concluded that forcing users to get into and then resolve invalid states would create a lot of unnecessary work and introduce too much complexity. To avoid this, we set out to design a way to enforce a valid state as users were building their layouts. Step 3: Solution Exploration I took the ideas generated in the brainstorming session and explored several design directions. I began ideating on interactions that both enforced a valid state for constraints while also maintaining the flexibility users needed to design their layouts. I shared these concepts with the team for feedback and an initial feasibility assessment. After some back and forth, the team and I landed on possible two directions, both with pros and cons. Sketches of interactions I was exploring. Concept one:​ Prevent users from entering an invalid state in the first place by turning off constraints as users turned on conflicting constraints. Concept two:​ Display an error message prompting users to fix invalid states before proceeding. If they navigate away from the layout inspector before fixing the invalid state, their changes would not be saved and their layout would be reverted to the last valid state. Step 4: Prototyping and User Testing I worked with one of our front-end developers to create a functional prototype of both of these interactions. After a few rounds of testing, we came up with something that worked. Screenshot of the functional prototypes for concept 1 and 2 I took these concepts to one of our front-end developers and asked him to help me create a prototype. While, he was working on the prototype I scheduled 5 moderated user test for the following week. These tests ended up invalidating both concepts, proving both interactions confused users by forcing changes they did not initiate and failed to explain why those changes occurred. After reflecting on these results, we came up with the concept of making users pick from valid constraint combinations rather than giving them the ability to turn on/off all 6 constraints individually. After running another round of moderated user tests the results validated the new concept, allowing users to build their layouts while preventing invalid states. Mockup of the new layout inspector where users pick combinations Step 5: Prepping For Development Requirements and designs were finalized and handed off to the team for development. One page of the mockup handed off to the developers The team was happy to see the results and organized to start development. We hit a few hick-ups but were able to work through them and launch a successful feature for our users. Step 6: Measuring Results Our users were thankful for the updated design and new functionality. We also saw improved layouts in the apps our users were building. After releasing this feature we watched our support forum to see how users responded to the new design and if they ran into any issues. Within short order, we started receiving thanks from our users for the redesign, useful feedback on how to improve the design, as well as a few bug reports (which we fixed right away). "This is definitely a useful update. Previously it was very hard to center elements horizontally and vertically within another view but this new constraint system makes it easy to achieve that now."​ - Sandy H, Computer Science PHD "I've been waiting for this, thank you!"​ - JJ O, Unkown "Thanks Dropsource team. This is a step in the right direction."​ - Tim N, Web Developer Before and after of an app designed with the layout inspector. In addition to written feedback, we also started seeing our users create more refined app designs with sophisticated layouts, which I took as the true sign of success. .