How can we help users create a kitchen in 3D in 10 minutes?
Invent Spaces is a desktop app that lets home renovators create and decorate floor plans in 3D. The project kicked off as an industry partnership between a tech startup InventDev and George Brown College. The first prototype focused on technical features. The next step was focusing on usability and interface design.
Joining the team of 3D artists and developers, as the only UX/UI designer, my role spanned the entire UX process.
User research (interviews, surveys), IA, wireframes, lo-fi/hi-fi mock ups, motion prototypes, creating spec docs for developer hand off, user testing (1-on-1)
Problem to Solve
The team felt the prototype worked well, but first-time users had trouble with several key features. It took a while to get going on a project and controls were difficult to pick up.
We came up with a design goal: be able to create a kitchen in 10 minutes.
We created two primary personas and use cases:
- Had to be a desktop app, due to hardware requirements for VR
- Content is dynamic and unpredictable (ever growing furniture library)
After the discovery phase, we narrowed it down to the following insights:
- We overwhelmed users with the amount of buttons and options on screen at once.
- Users usually followed the same steps when constructing a 3D space:
- First, laying out the dimensions and building the floorplan
- Decorating and filling out the space with furniture and appliances
- Touring around the finished space
Our solution — we broke the app up into three stages — Layout, Furnish, Tour. Our idea was to group related features together. This way, we only show ed users features that helped with their current task.
Layout: Dragging and Dropping Rooms
Old method: corner-clicking
One of the challenges was creating rooms. Previously designed by the 3D art team, users’d create rooms by clicking to generate corners. A room was complete after all corners were created. But it was slow and hard to make straight walls. This was something 3D artists and gamers were used to, but demanded a lot of mouse precision from the casual user.
New method: room-dragging
Our design solution was to have users drag in the most common room shapes. While more shapes were possible in the previous version, we didn’t think it was useful to our target users, who were going to be creating the same-shaped rooms over and over again.
Testing confirmed that users knew intuitively to click and drag in the rooms. Whereas, in the previous corner-clicking method, some of our users had trouble discovering the corner-clicking method. Room-dragging also proved more efficient. In an A/B test, someone was able to layout a floor plan in 1 min 40 secs by dragging in the rooms. Versus, while it took them 2 min 30 secs clicking corners. A 60% decrease in time. We weren’t surprised that it was faster, but how much faster.
Creating a Furniture Catalog
Creating meaningful categories
If the goal is to quickly browse through a furniture catalog, the first MVP didn’t accomplish that very well. Items were all grouped together without meaningful categorization. It was okay for a small set of items. But as the library grew, the way we sorted items also had to change.
At first we used big placeholder categories of Appliance, Furniture and Decor. As the library got populated with more and more assets, we realized the categories became too broad, yet again. Users had to scroll through unrelated items before finding the right one.
To fix this, our observations of people using the prototype told us that they generally decorated one room at a time. From this insight, we grouped our furniture by the function of the space — Bath, Bedroom, Kitchen & Dining, Garage, etc. Then we allowed further drilling down to create more meaningful categories.
Error: users mistakenly dragged categories
A funny thing happened when we first pushed out our new category system. Instead of drilling down by clicking the new categories, they tried dragging them onto the project instead. We thought the labels would give them away, but no such luck. Almost all our new testers committed this error.
We realized there were two problems with the new library menu. For one, the large category thumbnails were in the same place as furniture items. Users were used to dragging items from that spot on the UI. Second, the large thumbnails looked too much like items, and we noticed users rarely read the labels.
So on our next prototype, we shrunk the category thumbnails and placed them into a side bar, besides the actual furniture items. The result? Our testers instinctively knew which were the drill-down items, which were the draggable items. Such a small change — reducing size and changing placement — had a dramatic effect.
Popup Menu and Feature Overload
Separating project & object functions
Another problem was having too many options presented on screen. It cluttered the interface and confused first-time users. We found testers having to work through completely unrelated functions to find the right one. To make things worse, often they dealt with different workflows. We needed to separate project-level functions (undo/redo, take a snapshot) and object-level functions (duplicate, delete).
Collapsing into the Popup Menu
So, we kept important functions like Save and Undo and put them at the top. As for smaller, more specific functions, we hid them in the pop up menu. The pop up menu only reveals functions that have to do with that particular piece of a furniture. Things like duplicate, favourite, delete.
We initially worried users would have trouble finding the popup menu. We were proven wrong. During tests, users intuitively knew to click items when they needed to interact with them. The new Popup Menu also solved another problem. When functions like delete was at the top, users weren’t sure what would happen when they clicked it. Was it a toggle? Did you have to click an item first, then delete? In contrast, when delete popped up next to a chair, it was immediately clear that the chair would be removed after clicking.
Retrospective, Lesson Learned
The year long project was a massive learning experience. Doing it all over again, I would change the following things:
- Involve real users at the beginning.
We delayed speaking to real users. We thought we were saving time. But we ended up spending lots of time going back and forth on designs based on personal hunches. Objective user data ended a lot of internal disputes quickly.
2. Test early, refine later
Tweaking hi-def mockups when we didn’t know how it worked wasn’t productive. Once a prototype was live and we saw how it worked, we realized we spent a lot of time refining something that had glaring usability problems. Doing it over, I’d prototype early, even with paper prototypes and get user feedback.
3. Create an MVP quickly
Scope creep was a real issue. The question “what if…” led us to features that users later ignored. The team was really excited about sharing to social media while our core users gave a general ‘meh’. Defining an MVP and releasing it quickly would have saved us lots of development time.