Teak & Timber - Project Management App
Teak & Timber is a furniture company that sources high-quality solid-wood furniture from local woodworkers.
We had already built an e-commerce site for customers to order furniture from local woodworkers. Now we had to build the woodworker side of the platform.
Our goal was to build a project management portal that would allow woodworkers to accept, send updates, manage, and get paid for projects online while helping administrators keep an eye on their progress, assess QA, and address potential jam-ups.
Position: Lead Designer
Roles:
User Research
UX/Product Design
UI/Visual Design
Prototype Testing
Deliverables:
User Interviews & Surveys
Competitive Analysis
Proto-personas
Product Requirements/Strategy
User Stories & Flows
Visual Identity
Wireframes & Prototype
User Testing & Design Iterations
Tools:
React
MaterialUI
Figma
TypeForm
FullStory
Wordpress
In the research and discovery phase, I conducted phone interviews with woodworkers, delved into woodworking business blogs, and conducted surveys.
Everyone on our team was an experienced woodworker, but we wanted to make sure we were getting a range of perspectives to validate our assumptions.
We learned…
Ad Hoc Process
Most woodworkers were doing this part-time, so most of them didn’t have a dedicated office and in some cases didn’t have a formalized business process.
Client Negotiations
Their goals were organization and communication - some estimated they spent up to 20% of their time going back and forth with the client through emails and phone calls.
Feast or Famine
Woodworkers tended to have too much work or not enough, so we needed to be flexible about the amount of work builders were willing/able to take on.
Phased Roll Out
The alpha build of Teak and Timber was focused on the e-commerce site (ordering was handled manually).
Beta version linked the product orders to the contractor portal (automated ordering, horray!).
Learning from the alpha
After the alpha launch of the e-commerce site, we learned that it wasn’t that important for customers to be able to pick their woodworker (an element that had previously required us to build our own ecommerce portal from scratch).
We revised our process flow and re-centered our efforts with a shared understanding of all the pieces that needed to be built.
Based on our research, I created high-level user stories. Those stories defined the scope and requirements for our beta build. Not all of our questions were answered right away. How to assess quality control and the payment procedure for customers and builders were sticky issues.
Quality assessment
Quality assessment was a big question for our business model.
After revisiting the process for managing a job, I sketched out a checklist of items that woodworkers needed to report to us as they progressed in their projects. It included photo sharing at key milestones of the project.
Mobile Focused
Most folks have a mobile device these days, but not all of our builders would have a desktop in their shop because of the dust.
Because part of our QA assessment asked builders to upload photos, it would be easier to take photos with a mobile device.
We used MaterialUI for ease and speed. Styles and components were minimally defined in a style guide.
Prototyping, Usability Testing, and Refinements
In an early version of the prototype, we explored versions of the checklist that allowed woodworkers to report their progress on a project. Funds for materials and final payment would be released at various stages of the build.
The biggest changes we made were in materials reporting. Builders had very different strategies for dealing with materials tracking.
What was clear from the interviews was that tracking materials was a non-linear process, so it didn’t fit neatly into our linear checklist. We broke materials tracking out of the checklist altogether and give it its own tab.
At the end of a project, builders would submit the materials list. That way, they could track as they go or tally it up at the end and only had to submit it when they were ready to get reimbursed.
They had a tool to use for calculating costs, but it was optional.
What did we learn from all this?
Fail Fast
Balancing speed and careful research/testing is hard in a startup environment. On one hand, iterating on different builds and launching them quickly gave us invaluable experience for how to address quality control and give clear guidelines for completing work. On the other hand, we wasted a lot of time in the alpha build because we didn’t go deeper into our research about consumer attitudes beforehand.
Scale Up to Scale Down
Adding custom ordering capabilities into our business model will significantly change the way the merchant portal is organized. If I were to start this design again, I would build the first prototype with custom orders in mind and then scale it back to the non-custom version. That way, it will be easier to scale up without doing a complete rebuild.