Dream book web app - a UX case study
Problems we had to solve, issues we encountered, and how we solved them.
Background
Dream book is a web application that serves as a tool for interior and exterior design, landscape design, and home improvement.
It allows users to search and upload content, create projects, rooms, and features. The idea behind it is to help the non-designers communicate their vision to the professionals who will work on the remodeling project or the house construction. Clients would share their vision by creating a wish-list in their “dream book” and organize them by rooms or features before contacting a general contractor.
Finalized “book” is a digital album of products that can be purchased on their respective websites and serves as a home’s style guide.
For the purpose of this text, “nail” = “card with an image and controls.”
My Role
I have joined the project in September of 2017, several months after it started. At that point, art direction, UX flows, and base styles have already been set. For the next couple of months, my primary role was to create new UI’s as a front-end developer. In the months to come, I worked with a back-end developer, project lead, and the client to design and develop new features and redesign the old ones where needed. At this stage, I got to carry out both UI design and front-end development while we collaborated on the UX flows and strategy.
The Problems
There were three main questions we were looking to find answers for:
1. How to start a project before getting distracted by all the features and options?
2. How to save those individual features to the room?
3. How to make a complex app with many functions easy to use?
1. How to start a project before getting distracted by all the features and options?
2. How to save those individual features to the room?
3. How to make a complex app with many functions easy to use?
Solution
With the new users in mind, we decided to streamline their experience towards the three consecutive actions:
1. start a project,
2. find the feature,
3. save the feature into the room.
Starting a project
An issue we encountered from the very beginning was endless scrolling. Test users would start scrolling, skipping the "start the project" button on the very top. The most often feedback complaint was that they: "weren't sure what to do."
We tackled that issue on several different fronts, the most important one being the new "welcome page." The new welcome page forced new users to create one of the offered room types, choose their preferred style, nail their very first feature and save it to the room. We wanted to make them focus and think about their future project from the get-go and not getting carried away with the beautiful images that dominated the application.
The welcome page was followed by a short "how-to" tutorial, highlighting all the main features on the home page. A user could reaccess the tutorial through the profile settings, but it would not show the next time users log in. We hoped this approach would set the users for the intended application use without being too intrusive.
Find the way around
This step was easier to solve since we already had a good search bar taking most of the horizontal space in the main navigation. We agreed that the main navigation should also be fixed, making the search and start buttons accessible at all times.
The second search tool we developed was a scrolling carousel similar to the ones used on Google images and Pinterest. This tool enabled toggling between room types and room styles depending on which one user was trying to find.
The very last search option was the "nail feed." Nail feed was a classic collection of cards based on the user's style preferences with infinite scrolling enabled. The design goal of this section was to show as many nails as possible on the screen. Images take most of the space. They were centered within the nail, each having their title and type, plus price and trending status where applicable.
Saving features in the room
Once the user pins the nail, we display the image in its full size with additional details and saving options.
Ease of use
The second big issue that started small but grew as the application grew was the over-cluttered interface. For example, our “card” can be of 3 different types (we had five at one point): “Room,” “Inspirational,” and “Feature Nail,” and in two states (saved and not saved). There can be six different controls on a single card and several descriptive attributes.
To simplify that information overload, we separated controls and descriptive attributes from images but kept the card outline that binds all the elements together. The hierarchy of the components was established using color, size, and position. As a result, our main action, saving the nails, was the most prominent second only to the image below which it sits. The following most crucial action was shuffling. We grayed it out and placed it opposite of saving. Once a user starts shuffling, other controls show up depending on the state of the card.
Conclusion
As of right now, and I’m writing this in July of 2018, the Dream book is out and well. It’s continuously developed and redesigned by the in-house team.
It was technically the most challenging project I had an opportunity to contribute. We finished the project in approximately six months, consisting of two week-long sprints, in an agile manner. Design and development sprints were all mashed up together, and our main goal was to push as many new features as possible. At times chaotic, we did manage to create a functional web app AND have a satisfied client.
In the retrospective today, I would have done some things differently. Keeping better control of the stylesheet and not allowing it to bubble up with every new feature, having an automated style-guide updated with every new iteration, and not building all features from scratch when there were no time for it, are the most important lessons I’ve learned during my time working on Dream book.
